Re: Provide a means to activate dynamically the debug traces

[Akim Demaille]

Le 9 janv. 09 à 19:40, Ralf Wildenhues a écrit :

> Hi Akim,

Hi Ralf,

> * 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

Are you saying that the behavior is expected?  Why?  Why not actually  
using the *.la in ltdl to be able to load uninstalled dependencies?


> 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.  ;-)

The last two points were expected, but first I wanted to have some  
feedback.  Which you did pretty well :)


> 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.

I agree.

> FYI, never ever use data (as opposed to function) symbols in a shared
> library API.

OK, will fix.  Thanks!

> 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.

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.

> 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.