Re: objc/2902: collect2 doesn't ...: libtool should use collect2?

[Alexandre Oliva]

On May 28, 2001, "John David Anglin" <address@hidden> wrote:

> In the case of hpux, I believe that -nostdlib results in libgcc not
> being linked with the shared archive.

Yep.  Except that output_verbose_link_cmd would have arranged for
libtool to collect all of the magic object files and libraries that
are implicitly linked in and get them explicitly linked it, which is
why we use -nostdlib in the first place.  The point about doing this
is that libtool can then check for static libraries and drop them on
platforms that don't support linking shared libraries with static
ones.

> Probably, linking the library with libgcc is the correct thing to
> do.

Yup

> However, it is not without problems since there isn't a shared
> version of libgcc for hpux yet.

Indeed, this would be a problem, because on HP-UX libtool would drop
libgcc from the link command when creating shared libraries, given
that HP-UX is one of those platforms in which it is not safe to link
static libraries into shared ones.

OTOH, since we do know it is safe to link in libgcc, because it's PIC,
we might just get rid of the -nostdlib, and let GCC do the library
magic by itself.  This should be good enough for objc.

Could you test such a change and re-post the patch, in case it works?

> The later approach sounds much beter to me.

Yep.  But it's not something to be taken lightly.  It will require a
lot of work.  Probably not something for libtool 1.5, nor GCC 3.0.

> Anybody using libtool to build a shared library with constructors
> doesn't want to have to add a libtool configuration script.

I don't understand your point.  This would be yet another libtool
configuration script that everybody would have to add.

The only advantage would be that we wouldn't have to maintain separate
GCC configurations for each language.

>> True.  But there's certainly a reason why we don't use GCC -shared on
>> HP-UX; it was used on all OSs in which it worked, back in the early
>> days of libtool.  I wish I knew what reason it was, in the case of
>> HP-UX :-(

> As far as I can tell, you can essentially do anything with -shared that
> you can do with the linker directly in creating HPUX shared archives.

It's possible that libtool runs the linker directly on HP-UX for the
same reason it does on Solaris: because non-PIC static libraries can't
be linked into shared ones.  In the old pre-MLB days, this caused a
lot of grief to g++, that would link in libstdc++ even when it was not
a shared library.  With MLB, this is no longer an issue.  But it's
hard to tell whether we can safely make this change.  But I suppose
we're going to have to bite the bullet and try it.  Libtoolers,
GCCers, does anybody disagree?

Worst case, it will fail with old versions of GCC, and people will
have to --disable-shared --enable-languages=c for the first build,
then use the newly-built C-only compiler to do a
shared-library-enabled full build.  Expected case, it will Just Work
(TM).

> GCC -shared MUST be used when creating a shared archive with GNU
> standard constructors because it runs collect2 to process the
> library constructors and create the library
> initialization/deinitialization routines.

If the problem is running collect2, it's not an issue.  libtool
already runs it, because that's the linker GCC tells libtool it's
going to use.  However, libtool won't explicitly link in whatever
object files GCC would introduce for the data collected by collect2 to
take effect, so the effect is probably nil.

> Using GCC -shared to build libstdc++ seems to work very well in the
> 3.0 prerelease.  The test results for the v3 library are much better
> than ever before.

Great.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me