[Bug target/26014] linking against libgcj results in strange unresolved symbols
--- Comment #7 from alex at milivojevic dot org 2006-01-30 14:50 --- (In reply to comment #5) > ld from binutils 2.16.1 does not resolve this issue. > GNU assembler version 2.16.1 (sparc-sun-solaris2.10) using BFD version 2.16.1 > sparc-sun-solaris2.10 I used recent weekly snapshot of binutils (060124). It works. Now I'm just waiting if Sun is going to include 64bit version of libart_lgpl (either in next beta or in final) and I'm going to be as happy as a pig in a mud ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26014
[Bug target/25998] static executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe)
--- Comment #7 from alex at milivojevic dot org 2006-01-29 19:52 --- Ah, of course it wasn't working. Either DONE should be set to .false., or DO should be changed to "while (DONE)". For example: ... logical DONE DONE = .false. DO while (.NOT. DONE) ... Now it works correctly everywhere. Guess this should be closed. -- alex at milivojevic dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998
[Bug target/25998] static executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe)
--- Comment #6 from alex at milivojevic dot org 2006-01-29 03:52 --- It just shows how rusty my Fortran is ;-) I've compiled the updated test program, and got the same thing. It does not work on SUNW,UltraAX-e2. -- alex at milivojevic dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998
[Bug target/26014] New: linking against libgcj results in strange unresolved symbols
ference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' ./.libs/libgcj.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[5]: *** [jv-convert] Error 1 make[5]: Leaving directory `/usr/local/tmp/gcc/sparc-sun-solaris2.11/sparcv9/libjava' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/tmp/gcc/sparc-sun-solaris2.11/sparcv9/libjava' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/usr/local/tmp/gcc/sparc-sun-solaris2.11/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/usr/local/tmp/gcc/sparc-sun-solaris2.11/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/usr/local/tmp/gcc' make: *** [bootstrap] Error 2 -- Summary: linking against libgcj results in strange unresolved symbols Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex at milivojevic dot org GCC build triplet: sparc-sun-solaris2.11 GCC host triplet: sparc-sun-solaris2.11 GCC target triplet: sparc-sun-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26014
[Bug target/25998] executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe) shared libc_psr.so.1
--- Comment #4 from alex at milivojevic dot org 2006-01-27 19:34 --- Some additional info (there's always something else that pops up). Seems the problem is present only on machine where both of the following are true: - processor is UltraSPARC-IIe - "uname -i" returns SUNW,UltraAX-e2 One machine where /usr/platform/sun4u/sbin/prtdiag claims the processor is UltraSPARC-IIe, but "uname -i" prints out SUNW,UltraAX-i2, and the test program was running correctly on it. I've blindly assumed that machine had IIi processor when I was writing bug report. Sorry about that. Interesting thing is that both SUNW,UltraAX-e2 and SUNW,UltraAX-i2 are symbolic links to generic sun4u directory: $ ls -l /usr/platform ... lrwxrwxrwx 1 root root 5 Apr 4 2003 SUNW,UltraAX-e2 -> sun4u lrwxrwxrwx 1 root root 5 Apr 4 2003 SUNW,UltraAX-i2 -> sun4u drwxr-xr-x 6 root sys 512 Mar 12 2003 sun4u ... The SUNWkvm package on both machines seems to be the same version. I even copied over libc_psr.so.1 from one machine to another and run diff, and it reports the files are identical. $ pkginfo -l SUNWkvm PKGINST: SUNWkvm NAME: Core Architecture, (Kvm) CATEGORY: system ARCH: sparc.sun4u VERSION: 11.9.0,REV=2002.04.06.15.27 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: core software for a specific hardware platform group PSTAMP: on81-patch20021015110113 INSTDATE: Mar 12 2003 09:15 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 192 installed pathnames 43 shared pathnames 46 directories 10 executables 2 setuid/setgid executables 1610 blocks used (approx) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998
[Bug target/25998] executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe) shared libc_psr.so.1
--- Comment #3 from alex at milivojevic dot org 2006-01-27 17:26 --- I said it might be a bug with gcc. After all, gcc is the only application that doesn't work correctly on this box. I guess maintainers of any other component mentioned (gmp, mpfr, binutils, Sun) can say the same thing as you did. Since gcc is the first (and so far only) application that had problem on this platform, it was the best place to start (IMO). As I said, if there are any tests I could run on this platform to rule out gcc, I'd be more than happy to run them. The libc_psr stuff is not really a black magic (and not really brought in by black magic). It's just the processor optimized part of libc. If it was black magic, than glibc optimized for anything else other than basic processor type (such as i386 for example) would be black magic too ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998
[Bug target/25998] executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe) shared libc_psr.so.1
--- Comment #1 from alex at milivojevic dot org 2006-01-27 17:11 --- Created an attachment (id=10743) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10743&action=view) test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998
[Bug target/25998] New: executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe) shared libc_psr.so.1
This might be a bug in any of the following:
- gcc/f951
- gmp
- mpfr
- Sun system libraries
- binutils
- UltraSPARC-IIe (not likely, but you never know)
Of course, there is always possibility it was just me doing something stupid.
If there is any way (or test) to check if bug is in f951 or not in f951, please
let me know. So far, I had the problem only with gcc/f951 generated code on
this machine (relatively bussy box that was running all kind of stuff in the
past 3 years). So it's either gcc/f951, or some obscure bug in other
component(s) that gets triggered only by gcc/f951.
When I compile sample Fortran hello world program, it produces different output
depending on which machine it is run (if dynamically linked). Or depending on
which machine it was compiled on (if statically linked). Statically linked
binary shouldn't include any machine-specific code (libc_psr is shared-only
library, there's no libc_psr.a). However, f951 itself gets dynamically linked
against this system library which is processor dependant.
I've downloaded the "hello world" program from the net. Haven't done Fortran
in long time, but looking at it, it should print "Hello, world." in endless
loop.
Running "uname -a" shows:
$ uname -a
SunOS apollo 5.9 Generic_112233-04 sun4u sparc SUNW,UltraAX-e2 Solaris
When compiled with -m32 and run on SUNW,UltraAX-e2 machine (output of uname
-i), the program exits immediatelly with no output.
When compiled with -m64, it works correctly.
If I copy the 32bit program (including libgfortran and libgcc_s libraries) to
any other machine (tested on UltraSPARC-II and UltraSPARC-IIi) it works
correctly.
If I compile the program statically on SUNW,UltraAX-e2 machine, and then copy
it to different machine, it doesn't work.
If I compile the program statically on any other machine, and copy it to
SUNW,UltraAX-e2 machine, it works correctly.
$ ldd a.out
libgfortran.so.0 => /opt/pbl/lib/libgfortran.so.0
libm.so.1 => /usr/lib/libm.so.1
libgcc_s.so.1 => /opt/pbl/lib/libgcc_s.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
/usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1
$ ldd /opt/pbl/libexec/gcc/sparc-sun-solaris2.9/4.0.2/f951
libmpfr.so.1 => /opt/pbl/lib/libmpfr.so.1
libgmp.so.3 => /opt/pbl/lib/libgmp.so.3
libc.so.1 => /usr/lib/libc.so.1
libgcc_s.so.1 => /opt/pbl/lib/libgcc_s.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
/usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1
gcc 4.0.2:
../configure --prefix=/opt/pbl --with-local-prefix=/opt/pbl
--with-cpu=ultrasparc --with-tune=ultrasparc
--enable-languages=c,ada,c++,f95,java,objc --disable-nls --with-gmp=/opt/pbl
--with-mpfr=/opt/pbl --with-gnu-ld --with-gnu-as --with-ld=/opt/pbl/bin/ld
--with-as=/opt/pbl/bin/as --enable-java-awt=xlib --with-x
gmp 4.1.4:
../configure --build=sparc-sun-solaris2.9 --enable-cxx --enable-shared
--enable-static --with-readline --with-gnu-ld
mpfr 2.2.0 (with all recommended patches):
../configure --prefix=/opt/pbl --with-gmp=/opt/pbl --enable-static
--enable-shared
binutils 2.16:
../configure --prefix=/opt/pbl --exec-prefix=/opt/pbl --with-mpfr=/opt/pbl
--with-gmp=/opt/pbl --enable-shared --disable-nls --enable-64-bit-bfd
I also did couple of test installations into my home directory
(gcc/gmp/mpfr/binutils) and was able to reproduce the problem every time.
I have only one UltraSPARC-IIe box (500MHz processor), so can't tell if the
problem is repeatable on every one of them. It is on mine.
--
Summary: executable generated by f951 doesn't work with 32-bit
SUNW,UltraAX-e2 (UltraSPARC-IIe) shared libc_psr.so.1
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alex at milivojevic dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998
[Bug target/25725] libtool -rpath works only for GNU ld, not for Sun ld
--- Comment #2 from alex at milivojevic dot org 2006-01-24 15:35 --- As a temporary workaround, I was thinking about changing Makefile.am files, and regenerating Makefile.in so that they include both -rpath and -R when invoking libtool (would work for me). Looking at files, only boehm-gc/Makefile.am and libjava/Makefile.am have '-rpath' inthere. What to do with the rest of them? What do I need to change so that when automake is run I get Makefile.in files with both -rpath and -R? There's couple of Makefile.in files that seem not to be generated by automake (for example, libobjc/Makefile.in), I guess I can edit them directly. There's also gcc/fortran, that doesn't have Makefile of its own. There's only Make-lang.in, and it doesn't use libtool. Hmmm... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725
[Bug target/25932] Gnat bug in simplify_subreg, at simplify-rtx.c:3746
--- Comment #6 from alex at milivojevic dot org 2006-01-23 20:45 --- Created an attachment (id=10723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10723&action=view) terminal_interface-curses.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25932] Gnat bug in simplify_subreg, at simplify-rtx.c:3746
--- Comment #5 from alex at milivojevic dot org 2006-01-23 20:45 --- Created an attachment (id=10722) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10722&action=view) terminal_interface-curses-aux.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25932] Gnat bug in simplify_subreg, at simplify-rtx.c:3746
--- Comment #4 from alex at milivojevic dot org 2006-01-23 20:44 --- Created an attachment (id=10721) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10721&action=view) terminal_interface-curses.ali -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25932] Gnat bug in simplify_subreg, at simplify-rtx.c:3746
--- Comment #3 from alex at milivojevic dot org 2006-01-23 20:44 --- Created an attachment (id=10720) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10720&action=view) terminal_interface-curses.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25932] Gnat bug in simplify_subreg, at simplify-rtx.c:3746
--- Comment #2 from alex at milivojevic dot org 2006-01-23 20:44 --- Created an attachment (id=10719) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10719&action=view) terminal_interface-curses.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25932] Gnat bug in simplify_subreg, at simplify-rtx.c:3746
--- Comment #1 from alex at milivojevic dot org 2006-01-23 20:43 --- Created an attachment (id=10718) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10718&action=view) terminal_interface.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25932] New: Gnat bug in simplify_subreg, at simplify-rtx.c:3746
I don't know anything about Ada, just happen to have gnat installed on my
system, and got this while compiling ncurses (ncurses-5.5.tar.gz, ncurses
configured with "../configure --with-shared --with-rpath --prefix=/opt/pbl"):
$ gcc -v -save-temps -c -I../../../Ada95/src/ -O3 -gnatpn -I.
-I../../../Ada95/src -I- ../../../Ada95/src/terminal_interface-curses.adb
Using built-in specs.
Target: sparc-sun-solaris2.6
Configured with: ../configure --prefix=/opt/pbl --with-local-prefix=/opt/pbl
--with-cpu=ultrasparc --with-tune=ultrasparc
--enable-languages=c,ada,c++,f95,java,objc --disable-nls --with-gmp=/opt/pbl
--with-mpfr=/opt/pbl --with-gnu-ld --with-gnu-as --with-ld=/opt/pbl/bin/ld
--with-as=/opt/pbl/bin/as --enable-java-awt=xlib --with-x
Thread model: posix95
gcc version 4.0.2
/opt/pbl/libexec/gcc/sparc-sun-solaris2.6/4.0.2/gnat1 -I../../../Ada95/src/
-I. -I../../../Ada95/src -I- -quiet -dumpbase terminal_interface-curses.adb -O3
-gnatpn -mcpu=ultrasparc -mtune=ultrasparc
../../../Ada95/src/terminal_interface-curses.adb -o terminal_interface-curses.s
+===GNAT BUG DETECTED==+
| 4.0.2 (sparc-sun-solaris2.6) in simplify_subreg, at simplify-rtx.c:3746 |
| Error detected at terminal_interface-curses.adb:2566:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
../../../Ada95/src/terminal_interface-curses.adb
./terminal_interface-curses.ads
../../../Ada95/src/terminal_interface.ads
./terminal_interface-curses-aux.ads
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387
I'll include listed files shortly...
--
Summary: Gnat bug in simplify_subreg, at simplify-rtx.c:3746
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alex at milivojevic dot org
GCC build triplet: sparc-sun-solaris2.6
GCC host triplet: sparc-sun-solaris2.6
GCC target triplet: sparc-sun-solaris2.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25932
[Bug target/25725] libtool -rpath works only for GNU ld, not for Sun ld
--- Comment #1 from alex at milivojevic dot org 2006-01-11 15:30 --- I've just installed GNU binutils and recompiled gcc (languages=c,c++,objc,java,f95) for sparc-sun-solaris2.9 and with GNU linker and assembler. The problem exists there too. So it is libtool script not passing -rpath argument to the linker command (doesn't depend on which ld is used). It's kind of strange, sometimes libtool will pass the correct option to the link command, sometimes it won't. Also, for some targets, the Makefile doesn't seem to use libtool to create them (invokes link command directly). Also, when creating shared libraries, if the library depends on another shared library, I found that sometimes I need RPATH set in the shared library as well (at least when using Sun ld). I'm not yet completely sure, but it seems that if liba.so depends on libb.so the dynamic linker will be able to find libb.so only if exectubale directly depends on both liba.so and libb.so. If executable (with correct RPATH tag pointing to both liba.so and libb.so) depends only on liba.so, the dynamic linker will fail to find libb.so. I had this problem (when using Sun ld) with several programs that depended on libraries that in turn depended on libgcc_s.so. Relinking the library to include RPATH tag to where libgcc_s.so is, solved the problem. However it was kind of annoying to have to manually fix this after almost every single library I built. As I said, this seems to be the problem when using Sun ld. Comparing "dump -Lv f951" outputs from excutables created by Sun and Gnu ld, the one created by Sun ld depends only on libgmp and libc. The one created by Gnu ld depends on libgmp, libc and libgcc_s. Looks like Sun ld will include NEEDED tags only for libs the exectable directly depends on. Gnu ld will include NEEDED tags for libs the executable indirectly depends on too (the libgmp depends on libgcc_s). Because of this Sun ld behaviour, when creating shared libraries on Sun Solaris systems, the -R or --rpath (depending which linker is used) should be used regardless of which linker is used (since the user might mix and match libs created by both linkers). BTW, one difference between GNU ld and Sun ld I noticed was that Sun ld will set both RPATH and RUNPATH tags. The GNU ld will set only RPATH. It doesn't seem to make any difference during runtime. Couple of examples from the last GCC build I made. >From the build log, it doesn't seem libtool was used to create f951 (Makefile used xgcc directly). The resulting binary is missing RPATH. $ ldd f951 libgmp.so.3 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => (file not found) libdl.so.1 =>/usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1 $ dump -Lv f951 f951: DYNAMIC SECTION INFORMATION .dynamic: [INDEX] Tag Value [1] NEEDED libgmp.so.3 [2] NEEDED libc.so.1 [3] NEEDED libgcc_s.so.1 [4] INIT0x12154 [5] FINI0x384500 [6] HASH0x100e8 [7] STRTAB 0x110a8 [8] SYMTAB 0x105b8 [9] STRSZ 0x6fb [10]SYMENT 0x10 [11]DEBUG 0 [12]PLTGOT 0x3f0f60 [13]PLTSZ 0x714 [14]PLTREL 0x7 [15]JMPREL 0x11a40 [16]RELA0x119a4 [17]RELASZ 0x7b0 [18]RELAENT 0xc [19]VERNEED 0x11904 [20]VERNEEDNUM 0x2 [21]1879048176 Another example. The libstdc++.so. It is missing RPATH, so dynamic linker might fail to find libgcc_s.so during runtime (if executable was created using Sun ld): $ ldd libstdc++.so libm.so.1 => /usr/lib/libm.so.1 libgcc_s.so.1 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1 $ dump -Lv libstdc++.so libstdc++.so: DYNAMIC SECTION INFORMATION .dynamic: [INDEX] Tag Value [1] NEEDED libm.so.1 [2] NEEDED libgcc_s.so.1 [3] NEEDED libc.so.1 [4] SONAME libstdc++.so.6 [5] INIT0x3e9d0 [6] FINI0xbd4c0 [7] HASH0x94 [8] STRTAB 0x1168c [9] SYMTAB 0x44ec [10]STRSZ 0x21cee [11]SYMENT 0x10 [12]PLTGOT 0xe1ee4 [13]PLTSZ 0x1950 [14]PLTREL 0x7 [15]JMPREL 0x3d080 [16]RELA0x34fe0 [17]RELASZ 0x99f0 [18]RELAENT 0xc [19]VERDEF 0x34db0 [20]VERDEFNUM 0xa [21]VERNEED 0x34f00 [22]VERNEEDNUM 0x3 [23]1879048176 [24]RELACOUNT 0x32d -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725
[Bug target/25725] New: libtool -rpath works only for GNU ld, not for Sun ld
Libtool is always invoked with -rpath /prefix/lib/sparcv9 option. When using Sun ld (/usr/ccs/bin/ld), the option should be -R/prefix/lib/sparcv9. This results in libraries and some executables not being able to find libraries they depend on during runtime. It is possible that sparc-sun-* target is also affected (not tested). Examples of libraries and executables that are affected: f951, libgfortran.so, libobjc.so, libgcj.so, libffi.so. Possibly more. Not sure if libtool was supposed to pass -rpath as -R to actual link command (it didn't), or if libtool should get -R instead of -rpath when Sun ld is used. -- Summary: libtool -rpath works only for GNU ld, not for Sun ld Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex at milivojevic dot org GCC build triplet: sparc64-sun-solaris2.9 GCC host triplet: sparc64-sun-solaris2.9 GCC target triplet: sparc64-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725
[Bug other/16507] gcc_s not found when linking 64-bit C++
--- Comment #16 from alex at milivojevic dot org 2006-01-05 21:50 --- (In reply to comment #15) > It's a build machinery problem. Actually it is the "configure" script and "libtool" scripts in 99% of open source packages not handling the sparc64 correctly (not handling it at all would be more correct description). This sometimes makes compiling stuff on bi-arch systems a nightmare. One workaround is to use 'LDFLAGS=-R/prefix/lib/sparcv9 ./configure --libdir=/prefix/lib/sparcv9' (however, there might be sideeffects). Gcc is about the only open source thing that I saw so far that handles sparc64 installs as it should. You type one make command, you get both 32-bit and 64-bit libs. You type one make install, you get both libs installed in correct locations (well, except for libiberty ;-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16507
[Bug other/23541] all error messages produce segfault
--- Comment #16 from alex at milivojevic dot org 2006-01-04 19:55 --- (In reply to comment #15) > Both in dgettext.c and dngettext.c at a minimum as far as I can see. Another > possible path is to bootstrap the compiler with Sun cc or with gcc -std=c89. Bootstrapping with 'gcc -std=c89' hasn't worked. First I got xgcc binary that was linked without -rpath or -R (so it was linked against $prefix/lib/sparcv9/libintl.so.3 from GNU gettext, while dynamic linker could find only libintl.so.1 in /usr/lib/sparcv9 which was part of Solaris system). This is probably something that should be fixed in build process. OK, there's --with-included-gettext option. Using that one, the xgcc crashed the very first time it was invoked. Currently recompiling without --with-included-gettext and with LD_LIBRARY_PATH set. If that one fails, I'll try switching the order of includes (probably should have done that one first). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug other/23541] all error messages produce segfault
--- Comment #14 from alex at milivojevic dot org 2006-01-04 15:03 --- Benjamin: You are not alone. I hit that bug too ;-) Andrew: I can reproduce the bug on my system. I haven't done anything fancy. And I made sure only standard Solaris header files/libraries were visible while bootstrapping the compiler (too bootstrap 64-bit build, I used intermediate 32-bit build that had --with-local-prefix pointing to an empty area, and again when bootstrapping 64-bit build I used --with-local-prefix pointing to different empty area). So, it is not just Benjamin's configuration. Could be that Eric had some additional conflicting header files in search path in front of standard Solaris ones (in other words, he built on "dirty" system). Actually, the bug prevents bootstrapping objc and java languages too (only c and c++ can be built). I haven't attempted bootstrapping fortran and ada, so I can't tell if they are affected. Eric: Hmmm... If in dgettext.c I simply change the order the files are included, would that solve the problem? Or the fix is going to be more complex? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug target/25602] internal compiler error while bootstraping (while compiling libobjc/sendmsg.c)
--- Comment #3 from alex at milivojevic dot org 2006-01-03 20:30 ---
Created an attachment (id=10579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10579&action=view)
one more example of sigsegv
Trivial example where 64-bit gcc binary segfaults.
The code in question is old-style hello world:
#include
int main()
{
cout << "Hello World\n";
}
When attempting to compile:
$ g++ -v -save-temps hello-old.cc
Using built-in specs.
Target: sparc64-sun-solaris2.9
Configured with: ../configure sparc64-sun-solaris2.9 --prefix=/opt/pbl
--with-local-prefix=/opt/pbl --with-cpu=ultrasparc --with-tune=ultrasparc
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.2
/opt/pbl/libexec/gcc/sparc64-sun-solaris2.9/4.0.2/cc1plus -E -quiet -v
-D__arch64__ -D__sparcv9 hello-old.cc -mcpu=ultrasparc -mtune=ultrasparc
-fpch-preprocess -o hello-old.ii
ignoring nonexistent directory
"/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../sparc64-sun-solaris2.9/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/sparc64-sun-solaris2.9
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../include/c++/4.0.2/backward
/opt/pbl/include
/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/include
/usr/include
End of search list.
In file included from :0:
:0: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Interestingly, the new style hello world compiles just fine:
#include
using namespace std;
int main()
{
cout << "Hello World\n";
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25602
[Bug target/25602] internal compiler error while bootstraping (while compiling libobjc/sendmsg.c)
--- Comment #2 from alex at milivojevic dot org 2005-12-30 21:04 --- I've attempted to repeat the build with --languages=c,c++,java and got basically the same thing (segmentation fault) when compiling boehm.cc in libjava directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25602
[Bug c/25602] internal compiler error while bootstraping (while compiling libobjc/sendmsg.c)
--- Comment #1 from alex at milivojevic dot org 2005-12-30 15:18 --- Created an attachment (id=10570) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10570&action=view) The .i file Here's the sendmsg.i file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25602
[Bug c/25602] New: internal compiler error while bootstraping (while compiling libobjc/sendmsg.c)
I was bootstrapping gcc-4.0.2 on Solaris 2.9 system. Since I wanted to build 64-bit compiler binary, and I didn't had compiler capable of producing 64-bit code, I did it in two stages. The first stage built and installed fine. I built 32-bit gcc-4.0.2 binaries using following commands: $ ../configure --prefix=/home/amilivojevic/s9 --with-local-prefix=/home/amilivojevic/s9 --with-cpu=ultrasparc --with-tune=ultrasparc --enable-languages=c $ gmake bootstrap (I know what --with-local-prefix does, and I really wanted it that way). Then, I used this temporary installation to build 64-bit gcc binary: $ CC="gcc -m64" ../configure sparc64-sun-solaris2.9 --prefix=/opt/pbl --with-local-prefix=/opt/pbl --with-cpu=ultrasparc --with-tune=ultrasparc $ gmake bootstrap The bootstraping started fine, but at one point I got "internal compiler error". This is output with '-v -save-temps added' including full command line. I'm not sure in what stage this was (but it was already using temporary 64-bit compiler binary to recompile itself): $ /home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/xgcc -v -save-temps -B/home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/ -B/opt/pbl/sparc64-sun-solaris2.9/bin/ -B/opt/pbl/sparc64-sun-solaris2.9/lib/ -isystem /opt/pbl/sparc64-sun-solaris2.9/include -isystem /opt/pbl/sparc64-sun-solaris2.9/sys-include -c -I. -I/home/amilivojevic/comp/gcc-4.0.2/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/objc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/../gcc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/../gcc/config -I../../gcc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/../include /home/amilivojevic/comp/gcc-4.0.2/libobjc/sendmsg.c -fPIC -DPIC -o .libs/sendmsg.o Reading specs from /home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/specs Target: sparc64-sun-solaris2.9 Configured with: ../configure sparc64-sun-solaris2.9 --prefix=/opt/pbl --with-local-prefix=/opt/pbl --with-cpu=ultrasparc --with-tune=ultrasparc Thread model: posix gcc version 4.0.2 /home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/cc1 -E -quiet -v -I. -I/home/amilivojevic/comp/gcc-4.0.2/libobjc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/objc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/../gcc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/../gcc/config -I../../gcc -I/home/amilivojevic/comp/gcc-4.0.2/libobjc/../include -iprefix /home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/../lib/gcc/sparc64-sun-solaris2.9/4.0.2/ -isystem /home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/include -D__arch64__ -D__sparcv9 -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -DPIC -isystem /opt/pbl/sparc64-sun-solaris2.9/include -isystem /opt/pbl/sparc64-sun-solaris2.9/sys-include /home/amilivojevic/comp/gcc-4.0.2/libobjc/sendmsg.c -mcpu=ultrasparc -mtune=ultrasparc -W -Wall -Wwrite-strings -Wstrict-prototypes -fno-strict-aliasing -fPIC -fworking-directory -O2 -O2 -fpch-preprocess -o sendmsg.i ignoring nonexistent directory "/opt/pbl/sparc64-sun-solaris2.9/include" ignoring nonexistent directory "/opt/pbl/sparc64-sun-solaris2.9/sys-include" ignoring nonexistent directory "/home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/../lib/gcc/sparc64-sun-solaris2.9/4.0.2/include" ignoring nonexistent directory "/home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/../lib/gcc/sparc64-sun-solaris2.9/4.0.2/../../../../sparc64-sun-solaris2.9/include" ignoring nonexistent directory "/opt/pbl/include" ignoring nonexistent directory "/opt/pbl/lib/gcc/sparc64-sun-solaris2.9/4.0.2/include" ignoring nonexistent directory "/opt/pbl/sparc64-sun-solaris2.9/include" #include "..." search starts here: #include <...> search starts here: . /home/amilivojevic/comp/gcc-4.0.2/libobjc /home/amilivojevic/comp/gcc-4.0.2/libobjc/objc /home/amilivojevic/comp/gcc-4.0.2/libobjc/../gcc /home/amilivojevic/comp/gcc-4.0.2/libobjc/../gcc/config ../../gcc /home/amilivojevic/comp/gcc-4.0.2/libobjc/../include /home/amilivojevic/comp/gcc-4.0.2/sol29/gcc/include /usr/include End of search list. /home/amilivojevic/comp/gcc-4.0.2/libobjc/sendmsg.c:44:1: :0: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error while bootstraping (while compiling libobjc/sendmsg.c) Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex at milivojevic dot org GCC build triplet: sparc64-sun-solaris2.9 GCC host triplet: sparc64-sun-solaris2.9 GCC target triplet: sparc64-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25602
