Re: 329-gary-allow-RTLD_GLOBAL

[Gary V. Vaughan]

Howdy Bob!

On 22 May 2007, at 15:32, Bob Friesenhahn wrote:
> On Tue, 22 May 2007, Ralf Wildenhues wrote:
> > > Except for annoyance to the end-user, I was originally thinking that
> > > we don't need to distinguish.  When the developer's libltdl client
> > > code calls lt_dladvise_global, we could have it emit a warning to
> > > stderr that says: If what you are trying to do won't work without
> > > calling lt_dladvise_global(), then you're code will not be fully
> > > portable.
> >
> > Hmm.  That will be informative the first time, and annoying the next
> > million times, if the user chose to accept this limitation.  So yes,
> > a documentation patch is better.  That way not only the fact about
> > some unportability but also its intensity may be conveyed.  ;-)
>
> It is a pity that many Linux application developers develop for  
> Linux only and openly claim to have no interest at all in  
> portability to other systems.  The same folks are also unlikely to  
> read the documentation.

Exactly :'(

> Given the current world order (odor?), I am inclined that  
> RTLD_GLOBAL should not be supported in libltdl unless an additional  
> configure.ac macro/option is supplied.  This would require a  
> concious decision on the part of application developers (at least  
> those bundling libltdl) to depend on this non-portable support.

Excellent!  Although I think the Libtool-2 way of doing it is not with
another macro but an option.  Having said that it seems a bit odd to
put an ltdl option in LT_INIT... where should ltdl options go though?
We still have the LTDL_INSTALLABLE, LTDL_CONVENIENCE mess that I never
got around to fixing up into an ltoptions.m4 driven interface.  There
are a few options:

 - LT_CONFIG_LTDL_DIR is already set up for options, but not everyone
   will use that option, so it probably isn't a good choice.
 - LT_WITH_LTDL still hasn't settled down, and doesn't take options
   yet, though adding an option argument would be natural.  It's not
   so onerous to force people who need options to use this macro to
   do so.
 - LT_INIT feels like the wrong place, but is technically feasible.
 - LTDL_INIT as a whole new macro orthogonal to LT_INIT for ltdl
   options is not a bad idea...

The next release blocker I'm working on is defining the semantics for
LT_WITH_LTDL clearly, and implementing them correctly.  As part of
tackling that, I think renaming it (again) to LTDL_INIT is our best
solution:

  LTDL_INIT([options])

  options is a space separated list of convenience, installable
  module-symbol-visibility (better name, please?).  With respect
  to the latter, if it isn't passed then lt_dladvise_local and
  lt_dladvise_global will emit a 'not supported by this configuration'
  error (or something similar) instead of behaving as they do
  now.

> Unfortunately, it does not cover the case of an already installed  
> libltdl which may or may not be configured to support RTLD_GLOBAL.   
> The macro can test if the already installed libltdl has the  
> support, but if it does, applications could still depend on the API  
> feature without a special configure test.

We haven't released a libltdl that does the support consistently, we
just changed our mind about what the default was, and offered no way
to change that default until 329.  No need to test for that, although
we should test for lt_dladvise_{local,global} were turned off for
the installed libltdl, and have the macro state that it is falling
back on the bundled libltdl to support those features required by
the current libltdl client package.

Thoughts?

Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

PGP.sig
Description: This is a digitally signed message part