OpenAL Soft 1.13 shared object problems

16 posts / 0 new

Last post

Tue, 2012-05-08 19:22

salass00

Offline

Last seen: 1 month 3 weeks ago

Joined: 2011-02-03 11:27

OpenAL Soft 1.13 shared object problems

I'm working on updating the OpenAL Soft port to version 1.13 but I'm having some problems with the shared object. If I link and run utils/openal-info using the static libopenal it runs without problems (doesn't matter if I use static or shared other libraries). If I link it with libopenal.so it either ISIs on alcOpenDevice() or works correctly but hangs on exit depending on whether I use -nostartfiles when creating the .so or not. All the object files for the .so are compiled using -fPIC option so at least that's not what is wrong. Modified source code including Makefile used for compiling can be downloaded from here: http://dl.dropbox.com/u/26599983/openal-1.13-os4.7z

Wed, 2012-05-09 01:59

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

Unless I completely

Unless I completely misundertsnd what you are doing you should not be using -nostartfiles at all, you should be using -shared. BTW blender crashes on exit, after a prolonged video edit, and I believe OpenAL is a possible reason, it's gard to be 100% sure, but it's an interesting cooincidence. I've just downloaded your source I will take a look....

Wed, 2012-05-09 02:10

(Reply to #2) #3

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

libopenal.so:

libopenal.so: $(SHARED_OBJS)
	$(CC) -shared -nostartfiles -use-dynld -o $@ $^ -lpthread

ouch! :-) Try

libopenal.so: $(SHARED_OBJS)
	$(CC) -shared -Wl,--no-undefined -o $@ $^ -lpthread

You don't want -nostartfiles as -shared implies parts of -nostartfiles that you need and draws in the sharedobject startup code, which -nostartfiles will exclude. As it's later on the command line it probably undoes the -shared option. -use-dynld is for building apps not libs. It may or may not make any difference I don't know. On the other hand if you library is incomplete and you don't specify "-Wl,--no-undefined" you will never get an error or warning about any missing symabol / function it will just crash at run time.

Wed, 2012-05-09 02:35

(Reply to #3) #4

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

ppc-amigaos-gcc -mcrt=newlib

ppc-amigaos-gcc -mcrt=newlib -shared -Wl,--no-undefined -o libopenal.so OpenAL32/alAuxEffectSlot.lo OpenAL32/alBuffer.lo OpenAL32/alDatabuffer.lo OpenAL32/alEffect.lo OpenAL32/alError.lo OpenAL32/alExtension.lo OpenAL32/alFilter.lo OpenAL32/alListener.lo OpenAL32/alSource.lo OpenAL32/alState.lo OpenAL32/alThunk.lo Alc/ALc.lo Alc/alcConfig.lo Alc/alcEcho.lo Alc/alcModulator.lo Alc/alcReverb.lo Alc/alcRing.lo Alc/alcThread.lo Alc/ALu.lo Alc/bs2b.lo Alc/mixer.lo Alc/panning.lo Alc/ahi.lo Alc/null.lo -lpthread Alc/ahi.lo:(.got2+0x4): undefined reference to `IExec' removing -Wl,--no-undefined it builds. I'll come back after I've tested ...

Wed, 2012-05-09 02:40

(Reply to #4) #5

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

Hmmm hangs on exit....

Wed, 2012-05-09 07:59

(Reply to #5) #6

salass00

Offline

Last seen: 1 month 3 weeks ago

Joined: 2011-02-03 11:27

You don't want -nostartfiles

You don't want -nostartfiles as -shared implies parts of -nostartfiles that you need and draws in the sharedobject startup code, which -nostartfiles will exclude. As it's later on the command line it probably undoes the -shared option.

I only added -nostartfiles because it wasn't working without it and I had some memory that I read somewhere that you needed to add it when creating a shared object to stop normal startup code being linked in (I probably remembered wrong though), I didn't know that there is special startup code that is linked only into shared objects.

-use-dynld is for building apps not libs. It may or may not make any difference I don't know.

I guess it might be implied by the -shared option but I don't think it hurts to be explicit, which is why I have -mcrt=newlib even though newlib is the default c-library. Anyway I was somewhat under the impression that you always needed to specify -use-dynld if you wanted gcc/g++ to be able to link with shared objects. I've put updated source code with your suggested changes added at the same link, but as you've already noticed even with these changes the shared object still doesn't work (hangs on exit).

Wed, 2012-05-09 11:06

(Reply to #6) #7

afxgroup

Offline

Last seen: 10 months 3 weeks ago

Joined: 2011-02-03 15:26

Did you try to link with -Wl,

Did you try to link with -Wl, --export-dynamic option? I had a similar problem wih iodbc shared object. and indeed without that option i get ISI every time.

Wed, 2012-05-09 11:11

(Reply to #7) #8

salass00

Offline

Last seen: 1 month 3 weeks ago

Joined: 2011-02-03 11:27

I did try

I did try -Wl,--export-dynamic when linking openal-info but it didn't make any difference.

Wed, 2012-05-09 15:23

(Reply to #8) #9

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

I only added -nostartfiles

I only added -nostartfiles because it wasn't working without it and I had some memory that I read somewhere that you needed to add it when creating a shared object to stop normal startup code being linked in (I probably remembered wrong though), I didn't know that there is special startup code that is linked only into shared objects.

-noatartfiles is required for amiga shared libraries not shared objects.

I've put updated source code with your suggested changes added at the same link, but as you've already noticed even with these changes the shared object still doesn't work (hangs on exit).

Yes. I tried a few things and can't se what the issue is. It seems to hang after main has exited. I rebuilt openal for blender (perhaps for this very reason, but I can't really remeber why) and the libopenal.so with blender doesn't not crash on exit. I can't for the life of me remeber what was changed...

Wed, 2012-05-09 16:00

(Reply to #9) #10

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

Looking at the 'crashed task'

Looking at the 'crashed task' in Scout it appears to be waiting on semaphore signal. That doesn't mean for certain that it's really a semaphore as Scout bases that assumption on the particular signal number IIRC. If I send the signal it's waiting for (0x0000010 4) then I get a crash.

    native kernel module kernel+0x00014864
    pthreads.library:_impl_key_delete()+0x80 (section 1 @ 0x1DD8)
    [source/linklib/lib.c:27] libpthread.so:pthread_key_delete()+0x3c (section 8 @ 0x2DC4)
    libopenal.so:alc_deinit()+0x94 (section 10 @ 0x1A560)
    libopenal.so:__shlib_call_destructors()+0x3c (section 10 @ 0xC8)

Wed, 2012-05-09 16:31

(Reply to #10) #11

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

As far as I can see then

As far as I can see then alc_init and alc_deinit are setup as a constructor / destructor pair. lines 383 384 in ALc.c I can't see the explicit call to pthreads in those functions, but I guess it's traced through to a called function deeper down. I'm guessing then when linked as a shared object the pthread.so destructor get's called first. Thus causing the crash. When linked staticaly the destructor will get added to the main executables construtor list and thus get called before the pthread destructor. Note that may not be guaranteed if you link wholy statically with libpthread.a as then the construtor order may not be guarenteed any more. I think to make a viable and safe openal under AmigaOS you will need to remove the constructors and explictly call the functions and start and finish of the program.

Wed, 2012-05-09 17:04

(Reply to #11) #12

salass00

Offline

Last seen: 1 month 3 weeks ago

Joined: 2011-02-03 11:27

I just tried that solution

I just tried that solution and it solves the problem but it also means that every ported program that uses openal needs to be modified to add these acl_init() and acl_deinit() calls manually, and of course then there is also the matter of programs that use openal through another library like freealut, I guess there might be the same problem with constructors/destructors here too and even more such changes need to be added to those programs. I can't say that I'm too happy about this (how come linux and other OSes that use shared objects don't suffer from this problem with openal or other libs for that matter?).

Wed, 2012-05-09 17:24

(Reply to #12) #13

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

Ah you beat me to it. I've

Ah you beat me to it. I've built a version that works too making the modification.

I can't say that I'm too happy about this (how come linux and other OSes that use shared objects don't suffer from this problem with openal or other libs for that matter?).

I've come across a few places that make assumptions about pthreads. The linux implementaion is clearly different and many apps from the linxu world simply assume that it exists and is ready to use. The same assumption can never be true of AmigaOS (well unless pthreads were built into the kernel in some way I suppose). OpenAL is the first program I've come cross that makes such a large usesage of consructors in a shared object. The other time I've come across this issue was with C++ constructors with static objects. An alternate solution to modifying apps to call alc_init() and alc_deinit() would be to modify alcCreateContext to call it on first invocation. something like static WORD inited = 0; alcCreateContext() { if(inited++ == 0) { alc_init() } } alcDestroyContext() { if(--inited == 0) { alc_deinit() } } That assumes that you must always call CreateContext to use openal I don't know much about OpenAL so that may not be the case.

Wed, 2012-05-09 17:26

(Reply to #13) #14

broadblues

Offline

Last seen: 3 years 1 month ago

Joined: 2012-05-02 21:48

BTW I'm not 100% that

BTW I'm not 100% that constructor / destructor call order is the culprit yet, but it's my best guess,

Wed, 2012-05-09 17:52

(Reply to #14) #15

salass00

Offline

Last seen: 1 month 3 weeks ago

Joined: 2011-02-03 11:27

BTW I'm not 100% that

BTW I'm not 100% that constructor / destructor call order is the culprit yet, but it's my best guess,

It probably is. I remember Spot and me had a similar problem with destructor order during the porting of Black Shades Elite (an FPS where you play as a psychic bodyguard), only in that case the problem was with minigl destructor and not with pthread one. The "solution" we ended up using was AFAIR far from an ideal one.

Wed, 2012-05-09 18:57

(Reply to #15) #16

salass00

Offline

Last seen: 1 month 3 weeks ago

Joined: 2011-02-03 11:27

Adding

Adding alc_init()/alc_deinit() to alcCreateContext()/alcDestroyContext() won't work I think. Adding them to alcOpenDevice()/alcCloseDevice() might work for most programs but probably won't be a perfect solution either but still better than nothing I guess.

Search form

User login