From: Boris on
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

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


From: Casper H.S. Dik on
"Boris" <boris(a)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

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.
From: Boris on
Casper H.S. Dik wrote:
> "Boris" <boris(a)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


From: Boris on
Drazen Kacar wrote:
> 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