[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #45 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-22 22:36 -------
Subject: Re:  shared link/execute fails for cross gcc from linux to target
hppa64-hp-hpux11.00

> Hey. I couldn't stop myself: since Dave said that HPUX doesn't support symbol
> versioning, (no way, no how) I have changed libstdc++ configure to reflect
> this.
> 
> :)
> 
> Ranier, great to see you got something working. I've changed the summary again
> to reflect what is now left of this bug. You are correct in that
> --disable-shared turns off shared library versioning, since versioning only
> applies to the shared lib.
> 
> I believe that this is a documentation-only bug at this point. 
> 
> In particular, I think that this documentation page:
> http://gcc.gnu.org/install/specific.html#hppa-hp-hpux
> 
> Should reflect this discussion. As it stands this:
> 
> There are a number of issues to consider in selecting which linker to use with
> the 64-bit port. The GNU 64-bit linker can only create dynamic binaries. The
> -static option causes linking with archive libraries but doesn't produce a
> truly static binary. Dynamic binaries still require final binding by the
> dynamic loader to resolve a set of dynamic-loader-defined symbols. The default
> behavior of the HP linker is the same as the GNU linker. However, it can
> generate true 64-bit static binaries using the +compat option. 
> 
> oddly changes:
> 
> The GNU 64-bit linker has some issues with shared library support and
> exceptions. As a result, we only support libgcc in archive format. For similar
> reasons, dwarf2 unwind and exception support are disabled. The GNU linker also
> has problems creating binaries with -static. It doesn't provide stubs for
> internal calls to global functions in shared libraries, so these calls can't be
> overloaded. 
> 
> I can see how people are confused by this. GNU ld appears to not really work
> with shared or static libs, from the docs. (But maybe just for 64 bit targets?)
> But experience says it works with static libs, but not shared libs. Something
> needs to be changed, and this section should be updated with the latest status
> and best practice (which appears to be GNU as, HPUX ld).  (FWIW, it looks like
> shared libgcc is being created on this target now with GNU ld or else this
> alone would turn off symbol versioning.) Some love here by people in the know
> would be helpful to all.

It's been awhile but I believe there never was an issue using archive
libraries.  There was a problem linking executables with -static that
I believe got fixed.

I agree this needs rewriting.  The problems with shared library support
are more important than the issues with -static.  However, some testing
is needed to determine the current state of GNU ld.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384