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.
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. 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.
Bob
======================================
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
