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 po
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 vir
On 31 May 2010, at 16:26, Matthias Klumpp wrote:
> On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe
> 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 register,
>> and th
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 Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe
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 happen?
>
> It'
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
default
