On 03/30/2017 04:58 PM, Martin Kelly wrote:
On 03/30/2017 12:31 PM, Khem Raj wrote:
On 3/30/17 12:20 PM, Martin Kelly wrote:
Hi,
I'm trying to integrate the meta-clang version of LLVM 4.0 (used for
recipes that need a newer LLVM version) alongside the oe-core version of
LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some
to use LLVM 3.3 and for them not to collide with each other.
Right now, once the meta-clang layer is enabled, the recipes collide
because they both provide llvm-common.bb. I tried explicitly versioning
llvm-common, which makes them no longer collide. However, mesa then
fails to build because the meta-clang version of LLVM installs
llvm-config into the native common sysroot in
merging all llvm-common into a single recipe might be good
I thought more about this issue. Absent some clever solution that allows
us to unify the wrappers (which is difficult due to the issues I
mentioned in the last mail), I think we have three routes that could
work to at least allow meta-clang and meta-oe to exist in the same Yocto
workspace without breakage:
(a) Instead of installing llvm-config into
${SYSROOT_DESTDIR}${bindir_crossscripts} -- which causes collisions when
meta-clang and meta-oe both try to overwrite the same shared file --
install into ${D}{bindir}llvm-config, and install the binary llvm-config
into ${D}${bindir}/llvm-config${PV}. Recipes requiring LLVM will then
need to depend on either llvm-common3.3 or llvm-common4.0, but at least
there will be no collision or ambiguity which one gets used.
(b) Use a common wrapper in
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config that does what the
meta-oe current version does; just exec
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config${WANT_LLVM_RELEASE}.
Let the meta-oe LLVM 3.3 install the binary llvm-config into
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config3.3 and let the
meta-clang LLVM 4.0 install its wrapper llvm-config into
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config4.0. meta-clang will
have to use the second wrapper script because it needs to edit
TARGET_CFLAGS and similar to avoid compiling target binaries using
native flags (due to the CMake LLVM build which appears not to respect
cross-compile).
(c) Use a common llvm-config wrapper in
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config that does a
hardcoded check for WANT_LLVM_RELEASE. If the version is 4.0 or greater,
then edit the TARGET_CFLAGS and similar, otherwise don't.
It seems to me that all these options are undesireable, but (a) is
probably least so.
Khem and others: which option would you like me to pursue, or do you
have an alternate suggestion?
Thanks,
Martin
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
