[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 329-gary-allow-RTLD_GLOBAL
From: |
Gary V. Vaughan |
Subject: |
Re: 329-gary-allow-RTLD_GLOBAL |
Date: |
Tue, 22 May 2007 18:11:52 +0100 |
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
- Re: 329-gary-allow-RTLD_GLOBAL, (continued)
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Ralf Wildenhues, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Gary V. Vaughan, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL, Bob Friesenhahn, 2007/05/22
- Re: 329-gary-allow-RTLD_GLOBAL,
Gary V. Vaughan <=