Bug 9215 - Overeager pattern in libdir QA check
Summary: Overeager pattern in libdir QA check
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 2.1
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.2
Assignee: Bill Randle
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-03-04 13:35 UTC by Joshua Lock
Modified: 2016-04-14 20:03 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
Proposed patch (1.08 KB, patch)
2016-03-22 20:08 UTC, Bill Randle
no flags Details | Diff
Revised patch to solve the real issue (1.21 KB, patch)
2016-03-23 00:12 UTC, Bill Randle
no flags Details | Diff
Third patch attempt (1.91 KB, patch)
2016-03-24 19:50 UTC, Bill Randle
no flags Details | Diff
fourth patch (2.58 KB, patch)
2016-04-01 16:52 UTC, Bill Randle
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Lock 2016-03-04 13:35:33 UTC
Overeager pattern (lib_re) in libdir QA check resulting in:

WARNING: QA Issue: soletta-dbg: found library in wrong location: /usr/share/gdb/auto-load/libsoletta.so.0.0.1-gdb.py [libdir]
Comment 1 Bill Randle 2016-03-22 20:08:15 UTC
Created attachment 3058 [details]
Proposed patch

Add gdb dir to INSANE_SKIP list. See attached patch.

Joshua, I'm not on the soletta mailing list. If you are, can you submit? (I don't have the setup to test this currently, but from what I've read and seen, it does seem to be the correct fix.)
Comment 2 Joshua Lock 2016-03-22 21:09:00 UTC
Apologies, the original bug description could have been much better. The bug isn't in the soletta recipe specifically. 

The issue is that the test is hitting false positives, likely due to the lib_re regex in insane.bbclass being too greedy.

The test is matching something which clearly isn't a library — /usr/share/gdb/auto-load/libsoletta.so.0.0.1-gdb.py — because the filename begins with /lib and contains "so.", then reporting that as an error because the matched file isn't in ${libdir} or ${libexecdir}.
Comment 3 Bill Randle 2016-03-23 00:12:44 UTC
Created attachment 3059 [details]
Revised patch to solve the real issue

Ok, now that I understand the real issue, the fix is straight forward. See attachment #2 [details]. Tested the new re using the tool on this website:  https://regex101.com/ and several real examples of library files.
Comment 4 Joshua Lock 2016-03-23 15:19:49 UTC
(In reply to comment #3)
> Created attachment 3059 [details]
> Revised patch to solve the real issue
> 
> Ok, now that I understand the real issue, the fix is straight forward. See
> attachment #2 [details]. Tested the new re using the tool on this website: 
> https://regex101.com/ and several real examples of library files.

Looks good to me, could you submit that to OE-Core? Thanks Bill!
Comment 5 Bill Randle 2016-03-23 15:55:09 UTC
Patch send to oe-core mailing list.
Comment 6 Bill Randle 2016-03-24 19:50:09 UTC
Created attachment 3062 [details]
Third patch attempt

Ok, so this checks to verify the file is an ELF file before declaring it to be in the wrong location. The re checks are loosened up (basically back to what they were originally) to allow library files with non-standard names to be included in the check.

I still need to test this and verify "rel_path" is the correct entity to run the ELF check on vs. one of the other path options in that block of code.
Comment 7 Bill Randle 2016-04-01 16:52:48 UTC
Created attachment 3087 [details]
fourth patch

Verified with local testing using a real ELF library and a non-ELF file that the ELF test does work and that full_path is the proper value to pass to the ELFFile() function.
Comment 8 Ross Burton 2016-04-14 20:03:18 UTC
Fixed in oe-core a3ad36b9a435e7c3d97f114809561198b8abe6cf.