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

[John David Anglin]

> > 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.

There are other issues beyond whether or not a static archive is PIC
or not if it is linked with a shared archive.  It's possible to get
module duplication, version inconsistencies, etc.  In 2.95, libgcc
contained routines related to exception handling that contained static
data that couldn't be duplicated.  However, linking a shared libstdc++
with the static libgcc caused no end of problems.

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

Yes.  Unfortuately there is another issue with libobcj that cropped
up.  The external data variable __objc_class_name_Object is placed
in $CODE$.  This isn't allowed and causes most of the tests to fail.
I think I should try to fix this or at least find out why it happens.

> >> 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?

As far as I know, using the linker directly won't help resolve this
under hpux.  We're talking about `gcc -shared', not `g++ -shared',
for the shared archive link command when we have gcc.

> 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).

This shouldn't be a problem unless people don't do a full bootstrap.

> > 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.

That's why I think libtool should use `gcc' rather than attempt
to run collect2 directly.  Stuff is passed from gcc to collect2
in the environment that libtool doesn't know about.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)