We've had a lot of success with uninative but in the 2.2-rc2 build
which I ran last night on two different autobuilders, we saw two
different failures:


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.

Opinions? Other ideas?



Openembedded-core mailing list

Reply via email to