This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: SCO UNIX 5.0.5 with gcc 2.95.2 link problem
Dear all,
We have found the reason now. The object files producing the shared library
was not compiled with -fPIC to generate Position Independent Codes.
Thanks anyway.
Cheers!
Alex
----- Original Message -----
From: "Alex Chan" <alexchan@task.com.hk>
To: <gcc-help@gcc.gnu.org>
Cc: "StanleyYu" <stanleyyu@task.com.hk>
Sent: Wednesday, June 19, 2002 10:28 AM
Subject: SCO UNIX 5.0.5 with gcc 2.95.2 link problem
> Dear all,
>
> When we try to build shared libraries (.so) on SCO UNIX 5.0.5 with gcc
> 2.95.2, it often complains with messages similar to the following (e.g.):
>
> g++ -O -I. -I/usr/abc/isam/include -I/usr/abc/SSF/include -I/usr/abc/S
>
SF/ddf/cpp -I/usr/abc/utility -I/usr/local/include -I/usr/local/include -I/u
> s
> r/informix/incl/esql -fPIC -shared -o procf.so
> procf.o -L/usr/informix/lib -L/us
> r/informix/lib/esql `esql -libs` -linfxxa
> relocations referenced
> from file(s)
> procf.o
> /usr/lib/libnsl_s.a(t_accept.o)
> /usr/lib/libnsl_s.a(t_bind.o)
> /usr/lib/libnsl_s.a(t_connect.o)
> /usr/lib/libnsl_s.a(t_close.o)
> /usr/lib/libnsl_s.a(t_listen.o)
> /usr/lib/libnsl_s.a(t_look.o)
> /usr/lib/libnsl_s.a(t_rcv.o)
> /usr/lib/libnsl_s.a(t_rcvconnect.o)
> /usr/lib/libnsl_s.a(t_rcvdis.o)
> /usr/lib/libnsl_s.a(t_snd.o)
> /usr/lib/libnsl_s.a(t_snddis.o)
> /usr/lib/libnsl_s.a(t_unbind.o)
> /usr/lib/libnsl_s.a(t_optmgmt.o)
> /usr/lib/libnsl_s.a(t_rcvudata.o)
> /usr/lib/libnsl_s.a(t_sndudata.o)
> /usr/lib/libnsl_s.a(t_sndrel.o)
> /usr/lib/libnsl_s.a(t_rcvrel.o)
> /usr/lib/libnsl_s.a(t_alloc.o)
> /usr/lib/libnsl_s.a(t_free.o)
> /usr/lib/libnsl_s.a(t_open.o)
> /usr/lib/libnsl_s.a(t_sync.o)
> /usr/lib/libnsl_s.a(_conn_util.o)
> /usr/lib/libnsl_s.a(_utility.o)
> /usr/ccs/lib/libcrypt_i.a(crypt.o)
> /usr/ccs/lib/libcrypt_i.a(des_crypt.o)
> fatal error: relocations remain against allocatable but non-writable
> section: .
> text
>
> collect2: ld returned 1 exit status
>
>
> Does it suggest that some symbols are unresolved or what?
>
> We have solved this once (for a particular case) involving linking against
> the math library -lm which comes with an archive (.a) only on SCO. We
either
> have to instruct the linker to static link with the math library or
> reconstruct a libm.so from the archive contents to get it work.
>
> Surely this is not a good idea in general.
>
> Any advice?
>
> Thanks and Regards
>
> Alex
>
>