This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 502112 - Statically linked binary missing GNU stack section
Statically linked binary missing GNU stack section
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-21 18:33 EDT by Dean Glazeski
Modified: 2009-06-08 15:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-08 15:38:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dean Glazeski 2009-05-21 18:33:23 EDT
Description of problem:
When a package contains a statically linked ELF file meant for a system other than the host, rpmlint reports the following error:

openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf

The ELF in question is meant for target systems and is not meant to be executed on the host system.

Version-Release number of selected component (if applicable):
rpmlint version 0.87 Copyright (C) 1999-2007 Frederic Lepied, Mandriva

How reproducible:
Run rpmlint on a binary RPM that has a statically linked ELF binary for an architecture other than the current system.
  
Actual results:
Two errors complaining about the library being static and missing a GNU stack secion:

openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf

Expected results:
No error.

Additional info:
This is coming up because I am working on a package for OpenOCD, an on-chip debugger for ARM, MIPS, etc. targets.  An elf file is statically linked so it can be passed to a target for debugging purposes.  It should be ignored by rpmlint.
Comment 1 Chitlesh GOORAH 2009-05-22 05:14:23 EDT
Can you post the url for the SRPM and the output of

rpm -q rpmlint
?
Comment 2 Dean Glazeski 2009-05-22 07:41:17 EDT
(In reply to comment #1)
> Can you post the url for the SRPM and the output of
> rpm -q rpmlint?

SRPM is at http://files.dinoprojects.com/openocd-0.1.0-1.fc10.src.rpm

Output is:
openocd.x86_64: E: statically-linked-binary/usr/lib64/openocd/ecos/at91eb40a.elf
openocd.x86_64: E: missing-PT_GNU_STACK-section/usr/lib64/openocd/ecos/at91eb40a.elf
Comment 3 Ville Skyttä 2009-05-22 09:06:52 EDT
I suppose the only thing about this we could do in rpmlint would be to filter the message(s) out.  But if the file in question is not meant to run on the host system, as far as the package is concerned it is treated just as data, no?  Therefore, wouldn't it be more appropriate to ship it in /usr/share instead of /usr/lib(64)?  I'm asking because this most likely has implications to how the messages should be filtered out in rpmlint.

statically-linked-binary sounds ok to me to be filtered out, but are you sure that missing-PT_GNU_STACK-section is intentional and ok and shouldn't be "fixed" in the package?  See "rpmlint -I missing-PT_GNU_STACK-section".
Comment 4 Dean Glazeski 2009-05-22 10:27:11 EDT
(In reply to comment #3)
> I suppose the only thing about this we could do in rpmlint would be to filter
> the message(s) out.  But if the file in question is not meant to run on the
> host system, as far as the package is concerned it is treated just as data, no?
>  Therefore, wouldn't it be more appropriate to ship it in /usr/share instead of
> /usr/lib(64)?  I'm asking because this most likely has implications to how the
> messages should be filtered out in rpmlint.

You make a valid point.  I brought up this very issue up with the OpenOCD developers as I was making this RPM.  It makes more sense that the file should end up in /usr/share to stay compliant with FHS.  Will rpmlint have any problems if there is a static link against a library in /usr/share?

> statically-linked-binary sounds ok to me to be filtered out, but are you sure
> that missing-PT_GNU_STACK-section is intentional and ok and shouldn't be
> "fixed" in the package?  See "rpmlint -I missing-PT_GNU_STACK-section".  

From what I've been told from the people in OpenOCD, this elf file is meant for target embedded systems being debugged and not for the system the tool is installed on.  This error doesn't show up if you run rpmlint against the PPC or PPC64 builds of the OpenOCD package, but I assume those environments have a different requirement for library files.
Comment 5 Ville Skyttä 2009-05-22 14:09:21 EDT
(In reply to comment #4)
> Will rpmlint have any
> problems if there is a static link against a library in /usr/share?

It'll quite likely emit even more warnings in that case because there's an arch dependent thing in /usr/share (and it doesn't know it's supposed to be treated as data).

Anyway... no matter where the file is located, how about if we do nothing about it in rpmlint?  I'm not sure what value the filtering would add once the package is ready, the messages could just be ignored as known false positives (would be good to document it in the specfile though).  Thoughts?
Comment 6 Dean Glazeski 2009-06-02 09:08:32 EDT
(In reply to comment #5)
> Anyway... no matter where the file is located, how about if we do nothing about
> it in rpmlint?  I'm not sure what value the filtering would add once the
> package is ready, the messages could just be ignored as known false positives
> (would be good to document it in the specfile though).  Thoughts?  

I'm alright with this approach.  I just wanted to make sure there was some understanding about the issue with rpmlint developers.  If you think its alright to just ignore the error, I'll document it in the SPEC file and call it good.
Comment 7 Ville Skyttä 2009-06-08 15:38:46 EDT
Generally I like to add filters to rpmlint that suppress known categorical false positives for several packages instead of adding ones to get the output clean for isolated single cases (although I admit I haven't been 100% consistent with that).  Anyway, I don't see a pattern here that we could turn into a generally useful filter so I'll close this as wontfix.  Referring to this bug in comments in your specfile would probably be useful.

Note You need to log in before you can comment on or make changes to this bug.