Bug 5964 - e2fsprogs: gettext mismatch failure with non-gplv3 builds
Summary: e2fsprogs: gettext mismatch failure with non-gplv3 builds
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.6 M5
Assignee: Christopher Larson
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2014-03-13 17:49 UTC by Christopher Larson
Modified: 2014-04-01 17:02 UTC (History)
2 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.