Re: Provide a means to activate dynamically the debug traces

[Ralf Wildenhues]

* 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