On 02 Mar 2015, at 09:14, Victor Matuzenko wrote:
I have a (very) huge project, and compilation of a shared library
inside it fails at the linking stage:
/usr/bin/ld: </long/directory/file.o>: relocation R_X86_64_32S
against `FPC_ABSMASK_SINGLE' can not be used when making a shared
object; recompile with -fPIC
</long/directory/file.o>: could not read symbols: Bad value
How can I fix it? Should I pass -fPIC argument (and how to do this)?
You just pass this argument to the compiler (or, alternatively, -Cg,
which means the same thing). Make sure to clean all compiled code
first so that all of your units are recompiled with this option. The
standard FPC units are already compiled with this option.
On 02 Mar 2015, at 14:36, denisgolovan wrote:
AFAIK, PIC code generation is turn on by default.
On Linux/x86-64, that is only the case for units compiled via fpcmake
(such as the RTL and packages/FCL).
Are you sure you don't have an opposite problem?
Sometimes when you have asm code written with hard-coded offsets you
can get a module which can't be PIC-compiled.
See fpc -h params for _disabling_ PIC code generation.
He gets an error from the linker stating that a dynamic library cannot
contain that kind of relocation. Those relocations are created for non-
PIC code. Disabling the generation of PIC code cannot solve that issue.
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
