On 11 Apr 2000, Alexandre Oliva wrote:
> 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 a very different answer from what I got from Ossama Othman who
said:
Right. I don't have access to all of the platforms supported by
libtool's C library support so I wasn't able to configurations for all
of the platforms. Any contributions would be more than welcome.
...
> This is the only sane thing to do for a module onae
> 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.
Yes this would defiantly help me out.
> > 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.
Yes this would be great. How difficult would it be to implement and how
soon do you think it will happen. It would make my life a lot easier.
> 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.
>
> > 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.
Actually Ossama Othman told me that using -nostdlib should work.... At
least for gcc....
> > 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.
Perhaps but the problem is with different versions of libtool on the
system as each distribution comes with a slightly different one. For
example when linking in two different libraries in, one which uses a
released version, and another which uses the multilib CVS branch, which
one should be used?
How about a way to get libtool to simply list the necessary libraries to
link in rather than giving the actual command? So that each library can
have a special *-config script (such as found in gtk and gnome) which will
call its own libtool version to figure out the necessary libraries that need
to be linked in. Than libtool won't have to be used, even in the case of
static libraries where the exact libraries needed to link in varies from
one system to another.
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
