| Summary: | source-highlight-native world build failures | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Richard Purdie <richard.purdie> |
| Component: | devtools / tool chain | Assignee: | Ed Bartosh <eduard.bartosh> |
| Status: | VERIFIED FIXED | QA Contact: | David Lopez Barriba <davidx.lopez.barriba> |
| Severity: | major | ||
| Priority: | Medium+ | CC: | jose.perez.carranza, liezhi.yang, meta.mr.watcher, meta.watcher, randy.macleod |
| Version: | 2.2 | ||
| Target Milestone: | 2.3 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Richard Purdie
2016-10-16 10:08:44 UTC
Posted for discussion on the mailing list: On a system compiling source-highlight-native with gcc 4.9 where boost- native was built on a gcc 5 system, we see one error. On a system compiling source-highlight-native with gcc 4.8 where boost-native was built on a gcc 4.9 system, we see a different error. The trouble is that libboost_regex.so in these cases wants the newer libstdc++ but at link time of executable, it can only see the host system and hence can't see newer symbols like std::runtime_error::runtime_error(char const*) or std::__throw_out_of_range_fmt(char const*, ...). I have done a lot of experimentation and the only way I can see of possibly making this work is to add -Wl,--unresolved-symbols=ignore-in- shared-libs to BUILD_LDFLAGS for source-highlight *and* ensure any native binaries get tweaked to use our own uninative loader before they're run. The former is horrible and the latter bit is hard. Another option would be to have multiple uninative feeds based on gcc version rather than a single uninative one. This close to release, I'm reluctant to poke this too much. We don't have many components that using C++, source-highlight is a comparatively new one which isn't in our default configuration for now. I'm therefore tempted to release note and look at this in 2.3. Fixed by implementing gcc version dependant uninative sstate cache. Please, review: http://lists.openembedded.org/pipermail/openembedded-core/2016-October/128067.html Sent v2 for review: http://lists.openembedded.org/pipermail/openembedded-core/2016-October/128075.html sent v3 after Pauls comment regarding v2 + fix: http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130154.html http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130158.html Tested on oe and poky. the fix has been merged to poky master Verified in e5aa1ac23669a45491de9ecffac491c01e70203f |