[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#172078: marked as done ([new check] check for PIC code in .a libraries)

Your message dated Sat, 29 Apr 2017 20:03:00 +0000
with message-id <a3fe9aab-f73e-dbad-a2c7-f32251d599f6@thykier.net>
and subject line Re: lintian: suggest test for PIC in .a
has caused the Debian Bug report #172078,
regarding [new check] check for PIC code in .a libraries
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
172078: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172078
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: lintian
Version: 1.22.2
Severity: wishlist

I'd like to propose a test for PIC code in .a libraries, as per policy
11.2.

On i386 this is just a matter of grepping for _GLOBAL_OFFSET_TABLE_ in
the "nm" output.  Unfortunately I'm not sure if the same is true on
other CPUs.  Restricting the test to i386, at least initially, would
be better than nothing I guess.

I'm also not sure, unfortunately, where to tie it into the existing
lintian checks.  But pic-a.pl below illustrates the idea, just running
over /usr/lib/*.a.

/usr/lib/libc_nonshared.a is an exception to this test, it's correct
for it to be PIC.  I guess libc6 can have an override for that, since
that oddity is specific to it.

I believe xfree86 has some oddities related to the second remark in
the .desc, but I don't know the full story.

Otherwise, on my system electric-fence is the only genuine current
case, the rest are the libtool bug per the first remark in the .desc,
as far as I can tell.

Attachment: pic-a.pl
Description: Perl program

Attachment: pic-a.desc
Description: Binary data


--- End Message ---
--- Begin Message --- 
On Sat, 07 Dec 2002 10:01:50 +1000 Kevin Ryde <user42@zip.com.au> wrote:
> Package: lintian
> Version: 1.22.2
> Severity: wishlist
> 
> I'd like to propose a test for PIC code in .a libraries, as per policy
> 11.2.
> 
> On i386 this is just a matter of grepping for _GLOBAL_OFFSET_TABLE_ in
> the "nm" output.  Unfortunately I'm not sure if the same is true on
> other CPUs.  Restricting the test to i386, at least initially, would
> be better than nothing I guess.
> 
> I'm also not sure, unfortunately, where to tie it into the existing
> lintian checks.  But pic-a.pl below illustrates the idea, just running
> over /usr/lib/*.a.
> 
> /usr/lib/libc_nonshared.a is an exception to this test, it's correct
> for it to be PIC.  I guess libc6 can have an override for that, since
> that oddity is specific to it.
> 
> I believe xfree86 has some oddities related to the second remark in
> the .desc, but I don't know the full story.
> 
> Otherwise, on my system electric-fence is the only genuine current
> case, the rest are the libtool bug per the first remark in the .desc,
> as far as I can tell.
> 

Hi,

This certainly made sense 14 years ago when the bug was filed and all
the way up to about 1 year ago, when gcc started defaulting to PIE to
default.  Today, the average static library is de facto compiled as PIC
(or -fPIE, which is the same for the purpose of this bug).  In fact, we
have had to transition some of them to PIC/PIE in order to successfully
enable PIE by default.

Given this change, I believe this bug has become obsolete.  If the
policy still recommends static libs being non-PIC, then we should
probably update it to reflect the current defaults.

Thanks,
~Niels

--- End Message ---
Reply to: