[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 06:59 --- First of all, thank you all for the suggestions. libstdc++'s configure contains the docs for --with-pic: I'm sorry, I'm not a gcc configuration guru :), and all that I was doing was building gcc via its configure + make, according to the published instructions. Could you please give me a hint. On what stage of gcc build process can I pass this option? Isn't the process of libstdc++ build a part of the entire gcc build? Should I pass --with-pic to gcc configure's command line? Does it change anything if you build libq.so with -mimpure-text? I'd be happy to try if you'd tell me where to switch this option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 07:15 --- I'd be happy to try if you'd tell me where to switch this option g++ -m64 -fPIC q.cpp -shared -mimpure-text -o libq.so -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 07:19 --- I'd be happy to try if you'd tell me where to switch this option g++ -m64 -fPIC q.cpp -shared -mimpure-text -o libq.so It doesn't help -- the same problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 07:23 --- Eric, maybe you can tell me more how/where to apply this --with-pic option? I was googling myself, but found nothing about this option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 07:27 --- It doesn't help -- the same problem OK. To further confirm the diagnostic, you could run readelf -r on libq.so and find out where this R_SPARC_WDISP30 relocation comes from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 07:33 --- readelf -r libq.so | grep R_SPARC_WDISP30gives the following: a73c 004f0007 R_SPARC_WDISP30 abort + 0 a764 004f0007 R_SPARC_WDISP30 abort + 0 a890 004f0007 R_SPARC_WDISP30 abort + 0 ab70 004f0007 R_SPARC_WDISP30 abort + 0 b234 004f0007 R_SPARC_WDISP30 abort + 0 b244 004f0007 R_SPARC_WDISP30 abort + 0 cd04 004f0007 R_SPARC_WDISP30 abort + 0 cd48 004f0007 R_SPARC_WDISP30 abort + 0 cd6c 004f0007 R_SPARC_WDISP30 abort + 0 cde4 004f0007 R_SPARC_WDISP30 abort + 0 a754 00850007 R_SPARC_WDISP30 00012a20 _Unwind_GetTextRelBase + 0 a76c 00360007 R_SPARC_WDISP30 00012a30 _Unwind_GetRegionStart + 0 aa38 00360007 R_SPARC_WDISP30 00012a30 _Unwind_GetRegionStart + 0 a774 00ad0007 R_SPARC_WDISP30 00012a28 _Unwind_GetDataRelBase + 0 acc8 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 acec 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 b1f4 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 b204 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 b23c 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 b3cc 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 b438 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 cd5c 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 cd74 008a0007 R_SPARC_WDISP30 b720 __cxa_begin_catch + 0 ace4 008c0007 R_SPARC_WDISP30 b284 _ZN10__cxxabiv112__une + 0 b2b4 008c0007 R_SPARC_WDISP30 b284 _ZN10__cxxabiv112__une + 0 acf4 007a0007 R_SPARC_WDISP30 ba68 __cxa_get_globals_fast + 0 b7d4 007a0007 R_SPARC_WDISP30 ba68 __cxa_get_globals_fast + 0 ad6c 00920007 R_SPARC_WDISP30 b580 __cxa_allocate_excepti + 0 ada8 00750007 R_SPARC_WDISP30 b340 __cxa_throw + 0 adb0 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 adb8 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 b214 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 b24c 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 cd64 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 cddc 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 cdec 0057 R_SPARC_WDISP30 b7d0 __cxa_end_catch + 0 adc0 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 b21c 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 b254 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 b56c 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 b70c 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 b7bc 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 badc 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 bc88 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 cdf4 005f0007 R_SPARC_WDISP30 00014828 _Unwind_Resume + 0 adc8 009d0007 R_SPARC_WDISP30 b228 _ZN10__cxxabiv111__ter + 0 b1fc 009d0007 R_SPARC_WDISP30 b228 _ZN10__cxxabiv111__ter + 0 b278 009d0007 R_SPARC_WDISP30 b228 _ZN10__cxxabiv111__ter + 0 b334 009d0007 R_SPARC_WDISP30 b228 _ZN10__cxxabiv111__ter + 0 add0 00260007 R_SPARC_WDISP30 b3e0 __cxa_rethrow + 0 cca0 00260007 R_SPARC_WDISP30 b3e0 __cxa_rethrow + 0 ccc0 00260007 R_SPARC_WDISP30 b3e0 __cxa_rethrow + 0 ae78 009c0007 R_SPARC_WDISP30 00012d74 _Unwind_SetGR + 0 ae8c 009c0007 R_SPARC_WDISP30 00012d74 _Unwind_SetGR + 0 ae9c 00760007 R_SPARC_WDISP30 00012dd0 _Unwind_SetIP + 0 af14 00890007 R_SPARC_WDISP30 00012dd8 _Unwind_GetLanguageSpe + 0 af58 00280007 R_SPARC_WDISP30 00012dc8 _Unwind_GetIP + 0 b1e4 00220007 R_SPARC_WDISP30 b29c _ZSt10unexpectedv + 0 b1ec 00530007 R_SPARC_WDISP30 b260
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 07:57 --- readelf -r libq.so | grep R_SPARC_WDISP30gives the following: OK, the fundamental problem is that you're trying to build shared libraries with a compiler configured with --disable-shared. That's not really intended (and might cause problems for exception propagation in C++). The fix is indeed to recompile every GCC library with -fPIC. Try to configure at toplevel --with-pic, but I'm not sure the option is valid there. Otherwise you'll need to specifically configure libstdc++-v3 --with-pic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 08:15 --- OK, the fundamental problem is that you're trying to build shared libraries with a compiler configured with --disable-shared. That's not really intended (and might cause problems for exception propagation in C++). We must link our .so statically with all the gcc stuff to make sure it runs on every Solaris. Shipping libstd++.so with our shared library is not very suitable for us, because it makes product download size bigger. Without --disable-shared we had other problems linking 64 bit code statically. Anyway, option --disable-shared exists, and is documented. So it should either properly work (for platforms it is supported for), or be dropped (for platforms where it is not supported). While there's nothing said it is not supported for Solaris, all its improper work is a bug, and nothing but a bug. Isn't it? :) The fix is indeed to recompile every GCC library with -fPIC. Try to configure at toplevel --with-pic, but I'm not sure the option is valid there. Otherwise you'll need to specifically configure libstdc++-v3 --with-pic. Thank you for the suggestion. I'll try it now, and will let you know whether it helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 09:05 --- We must link our .so statically with all the gcc stuff to make sure it runs on every Solaris. Shipping libstd++.so with our shared library is not very suitable for us, because it makes product download size bigger. 5 MB uncompressed for 32-bit, 6 MB uncompressed for 64-bit! Anyway, option --disable-shared exists, and is documented. So it should either properly work (for platforms it is supported for), or be dropped (forplatforms where it is not supported). While there's nothing said it is not supported for Solaris, all its improper work is a bug, and nothing but a bug. Isn't it? :) There is nothing wrong in the current behavior of --disable-shared: it builds static libraries the way static libraries should be built. Your practice of building shared libraries with a compiler configured with --disable-shared looks far more questionable to me; if I were to change something, I'd simply reject -shared in that case. Note for example that a shared libgcc is required on Solaris for exception propagation accross shared libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 09:25 --- 5 MB uncompressed for 32-bit, 6 MB uncompressed for 64-bit! Of course it's not a show stopper, but given 2-3M total packed size of the distribution, we'd prefer not to double it. Furthermore, the approach always worked for 32 bit. There is nothing wrong in the current behavior of --disable-shared: it builds static libraries the way static libraries should be built. Your practice of building shared libraries with a compiler configured with --disable-shared looks far more questionable to me; if I were to change something, I'd simply reject -shared in that case. Note for example that a shared libgcc is required on Solaris for exception propagation accross shared libraries. Actually, instead of --disable-shared we were successfully using gcc compiled without this flag, specifing appropriate *.a on linking stage. --disable-shared only makes compile [command line] more straightforward, not letting compiler using .so's instead. There's absolutely nothing illegal in static linking with a shared library other libraries that it uses. The intention is to make resulting shared library loadable on every target machine with no regard to availablity of shared libraries, and make the library as small as possible. The approach works fine for 32 bit on Solaris. And it is definetely a bug that it doesn't do so for 64 bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 09:46 --- Adding --with-pic to the command line of gcc's configure helped. Thanks a lot, Eric! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 09:54 --- There's absolutely nothing illegal in static linking with a shared library other libraries that it uses. The intention is to make resulting shared library loadable on every target machine with no regard to availablity of shared libraries, and make the library as small as possible. Indeed, except that if the static libraries are not compiled with -fPIC, your shared library is only shared on disk, not in memory. The approach works fine for 32 bit on Solaris. And it is definetely a bug that it doesn't do so for 64 bit. It works only by accident in 32-bit mode; it would fail if the R_SPARC_WDISP30 relocation was slightly different. And, again, not using a shared libgcc on Solaris means that exceptions cannot be propagated across shared libraries; that's why g++ automatically passes -shared-libgcc on Solaris. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 09:58 --- Adding --with-pic to the command line of gcc's configure helped. Great, but now you know my position on this mess. :-) Thanks a lot, Eric! Andrew deserves them too. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From info at yourkit dot com 2005-05-02 11:10 --- Thanks a lot, Eric! Andrew deserves them too. No doubt :) I'm sorry. And, again, not using a shared libgcc on Solaris means that exceptions cannot be propagated across shared libraries; that's why g++ automatically passes -shared-libgcc on Solaris. Just curious: where can I get more information about this issue? We were linking our shared library statically with libgcc_eh.a in the past with no problems, and many people on different machines successfully used it. Should there be any problems? By the way, all these tricks were found googling reports of other people who wanted to link statically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02 15:53 --- Just curious: where can I get more information about this issue? We were linking our shared library statically with libgcc_eh.a in the past with no problems, and many people on different machines successfully used it. Should there be any problems? Theoritically there should be exactly one EH machinery linked in the executable, hence the need for one shared libgcc when there are other shared libraries involved. In practice, if only one shared library has its private EH machinery and if others don't, that may still work. See in the manual the section about -shared-libgcc/-static-libgcc. By the way, all these tricks were found googling reports of other people who wanted to link statically. We should probably add links to Google in the manual. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
[Bug target/21277] Runtime error with C++ shared library and --disable-shared
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-30 20:46 --- Andrew is right, this error usually means that a shared library contains code that has not been compiled with -fPIC. The Solaris 64-bit runtime linker doesn't seem to be able to cope with this (unlike the 32-bit one). Does it change anything if you build libq.so with -mimpure-text? -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|critical|normal Component|c++ |target GCC build triplet||sparc64-sun-solaris2.* GCC host triplet||sparc64-sun-solaris2.* GCC target triplet||sparc64-sun-solaris2.* Priority|P3 |P2 Summary|gcc 4.0 fails to statically |Runtime error with C++ |link on Solaris SPARC 64 bit|shared library and -- ||disable-shared http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
