--- 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 suc
--- 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++ au
--- 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
--- 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 re
--- 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
--- 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
--- 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 downlo
--- 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
--- 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 n
--- 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
00
--- 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/b
--- 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
--- 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=
--- 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
--- 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 configu
--- 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
16 matches
Mail list logo
