Hi,
Geez, I see that I'm being quoted all over the place. :-)
On Wed, Apr 12, 2000 at 07:54:47PM -0400, Kevin Atkinson wrote:
> On 11 Apr 2000, Alexandre Oliva wrote:
> > On Apr 10, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> > > 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.
I don't see how the two answers are related. I merely pointed out
that many C++ shared library generation configurations are missing
and/or untested. For example, IRIX C++ shared library support hasn't
been tested, HP-UX C++ support doesn't exist in the multi-language
branch, etc. Did I answer the wrong question? :-)
> > 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.
This doesn't seem too hard to implement. Alexandre, this feature
wouldn't necessarily be specific to the multi-language branch, right?
> > 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....
Presumably if libtool was configured with the "-nostdlib" flag passed
to g++ , then libtool won't have any knowledge of libstdc++ at link
time. I think that Alexandre may have been referring to a way of
accomplishing the same thing at libtool link time without the
workaround I described. Alexandre?
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
