From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25546 invoked by alias); 22 Jan 2009 22:37:01 -0000 Received: (qmail 25485 invoked by alias); 22 Jan 2009 22:36:44 -0000 Date: Thu, 22 Jan 2009 22:37:00 -0000 Message-ID: <20090122223644.25484.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dave at hiauly1 dot hia dot nrc dot ca" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-01/txt/msg02414.txt.bz2 ------- 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