On Apr 10, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> About a week ago I posted this massage to the libtool mailing but I have
> yet to receive any replies.
Sorry. I'm drowning in e-mail :-(
Your message was marked as one I should reply some day. Like many
hundreds of others :-)
> 1) On many platforms libtool can create shared libraries for C but
> not for C++
When libtool finds that a shared library depends on a library for
which no shared version is available, it decides not to create a
static library. This is the only sane thing to do for a module one
wouldn't be able to dlopen the module anyway, but maybe we're
overdoing it in case of libraries: we might simply drop the dependency
library, and expect the final program to be linked with it (assuming
allow_undefined, of course). In fact, we might even do it for
modules, but this may force the use of libtool to link final programs,
and the use of -dlopen to bring in any dependencies that may have been
dropped at module-creation time. It would take some work, but would
be a good thing to do, IMO.
> 2) On many of the platforms which libtool does know how to create
> C++ shared libraries libstdc++ is not compiled as a shared library,
> nor is it compiled with PIC support. This means that linking the
> shared library fails miserably because it will try to link the non
> PIC code into the shared library.
Libtool should detect whether libstdc++ is available as a shared
library or not, and arrange for it to be dropped from the link command
in case the shared version is not available, and non-PIC code can't go
into shared libraries.
In fact, we could improve the test about whether a static library can
be linked into a shared one: we could try to create a shared library
with references to all symbols exported from the static library. If
the link succeeds, it is safe (I think :-) to assume that we don't
have to discard the library from the link command.
> 1) Is there a way to force libtool NOT to link it as a C++ library if it
> can't do it as a shared library. IE don't fall back to only making a
> static library.
I don't think so.
> 2) Is there a way to force libtool NOT to link in libstdc++ but STILL link
> it using c++?
No, but this can (and should) be improved.
> In either case I would like the C++ libraries to be specified in the
> .la files so that they will get statically linked in by libtool when
> a C program uses my libraries.
Which means you'd require the programs to be linked with libtool.
Historically, libtool has always avoided being a requirement, but I
think it's the only way to offer certain features.
> Is they a way to do the ldpreloding stuff that is 100% transparent
> to programs linking with my libraries using libtool? I want the end
> user to have to doing noting but "libtool --mode=link ... -l<My
> library>" and have libtool automatically preload the necessary
> modules and set up the data structure automatically so that the end
> user does NOT have to call LTDL_SET_PRELOADED_SYMBOLS().
Not really. But there's a lot of room for improvement, with some
recent improvements in libltdl. Since now the list of dlopening
mechanisms is dynamically modifiable, we could create a symbol table
in the module itself, and arrange that, when the module is dlopened,
the dlpreopen function performs dlopen(NULL) and looks up a symbol
with the name of the symbol table of the library. Assuming
dlopen(NULL) works, of course. If it doesn't (and there are
situations in which it doesn't), there's not much hope for
improvement.
Libtool could also try tricks such as setting up dynamic initializers
in the object file in which the symbol table is created, that would
register dlpreopen handlers in libltdl. But that isn't fully portable
either.
In any case, we'd still have to make sure that the dlpreopen symbol
table gets linked into the final executable, i.e., it would have to be
explicitly referenced either in the (shared) library the program is
linked with, or in the program itself.
One thing you can do is to create your library such that it calls
LTDL_SET_PRELOADED_SYMBOLS() in its own initialization function
(assuming there is one; if there isn't you may have to call it from
all other entry points, or just before any lt_dlopen() called in it).
The problem is that you won't be able to declare that library as
-no-undefined, so it will be created as a static library on platforms
that don't support ``incomplete'' libraries. You'd also have to
declare `-dlopen's when you create the library, and hope libtool will
propagate these `-dlopen's to the end program. I'm not sure it will;
but I'm pretty sure it should :-) You may also have to add `-dlpreopen
force' (or however that option is spelled), to make sure that the
preloaded symbols table is created, even if no dlpreopening is
necessary. Again, I'm not sure this option will be propagated to the
final executable.
--
Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
