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.
Can you post the url for the SRPM and the output of rpm -q rpmlint ?
(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
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".
(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.
(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?
(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.
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.