[Bug other/28377] New: unresolved symbols in libstdc++, shared lib link strategy of libgcc.a
These are two related problems. The most obvious one is that when building
libstdc++.so (don't mind the renaming, I want to isolate our gcc installation
from other tools that have their own libstdc++.so and set LD_LIBRARY_PATH,
because they are too stupid to use -rpath in their software) and I run
ldd -r -v .../libstdc++.so I get these unresolved symbols:
symbol not found: _Unwind_Resume (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __ctzsi2 (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __eprintf (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __umoddi3 (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __udivdi3 (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_DeleteException
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetTextRelBase
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetRegionStart
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetDataRelBase
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_SetGR (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_SetIP (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found:
_Unwind_GetLanguageSpecificData(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetIP (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_RaiseException
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_Resume_or_Rethrow
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
These symbols are obviously not part of libgcc_s.so, but some of them can be
found in:
nm /opt/gcc_4.0.3/solaris8/lib/gcc/sparc-sun-solaris2.8/4.0.3/libgcc.a | ggrep
-E '_Unwind_|__ctzsi2|__eprintf|__umoddi3|__udivdi3'
[12]| 8| 228|FUNC |GLOB |0|5 |__ctzsi2
[14]| 8| 72|FUNC |GLOB |0|5 |__eprintf
[13]| 8| 916|FUNC |GLOB |0|5 |__udivdi3
[13]| 8| 948|FUNC |GLOB |0|5 |__umoddi3
and the _Unwind in libsupc++.a. So far it is clear - but is this allowed? When
I build a C++ executable, which is linked against -lstdc++, how is this
executable supposed to find the missing symbols? My belief is up to now that a
shared object can only have unresolved symbols agaist other shared libs (which
it depends on) - but not against static ones.
The other (but related) problem is this: when I compile source code with
assert.h, I requently get errors at runtime that __eprintf is not found. This
does not happen when the executable is linked with gcc, since this passes
"-lgcc_s -lgcc" to the linker. But when building shared libraries (gcc
-shared), then only -lgcc_s is supplied (see the "specs" file:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s-IFX -lgcc}}%{shared:-lgcc_s-IFX}}}
) and the shared lib has unresolved dependencies on __eprintf. So basically
this could be the root cause of the libstdc++ trouble above - wouldn't it be
correct to link shared libs with "-lgcc_s -lgcc" as well, to avoid that the
shared object will have the unresolved dependency on __eprintf?
I looked at Bug 15253 and Bug 15527, but that did not seem to give an answer to
the questions above.
On Linux (RedHat Enterprise Linux 3.0) this looks totally different: All the
symbols above (__ctzsi2 __udivdi3 __umoddi3) are in libgcc_s.so, __eprintf is
in libgcc.a, and the libstdc++.so only has the unresolved symbols _Unwind_*,
but no others.
Let me know if you need more information.
-Marek
--
Summary: unresolved symbols in libstdc++, shared lib link
strategy of libgcc.a
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marek dot rouchal at infineon dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377
[Bug other/28377] unresolved symbols in libstdc++, shared lib link strategy of libgcc.a
--- Comment #2 from marek dot rouchal at infineon dot com 2006-07-14 09:08 --- The test case is the build of gcc 4.0.3 on Solaris 8, including the libstdc++.so build. When done, run env LD_LIBRARY_PATH= ldd -r -v .../libstdc++-IFX.so and you will see __eprintf unresolved. I will try to put together a test case to build a shared lib from C source code that contains #include and some assertion to demonstrate the the resulting libXXX.so has an unresolved reference to __eprintf. One more comment: The libstdc++ on Solaris does not have the RUNPATH compiled in to find the libgcc_s.so, so that is why the _umoddi etc. symbols are not found. So when running env LD_LIBRARY_PATH=/opt/gcc_4.0.3/solaris8/lib ldd -r -v /opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so I only get the __eprintf unresolved symbol. So the difference between Solaris and Linux is really that on Solaris there is __eprintf unresolved in libstdc++.so. And I noticed another difference: On Solaris, my gcc is using the Solaris ld linker, and the collect2 call contains (gcc -shared) only -lgcc_s, whereas on Linux (where GNU ld is used) it contains: -lgcc --as-needed -lgcc_s-IFX --no-as-needed -lc -lgcc --as-needed -lgcc_s-IFX --no-as-needed so link first with the static libgcc.a, then with the shared gcc_s. I failed to figure out where and how the link lib list is constructed within gcc (i.e., how the collect2 command line is put together), so I do not know how to compare that between Solaris and Linux. -Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377
[Bug other/28377] unresolved symbols in libstdc++, shared lib link strategy of libgcc.a
--- Comment #4 from marek dot rouchal at infineon dot com 2006-07-14 11:03 --- I think I have found the root cause - there is indeed a /usr/local/include/assert.h on my system. However, I was not aware that /usr/local/include is being searched by default! So I will recompile (bootstrap) gcc-4.0.3 again, and make sure that LOCAL_INCLUDE_DIR is undefined (if some user wants the &@#&$ in there, she can always add -I/usr/local/include). Please do not close this ticket now, I will update it with the outcome of the new build. Stay tuned, and many thanks so far! -Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377
[Bug other/28377] unresolved symbols in libstdc++, shared lib link strategy of libgcc.a
--- Comment #5 from marek dot rouchal at infineon dot com 2006-07-14 14:01 --- Ok, the compile is done. In gcc/Makefile.in, I changed -DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \ to -ULOCAL_INCLUDE_DIR \ so that /usr/local/include is NOT searched by default by the preprocessor. This way I do not source the evil assert.h in that path, and everything now works smoothly - the __eprintf is gone from libstdc++.so, and I do not see this popping up in any other compiles - as I do not search /usr/local/include any more. So all is fine now. Suggestions: - make the assert.h/__eprintf trouble a FAQ: "Whenever you see an unresolved symbol __eprintf, this most likely means that you have an old and buggy assert.h in some of your include directories. Note that cpp has some built-in search paths that you may need to consider as well, like /usr/local/include" - remove /usr/local/include from the standard include file search path; only the _real_ standard locations for the platform (/usr/include) should be considered, anything else should be up to the user - and it is easy (-I/usr/local/include) Thanks for your quick help, Marek -- marek dot rouchal at infineon dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377
[Bug other/28377] unresolved symbols in libstdc++, shared lib link strategy of libgcc.a
--- Comment #7 from marek dot rouchal at infineon dot com 2006-07-17 07:56 --- Subject: RE: unresolved symbols in libstdc++, shared lib link strategy of libgcc.a Using --with-local-prefix="something" may work ok, but what I want is --without-local-prefix, and that does not work as I expect (just tried with gcc-4.0.3); the expected behaviour would be the one achieved with the patch below: no additional "local" search directory for includes. Thanks for your patience, Marek > --- Comment #6 from ebotcazou at gcc dot gnu dot org > 2006-07-14 14:08 --- > > Ok, the compile is done. In gcc/Makefile.in, I changed > > -DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \ > > to > > -ULOCAL_INCLUDE_DIR \ > > so that /usr/local/include is NOT searched by default by > the preprocessor. > > The preferred method is to pass --with-local-prefix on the > configure line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377
[Bug bootstrap/35531] Assembler failure while compiling libgcc
--- Comment #11 from marek dot rouchal at infineon dot com 2009-07-01 11:58 --- (In reply to comment #2) > and did get farther, but the final link fails like > ... > ld: fatal: unwind table: file > /home/bfriesen/build/gcc-4.3.0/./gcc/amd64/crtend.o: section .eh_frame: bad > cie > version 0: offset 0xfd7fffdfb220 I saw this, too with gcc-4.3.2 on Solaris 10 x86. The issue is described also in Bug 33100, which seems to be fixed in gcc-4.3.3. Furthermore, the linker error is supposed to be fixed with a Sun/Solaris patch: 139574-03 for SPARC and 139575-03 for x86 (quoted from Bug 33100). -Marek -- marek dot rouchal at infineon dot com changed: What|Removed |Added CC| |marek dot rouchal at | |infineon dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35531
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #7 from marek dot rouchal at infineon dot com 2009-07-02 11:46 --- (In reply to comment #5) > What you want is --with-cpu=default32 for x86_64 which does not exist yet. It > does for powerpc64 though. I'd like to ping this request once again - it seems that there was no progress on this. The requirement actually is as follows: When building gcc on x86_64 (amd64), currently the resulting gcc (and g++, gfortran etc.) binaries are 64bit. This is unlike Solaris, where the binaries are 32bit. On both platforms, gcc is able to produce 32bit and 64bit binaries (thanks to the multilib support). For a network installation of gcc, with 32bit (i686) and 64bit (x86_64) Linux hosts it would be preferable, if the gcc binaries were 32bit - then gcc would run on both CPU types; and on the x86_64 systems, it would be able to build 64bit binaries with -m64. So far I have not found a way to pass -m32 selectively through the gcc bootstrap process such that the gcc (g++, gfortran, ...) binaries would be 32bit, while the multilib support would remain as is. Any hints are appreciated. Many thanks, Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #9 from marek dot rouchal at infineon dot com 2009-07-02 13:52 --- (In reply to comment #8) > For a 32-bit-default compiler that can also build 64-bit code, configure > for i686-pc-linux-gnu with --enable-targets=all. (Set CC="gcc -m32" > and CC_FOR_BUILD="gcc -m32" in your environment and configure > --enable-targets=all --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu > --target=i686-pc-linux-gnu.) This is implemented in 4.3 and later. I tried this - and it does not work here. I even added STAGE1_CFLAGS="-m32 -g" as suggested in an earlier comment. The build of gcc-4.3.2 bails out at this point: gmake[7]: Leaving directory `/var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/gcc' mkdir -p -- i686-pc-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in i686-pc-linux-gnu/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-lipo... lipo checking for i686-pc-linux-gnu-nm... /var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/nm checking for i686-pc-linux-gnu-ranlib... ranlib checking for i686-pc-linux-gnu-strip... strip checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... /var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/xgcc -B/var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/bin/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/lib/ -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/include -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. The relevant portion of the gcc-4.3.2/i686-pc-linux-gnu/libgcc/config.log is: configure:2398: /var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/xgcc -B/var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/bin/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/lib/ -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/include -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/sys-include -o conftest -g -fkeep-inline-functions -Wl,-rpath,/opt/gcc_4.3.2/linux40_64/ext/lib conftest.c >&5 /tmp/ccIIK43d.s: Assembler messages: /tmp/ccIIK43d.s:19: Error: suffix or operands invalid for `push' /tmp/ccIIK43d.s:21: Error: suffix or operands invalid for `push' /tmp/ccIIK43d.s:25: Error: suffix or operands invalid for `push' /tmp/ccIIK43d.s:30: Error: suffix or operands invalid for `pop' /tmp/ccIIK43d.s:31: Error: suffix or operands invalid for `pop' I assume that the -m32 option is not passed through correctly. I think that in gcc-4.3.2/Makefile the HOST_EXPORTS macro does not contain the appropriate CFLAGS. Or is this perhaps fixed in gcc-4.3.3? -- marek dot rouchal at infineon dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||4.3.2 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #11 from marek dot rouchal at infineon dot com 2009-07-09 14:48 --- (In reply to comment #10) Thank you very much! I can confirm now that with the given information I was able to compile on a x86_64 Linux box a gcc-4.3.3 with all executables (gcc, cc1, ...) built in 32bit, plus the libgcc_s.so and libstdc++.so in both 32 and 64bit. May I suggest to add a note on this to the INSTALL document, in the section on x86_64? Here is a rough proposal for the text, please feel free to edit: On x86_64 gcc will bootstrap by default to 64bit binaries. You can force the build of 32bit gcc binaries, such that the resulting gcc will also be executable on 32bit CPUs; this requires i686-pc-linux-gnu binutils (configured with --enable-64-bit-bfd) to be present in the path where gcc is going to be installed. The gcc bootstrap process then has to be configured with: CC="gcc -m32" CC_FOR_BUILD="gcc -m32" ./configure --enable-targets=all --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu -- marek dot rouchal at infineon dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #6 from marek dot rouchal at infineon dot com 2005-10-24 06:26 --- Subject: RE: --with-cpu=default32 for x86_64 > What you want is --with-cpu=default32 for x86_64 which does > not exist yet. It does for powerpc64 though. This is also correct. It would be sufficient for me, if the bootstrapped compiler was all 32bit, but still would produce by default 64bit binaries. The changed scope of the request is however fine as well. -Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug bootstrap/22073] build a 32bit gcc-3.4.4 on AMD64/Opteron Linux
--- Additional Comments From marek dot rouchal at infineon dot com 2005-07-01 09:04 --- (In reply to comment #1) > Can you try the following: > CFLAGS="-m32 -O2 -g" BOOT_CFLAGS="-m32 -O2 -g" STAGE1_CFLAGS="-m32 -g" I spent some more thoughts on this: My desired result could be achieved by doing this: - bootstrap normally and install - bootstrap (again) with the macros above, but install only the gcc binary I am wondering whether this could not be automated in a sensible way. As far as I was able to trace through the configure/Makefile.in files, I think I have found a possible solution (did not try it yet, so can't send a patch right now): When building the stage2/3 compiler, libgcc and libiberty needs to be rebuilt with the stage1/2 compiler - however these libs do not "see" the BOOT_CFLAGS. CFLAGS_FOR_TARGET is not appropriate either, since that influences the multilib setup when building the runtime libs. Maybe this hint is enough for a gcc bootstrap expert to fix the top-level configure and Makefile.in such that BOOT_CFLAGS are passed through to libgcc/libiberty when bootstrapping the compilers, but not when building the runtime libs (libgcc.a, libgcc_s.so, libstdc++.a, libstdc++.so, ...) - these are dependent on the multilib setup, which is ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug bootstrap/22073] New: build a 32bit gcc-3.4.4 on AMD64/Opteron Linux
I would like to build a gcc/3.4.4 installation on RedHat Enterprise Linux 3.0
(AMD64 - Opteron hardware), in which the gcc binaries are 32bit, such that this
gcc installation would also be usable on 32bit (x86) hardware.
I tried all sorts of BOOT_CFLAGS=-m32 and/or CFLAGS_FOR_TARGET=-m32,
unfortunately to no avail, as the default of "make bootstrap" is to build 64bit
binaries on x86_64-unknown-linux-gnu.
The actual problem seems to be libiberty, which does not "see" the -m32 option
when building the stage1 compiler.
I hope this is not a FAQ - I did not find anything so far. And I am not saying
this is necessarily a bug, maybe I just did not find the correct set of macros.
Thanks,
Marek
--
Summary: build a 32bit gcc-3.4.4 on AMD64/Opteron Linux
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marek dot rouchal at infineon dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
