Hi Akim, * Akim Demaille wrote on Fri, Jan 09, 2009 at 04:37:32PM CET: > > when I dlopen a module.la which has a dependency.la library, I > expected ltdl to automatically find dependency.la which is not > installed. Yet it does not seem to use the module.la's deplibs to > dlopen them, it delegates this to the native dlopen. As a result, > since my library is not installed, dlopen fails (see > dlopen-failure.txt attachement, notice the deplibs line). > > Of course I can adjust LD_LIBRARY_PATH, but that's not what I expected.
You can instead use libtool --mode=execute -dlopen module.la $program $args Thank you for the patch. I haven't looked at it in detail, but AFAICS it (1) introduces global data symbols, (2) uses them as user-API, and (3) does not annotate them suitably for w32, and (4) doesn't bump the library version numbers accordingly. None of these are ok, unfortunately. Oh, I forgot missing testsuite addition and documentation for new functionality. ;-) I understand that you probably wrote this as a quick hack to get something working. However, IMVHO we should not give in to let such quick hacks into the code base without proper cleanup. FYI, never ever use data (as opposed to function) symbols in a shared library API. Even now that Cygwin is quite usable with them, it will certainly come back to haunt you down the road when you have a better internal representation but are stuck with exposing it. Just don't ever do it. To give a bad precendece example, libltdl did it with lt_preloaded_symbols, and users are suffering because we failed to keep it compatible, and libltdl is suffering because it can't use a faster search inside them. BTW, your editor seems to both reformat existing code, and use different indenting strategy for new code. Hmm. Cheers, Ralf
