Unix Programming - Non-PIC objects in shared lib still works?

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > July 2007 > Non-PIC objects in shared lib still works?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Non-PIC objects in shared lib still works?
Michael B Allen

2007-07-26, 7:19 am

Hi all,

I've been linking a bunch of .a files into one big shared .so which
worked great.

But trying to link on x86_64 I got the following:

relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC ...libfoo.a: could not read
symbols: Bad value

I added -fPIC to the necessary Makefiles and appended CFLAGS="-fPIC" to
configure for various packages. Now everthing links fine (but I haven't
tried the code yet - knock on wood).

It makes perfect sense to me that the .o files in the .a archives should
be compiled with -fPIC if they are to be used to build a .so.

But now I'm very curious as to why my code worked *before*.

Can someone explain to me how .o files compiled *without* -fPIC could
be bundled into a .so and used by applications without error?

Just trying to understand these things better,
Mike
Måns Rullgård

2007-07-26, 7:19 am

Michael B Allen <ioplex@gmail.com> writes:

> Hi all,
>
> I've been linking a bunch of .a files into one big shared .so which
> worked great.
>
> But trying to link on x86_64 I got the following:
>
> relocation R_X86_64_32 against `a local symbol' can not be used when
> making a shared object; recompile with -fPIC ...libfoo.a: could not read
> symbols: Bad value
>
> I added -fPIC to the necessary Makefiles and appended CFLAGS="-fPIC" to
> configure for various packages. Now everthing links fine (but I haven't
> tried the code yet - knock on wood).
>
> It makes perfect sense to me that the .o files in the .a archives should
> be compiled with -fPIC if they are to be used to build a .so.
>
> But now I'm very curious as to why my code worked *before*.
>
> Can someone explain to me how .o files compiled *without* -fPIC could
> be bundled into a .so and used by applications without error?


Shared libs need PIC on x86-64, or more accurately, relocatable code
has to be PIC. This is because a 32-bit immediate address operand
used in the code might need more than 32 bits after relocation. If
this happens, there is nowhere to write the new value. Theoretically,
it would be possible to generate non-PIC code without using the
troublesome 32-bit immediate operands, but to my knowledge no compiler
does this.

--
Måns Rullgård
mans@mansr.com
Michael B Allen

2007-07-26, 7:20 pm

On Thu, 26 Jul 2007 09:30:33 +0100
M=E5ns Rullg=E5rd <mans@mansr.com> wrote:

> Michael B Allen <ioplex@gmail.com> writes:
>=20
to[vbcol=seagreen]
>=20
> Shared libs need PIC on x86-64, or more accurately, relocatable code
> has to be PIC. This is because a 32-bit immediate address operand
> used in the code might need more than 32 bits after relocation. If
> this happens, there is nowhere to write the new value. Theoretically,
> it would be possible to generate non-PIC code without using the
> troublesome 32-bit immediate operands, but to my knowledge no compiler
> does this.


Hi Mans,

Very good explaination. That clears it up well.

Thanks,
Mike
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com