>gcc -O2 -Wall -fPIC -c bfio_alsa.c >ld -shared -o alsa.bfio bfio_alsa.o -lasound
i don't think you can't build shared libraries like this unless you have the right kind of object for libasound, and i'm not sure that *.so is not the right kind of object. it seems that you're trying to express a dependency between your new shared library, alsa.bfio, and the existing shared library libasound.so. you don't need to do that. >ld -shared -static -o alsa.bfio bfio_alsa.o -lasound this seems nonsensical. -shared -static cancel each other, right? this is just linking everything needed from libasound.a into the static library alsa.bfio. to be honest, i am not sure you can create inter-shared-library dependencies in this way. there is, however, some way to do it, since ldd /usr/lib/*.so.* will reveal many such linkages. >I get it to work, or if I link the the main executable dynamically with ALSA. >I am new to using dlopen(), but it seems to me like the problem could be that >ALSA fetches the handle for the main executable, which in this case is not >linked with ALSA. > >Any suggestions? Could this be a problem with how ALSA uses dlopen, making it >impossible to make shared libraries that dynamically links to ALSA? ALSA uses dlopen itself, yes. Anything else that tries to dlopen() libasound must use the RTLD_GLOBAL flag on dlopen() so that all symbols are resolved. This is a general problem with dlopen()-ing code that itself uses dlopen(). I don't know if link-time shared object construction can deal this or not. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
