ld: fatal: relocations remain against allocatable but non-writable sections
Boris
successfully compile the whole source code (with g++ 3.4.6) I can not link
currently (I try to build a shared object). I tracked down the problem to
one object file. This simple command causes problems:
$g++ -shared -o libfoo.so foo.o
Text relocation remains referenced
against symbol offset in file
<unknown> 0x8 foo.o
<unknown> 0xc foo.o
<unknown> 0x1c foo.o
<unknown> 0x24 foo.o
ld: fatal: relocations remain against allocatable but non-writable sections
There are some hundreds of other object files which I can link successfully.
However one object file causes problems. Does anyone have any idea what the
error message means and where I should look now for a solution?
Thanks in advance,
Boris
Boris
I found out meanwhile that the problem is caused by the "-z text" option
which is passed by g++ to the linker. If I use the linker myself and leave
out "-z text" I can link successfully. I will try to understand now what
this option means and why it causes a problem with one object file but not
with all the others (the application has been developed in standard C++ and
can be built currently with VC++ 2005 on Windows and g++ 3.4.6 on Linux). I
appreciate any explanations or hints where to look at.
Thanks,
Boris
Casper H.S. Dik
>I'm porting a Linux application to Solaris 10/Sparc. While I can
>successfully compile the whole source code (with g++ 3.4.6) I can not link
>currently (I try to build a shared object). I tracked down the problem to
>one object file. This simple command causes problems:
>$g++ -shared -o libfoo.so foo.o
> Text relocation remains referenced
> against symbol offset in file
><unknown> 0x8 foo.o
><unknown> 0xc foo.o
><unknown> 0x1c foo.o
><unknown> 0x24 foo.o
>ld: fatal: relocations remain against allocatable but non-writable sections
The code in foo.o is not PIC; it needs to be compiled with -fpic or -fPIC
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Casper H.S. Dik
>I found out meanwhile that the problem is caused by the "-z text" option
>which is passed by g++ to the linker. If I use the linker myself and leave
>out "-z text" I can link successfully. I will try to understand now what
>this option means and why it causes a problem with one object file but not
>with all the others (the application has been developed in standard C++ and
>can be built currently with VC++ 2005 on Windows and g++ 3.4.6 on Linux). I
>appreciate any explanations or hints where to look at.
Removing -ztext will cause the library to be fixed up at runtime;
that means it's no longer shared.
Boris
> "Boris" <bo...@gtemail.net> writes:
>
>> I'm porting a Linux application to Solaris 10/Sparc. While I can
>> successfully compile the whole source code (with g++ 3.4.6) I can
>> not link currently (I try to build a shared object). I tracked down
>> the problem to one object file. This simple command causes problems:
>
>> $g++ -shared -o libfoo.so foo.o
>> Text relocation remains referenced
>> against symbol offset in file
>> <unknown> 0x8 foo.o
>> <unknown> 0xc foo.o
>> <unknown> 0x1c foo.o
>> <unknown> 0x24 foo.o
>> ld: fatal: relocations remain against allocatable but non-writable
>> sections
>
> The code in foo.o is not PIC; it needs to be compiled with -fpic or
> -fPIC
The whole code has been compiled with -fPIC. That helped me to get around
some other problems already although as far as I know it shouldn't be
required to compile with -fPIC in general (or is there a strict requirement
on Solaris?).
Boris
Boris
> "Boris" <bo...@gtemail.net> writes:
>
>> I found out meanwhile that the problem is caused by the "-z text"
>> option which is passed by g++ to the linker. If I use the linker
>> myself and leave out "-z text" I can link successfully. I will try
>> to understand now what this option means and why it causes a problem
>> with one object file but not with all the others (the application
>> has been developed in standard C++ and can be built currently with
>> VC++ 2005 on Windows and g++ 3.4.6 on Linux). I appreciate any
>> explanations or hints where to look at.
>
> Removing -ztext will cause the library to be fixed up at runtime;
> that means it's no longer shared.
But what do I have to do to link with -ztext? The man page says that -ztext
"forces a fatal error if any relocations against non-writable, allocatable
sections remain". Is there a list of things to look for in C++ code which
you must avoid or code in a proper way? There are some examples at
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p24.html but
are they complete?
Boris
Casper H.S. Dik
>Boris
No need to change your code; just change the compiler options.
Drazen Kacar
> Casper H.S. Dik wrote:
> > The code in foo.o is not PIC; it needs to be compiled with -fpic or
> > -fPIC
>
> The whole code has been compiled with -fPIC.
Perhaps there is a hand written assembly in there which is not PIC.
> That helped me to get around some other problems already although as
> far as I know it shouldn't be required to compile with -fPIC in
> general (or is there a strict requirement on Solaris?).
No, I suppose g++ added -ztext to the linker invocation. That flag
forces the kind of errors you're seeing.
You can try adding -v to the g++ invocation and it will show all
commands it executes. The last one (collect2) is the wrapper around the
system linker and it passes its command line arguments to it.
If there is -ztext in there you can either try to remove it from gcc's
specs file or add -Wl,-ztextoff to the compiler invocation. That might
work if it gets in the linker line after -ztext.
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr
Boris
> Boris wrote:
>> Casper H.S. Dik wrote:
>
>>> The code in foo.o is not PIC; it needs to be compiled with -fpic or
>>> -fPIC
>>
>> The whole code has been compiled with -fPIC.
>
> Perhaps there is a hand written assembly in there which is not PIC.
It's actually just C++ code. I'm currently trying to find out though what's
so special about the one which causes problems.
>> That helped me to get around some other problems already although as
>> far as I know it shouldn't be required to compile with -fPIC in
>> general (or is there a strict requirement on Solaris?).
>
> No, I suppose g++ added -ztext to the linker invocation. That flag
> forces the kind of errors you're seeing.
>
> You can try adding -v to the g++ invocation and it will show all
> commands it executes. The last one (collect2) is the wrapper around
> the system linker and it passes its command line arguments to it.
>
> If there is -ztext in there you can either try to remove it from gcc's
> specs file or add -Wl,-ztextoff to the compiler invocation. That might
> work if it gets in the linker line after -ztext.
I tried the latter one already:
ld: fatal: option -ztextoff and -ztext are incompatible
I will try to understand why the linker chokes on the one object file. If it
takes too much time I might simply use the linker myself without -ztext.
Boris
Paul Pluzhnikov
> But what do I have to do to link with -ztext?
You need to compile your code as position-independent.
For gcc/g++, add -fPIC to all compile lines.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.