Message-ID: <email address hidden>
Date: Sat, 17 Sep 2005 11:36:21 +0200
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: Andreas Barth <email address hidden>
Cc: <email address hidden>
Subject: Re: For i386, this issue could be clarified after release of sarge
Hi,
On mer, oct 20, 2004, Andreas Barth wrote:
> I think we don't need to discuss about non-PIC for !i386 - this would b=
e
> plainly broken. But, as you told us, on !i386 the bug is not existent
> (and looking at mips and alpha revealed no TEXTREL-section, so this
> matches). So, this is not an issue in this case (but I remarked it if a
> similar bugs happens to hit us, so that we remember in that case).
>=20
> For i386, using non-PIC in a shared lib is in general a RC bug. But, in
> this case the maintainers decision for not using it has reasons. Of
> course, we need to discuss whether there are better ways to achive it,
> without breaking policy. Implementing it as static lib comes to my mind
> for that. However, I'd like a broader discussion, including input from
> the security team, on using a static lib. Therefore, for the time scale
> of sarge, there is probably no better solution available, and I'm
> marking this bug as sarge-ignore.
After discussion with upstream, PIC versus non-PIC is something like
10% difference in performance. Upstream wondered why it would an issue
to use PIC under i386 only, so I will seek clarification on why the
policy has such a requirement. If the requirement is only there to
protect against the level of support of non-PIC under !i386, which
would be strange, then I suppose it's ok to keep shipping the lib with
non-PIC under i386.
If the policy has some other justification, PIC will be used and
static libs will always be available for end-user apps to build with so
that full performance can be achieved.
Message-ID: <email address hidden> 1?Q?Lo= EFc?= Minier <email address hidden>
Date: Sat, 17 Sep 2005 11:36:21 +0200
From: =?iso-8859-
To: Andreas Barth <email address hidden>
Cc: <email address hidden>
Subject: Re: For i386, this issue could be clarified after release of sarge
Hi,
On mer, oct 20, 2004, Andreas Barth wrote:
> I think we don't need to discuss about non-PIC for !i386 - this would b=
e
> plainly broken. But, as you told us, on !i386 the bug is not existent
> (and looking at mips and alpha revealed no TEXTREL-section, so this
> matches). So, this is not an issue in this case (but I remarked it if a
> similar bugs happens to hit us, so that we remember in that case).
>=20
> For i386, using non-PIC in a shared lib is in general a RC bug. But, in
> this case the maintainers decision for not using it has reasons. Of
> course, we need to discuss whether there are better ways to achive it,
> without breaking policy. Implementing it as static lib comes to my mind
> for that. However, I'd like a broader discussion, including input from
> the security team, on using a static lib. Therefore, for the time scale
> of sarge, there is probably no better solution available, and I'm
> marking this bug as sarge-ignore.
After discussion with upstream, PIC versus non-PIC is something like
10% difference in performance. Upstream wondered why it would an issue
to use PIC under i386 only, so I will seek clarification on why the
policy has such a requirement. If the requirement is only there to
protect against the level of support of non-PIC under !i386, which
would be strange, then I suppose it's ok to keep shipping the lib with
non-PIC under i386.
If the policy has some other justification, PIC will be used and
static libs will always be available for end-user apps to build with so
that full performance can be achieved.
Bye,
--=20
Lo=EFc Minier <email address hidden>