Hi!
If I run an application which uses a library developed with FPC on a x86
plattform, the program gets killed by SELinux because of text relocations
inside of the library.
A quick check which eu-findtextrels found a lot of those in the lib.
Exactly the same code compiled for 64bit does not
On 31 May 2010, at 14:23, Matthias Klumpp wrote:
A quick check which eu-findtextrels found a lot of those in the lib.
Exactly the same code compiled for 64bit does not contain any text
relocation.
How can this happen?
It's because we don't generate PIC (position-independent code) by
On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
On 31 May 2010, at 14:23, Matthias Klumpp wrote:
A quick check which eu-findtextrels found a lot of those in the lib.
Exactly the same code compiled for 64bit does not contain any text
relocation.
How can this
In our previous episode, Matthias Klumpp said:
On x86-64, there is almost no penalty for PIC vs no PIC.
You have to recompile the entire RTL and your own code with the -Cg
compiler option to get shared libraries that only contain PIC.
Then it's up to red Hat to fix this in FPC or in
On 31 May 2010, at 16:26, Matthias Klumpp wrote:
On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
It's because we don't generate PIC (position-independent code) by
default on Linux-i386, because
a) PIC is fairly inefficient on i386 (it requires an extra
According to SELinux, this is a security issue..
I guess that it may prevent some address space randomization features. I very
much doubt that it opens up security holes by itself though.
The .so should be still relocatable? The point about pic is that one
page can be mapped on different
On 31 May 2010, at 20:29, Florian Klaempfl wrote:
According to SELinux, this is a security issue..
I guess that it may prevent some address space randomization features. I
very much doubt that it opens up security holes by itself though.
The .so should be still relocatable? The point
