Bug 5964

Summary: e2fsprogs: gettext mismatch failure with non-gplv3 builds
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Christopher Larson <kergoth>
Component: coreAssignee: Christopher Larson <kergoth>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: meta.mr.watcher, meta.watcher
Version: unspecified   
Target Milestone: 1.6 M5   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Christopher Larson 2014-03-13 17:49:44 UTC 
Ever since the change to how aclocal files are copied (based on dependencies),
target m4 macros seem to more reliably be used in preference to native (which
they should), but in a non-gplv3 build, gettext is 0.16 while gettext-native
is 0.18, causing a 0.16 po.m4 to be used with our 0.18 po/Makefile.in.in
files, causing at least some failed builds, including e2fsprogs.

I think the best way to work around this situation, assuming we're stuck using 0.16 target gettext, which I think we are, would be to just drop the target gettext m4 macros from the sysroot. Anyone inheriting gettext will also dep on gettext-native, so will get the macros from the newer gettext-native recipe anyway. See https://github.com/MentorEmbedded/meta-mentor/pull/110 for the workaround we're using at Mentor at the moment to fix our currently broken non-gplv3 builds (INCOMPATIBLE_LICENSE = "LGPLv3 GPLv3").
Comment 1 Saul Wold 2014-03-17 17:04:26 UTC 
I think the suggested workaround might be the best choice, please go ahead and 
submitt a patch.
Comment 2 Christopher Larson 2014-04-01 17:02:09 UTC 
The fix for this was merged to oe-core.