* Akim Demaille wrote on Fri, Jan 09, 2009 at 08:56:20PM CET: > Le 9 janv. 09 à 19:40, Ralf Wildenhues a écrit : >> >> You can instead use >> libtool --mode=execute -dlopen module.la $program $args > > Are you saying that the behavior is expected? Why? Why not actually > using the *.la in ltdl to be able to load uninstalled dependencies?
I had to think about this a bit (most of the code is from before my time). I think it cannot be done portably, at least not without changes to ltmain: On some systems where the shlibpath_var (LD_LIBRARY_PATH) overrides the encoded run paths, libtool exploits this for fast-install: the uninstalled module already has run paths pointing to the installed locations of its deplibs. This means, at 'make install' time, the module does not need to be relinked any more. However, it also means that libltdl would be wrongly loading the old installed deplib. libltdl itself cannot update LD_LIBRARY_PATH, AFAICS glibc only reads it once at program startup. I suppose we could change semantics so that you'd have to pass '-dlopen module' for every module you'd possibly dlopen, at mode=link time of the program. Then this information could be encoded in the program wrapper. However, that would require to always have a wrapper in this case, and the listing of all modules at link time is likely not feasible (they may not yet exist in the build tree). > So what do you recommend to store persistent information? A function > that returns some static variable (sort of a singleton)? Or an > additional argument everywhere (gee...). Maybe I can do it using > advices to hand over the verbosity flags, but that does sound like a > nuisance for the API. A lt_dlget* and a lt_dlset* function, if the user needs to be able to provide a type. Don't provide the user with a direct pointer if you don't have to. Note that I didn't say global variables are bad, although they are obviously bad, too, for two reasons: slow access, and, well, globality. Assume that you write a library that uses ltdl internally, and I use your library in a program that also links against a completely different library that also uses ltdl. You'll most likely not want interference. Well, in your case I'm not so sure. But if not, then adding a module loading advisor to change verbosity would seem appropriate. For the slow access, hidden visibility can help (not really relevant for this case). >> BTW, your editor seems to both reformat existing code, and use >> different indenting strategy for new code. Hmm. > > Yeah, I know. But fixing the indentation issues progressively does not > seem bad to me. I certainly don't want these useless differences to > creep into my new code. This implies that there is a single, well-defined ideal state. Your editor does not collapse 8 spaces to a TAB, mine (and some others) does. This causes whitespace-only changes. Very very minor, I agree, but still a small irritation when reviewing. Maybe we should update HACKING about the style we decide about? (note this is really just bike shedding, and babbling) Cheers, Ralf
