[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #51 from Eric Gallager --- (In reply to Steven Bosscher from comment #50) > There was a lot of patch activity for this PR. Is it fixed? I guess so
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||steven at gcc dot gnu.org --- Comment #50 from Steven Bosscher steven at gcc dot gnu.org 2012-01-29 23:13:55 UTC --- There was a lot of patch activity for this PR. Is it fixed?
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.7 |---
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.6 |4.4.7
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.5 |4.4.6
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.4 |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.3 |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #49 from rwild at gcc dot gnu dot org 2009-12-05 17:19 --- Subject: Bug 38384 Author: rwild Date: Sat Dec 5 17:18:53 2009 New Revision: 155012 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155012 Log: Sync from git Libtool and regenerate. /: PR target/38384 PR bootstrap/40972 * libtool.m4: Sync from git Libtool. * ltoptions.m4: Likewise. * ltversion.m4: Likewise. * lt~obsolete.m4: Likewise. * ltmain.sh: Likewise. boehm-gc/: * Makefile.in: Regenerate. * configure: Regenerate. * include/Makefile.in: Regenerate. fixincludes/: * configure: Regenerate. gcc/: * configure: Regenerate. libffi/: * Makefile.in: Regenerate. * configure: Regenerate. * include/Makefile.in: Regenerate. * man/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libgfortran/: * Makefile.in: Regenerate. * configure: Regenerate. libgomp/: * Makefile.in: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libjava/classpath/: * Makefile.in: Regenerate. * configure: Regenerate. * doc/Makefile.in: Regenerate. * doc/api/Makefile.in: Regenerate. * examples/Makefile.in: Regenerate. * external/Makefile.in: Regenerate. * external/jsr166/Makefile.in: Regenerate. * external/relaxngDatatype/Makefile.in: Regenerate. * external/sax/Makefile.in: Regenerate. * external/w3c_dom/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * lib/Makefile.in: Regenerate. * native/Makefile.in: Regenerate. * native/fdlibm/Makefile.in: Regenerate. * native/jawt/Makefile.in: Regenerate. * native/jni/Makefile.in: Regenerate. * native/jni/classpath/Makefile.in: Regenerate. * native/jni/gconf-peer/Makefile.in: Regenerate. * native/jni/gstreamer-peer/Makefile.in: Regenerate. * native/jni/gtk-peer/Makefile.in: Regenerate. * native/jni/java-io/Makefile.in: Regenerate. * native/jni/java-lang/Makefile.in: Regenerate. * native/jni/java-math/Makefile.in: Regenerate. * native/jni/java-net/Makefile.in: Regenerate. * native/jni/java-nio/Makefile.in: Regenerate. * native/jni/java-util/Makefile.in: Regenerate. * native/jni/midi-alsa/Makefile.in: Regenerate. * native/jni/midi-dssi/Makefile.in: Regenerate. * native/jni/native-lib/Makefile.in: Regenerate. * native/jni/qt-peer/Makefile.in: Regenerate. * native/jni/xmlj/Makefile.in: Regenerate. * native/plugin/Makefile.in: Regenerate. * resource/Makefile.in: Regenerate. * scripts/Makefile.in: Regenerate. * tools/Makefile.in: Regenerate. libjava/: * Makefile.in: Regenerate. * configure: Regenerate. * gcj/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libmudflap/: * Makefile.in: Regenerate. * configure: Regenerate. * testsuite/Makefile.in: Regenerate. libobjc/: * configure: Regenerate. libssp/: * Makefile.in: Regenerate. * configure: Regenerate. libstdc++-v3/: * Makefile.in: Regenerate. * configure: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. lto-plugin/: * configure: Regenerate. * Makefile.in: Regenerate. zlib/: * Makefile.in: Regenerate. * configure: Regenerate. Modified: trunk/ChangeLog trunk/boehm-gc/ChangeLog trunk/boehm-gc/Makefile.in trunk/boehm-gc/configure trunk/boehm-gc/include/Makefile.in trunk/fixincludes/ChangeLog trunk/fixincludes/configure trunk/gcc/ChangeLog trunk/gcc/configure trunk/libffi/ChangeLog trunk/libffi/Makefile.in trunk/libffi/configure trunk/libffi/include/Makefile.in trunk/libffi/man/Makefile.in trunk/libffi/testsuite/Makefile.in trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.in trunk/libgfortran/configure trunk/libgomp/ChangeLog trunk/libgomp/Makefile.in trunk/libgomp/configure trunk/libgomp/testsuite/Makefile.in trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/classpath/ChangeLog trunk/libjava/classpath/Makefile.in trunk/libjava/classpath/configure trunk/libjava/classpath/doc/Makefile.in trunk/libjava/classpath/doc/api/Makefile.in trunk/libjava/classpath/examples/Makefile.in trunk/libjava/classpath/external/Makefile.in trunk/libjava/classpath/external/jsr166/Makefile.in
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.2 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.1 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #46 from r dot emrich at de dot tecosim dot com 2009-01-23 10:45 --- Created an attachment (id=17164) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17164action=view) Verbose output of static link step As you can see for all libraries except libdld archives are used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #47 from r dot emrich at de dot tecosim dot com 2009-01-23 10:50 --- Created an attachment (id=17165) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17165action=view) chatr output for the resulting object As you can see there is one dependency to libdl.1 what is ok AFAIK. There is no libdl archive. In the segment index there are two unknown segments. That is with cvs binutils as of yesterday. But I think it's the same with binutils-2.16.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-23 17:41 --- Subject: Re: shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00 As you can see there is one dependency to libdl.1 what is ok AFAIK. There is no libdl archive. Yes, there are a number of libraries that don't have archive versions. I believe libdld needs the dynamic loader. Another library is librt. We try to handle this problem in the LIB_SPEC define. In the segment index there are two unknown segments. That is with cvs binutils as of yesterday. But I think it's the same with binutils-2.16.1. Advise using recent version. There are no recent fixes affecting GNU ld on hpux, but there have been some assembler fixes. I've seen the segment issue but don't have a fix. There's something going wrong in the core code. I think this is the main issue with shared libraries. I tried a full native build last night with GNU ld. It failed with a broken f951 compiler. The problem is pc-relative calls are broken (no stub, or incorrect offset to stub) when the call distance exceeds the maximum branch distance for the 22-bit pc-relative relocation. This should be relatively straightforward to fix. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #44 from bkoz at gcc dot gnu dot org 2009-01-22 22:01 --- 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. I leave the edits to the target maintainer. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Keywords||documentation Summary|link/execute fails for cross|shared link/execute fails |gcc from linux to target|for cross gcc from linux to |hppa64-hp-hpux11.00 |target hppa64-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- 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
