flto automake
If you aren't planning on enabling flto in a repo you can ignore this email.
I've created a new class flto-automake https://github.com/openbmc/meta-phosphor/blob/master/classes/flto-automake.bbclass if you are enabling -flto in an autotools project you might be interested in. When using static libraries you may run into undefined references when building with Yocto. Yocto by default uses:
export AR = "${HOST_PREFIX}ar"
export RANLIB = "${HOST_PREFIX}ranlib"
for AR and RANLIB. This new class replaces these with the gcc equivalent wrappers that can work with the flto object files. This doesn't seem to be an issue for the CI build, it only shows up for Yocto builds. Reference: http://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries#comment67660913_25878408
For Cmake I suggest looking at the way bmcweb handles it in CMakesLists:
https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt#L92
Thanks,
James
Quoted 12 lines · James Feist
If you aren't planning on enabling flto in a repo you can ignore this email.
I've created a new class flto-automake https://github.com/openbmc/meta-phosphor/blob/master/classes/flto-automake.bbclass if you are enabling -flto in an autotools project you might be interested in. When using static libraries you may run into undefined references when building with Yocto. Yocto by default uses:
export AR = "${HOST_PREFIX}ar"
export RANLIB = "${HOST_PREFIX}ranlib"
Quoted 8 lines
for AR and RANLIB. This new class replaces these with the gcc equivalent wrappers that can work with the flto object files. This doesn't seem to be an issue for the CI build, it only shows up for Yocto builds. Reference: http://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries#comment67660913_25878408
For Cmake I suggest looking at the way bmcweb handles it in CMakesLists:
https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt#L92Thanks,
James
Thanks James
I wonder if this is something they would be interested in upstream. I’ve copied the oe-core mailing list for possible comment.
-brad
Quoted 2 lines · Brad Bishop
I wonder if this is something they would be interested in upstream. I’ve copied the oe-core mailing list for possible comment.
Thanks for forwarding this to us. The class is very simple and just does:
PACKAGECONFIG_CONFARGS += " AR=${TARGET_PREFIX}gcc-ar \
RANLIB=${TARGET_PREFIX}gcc-ranlib"
That's quite an abuse of PACKAGECONFIG_CONFARGS, I'd recommend just setting AR and RANLIB directly in the class, they'll override the defaults in bitbake.conf.
That however leads to the question of should we just change the defaults? Does anything break if we use gcc-ar instead of ar?
Ross
Quoted 10 lines · Ross
Quoted 2 lines · Brad Bishop
I wonder if this is something they would be interested in upstream. I’ve copied the oe-core mailing list for possible comment.
Thanks for forwarding this to us. The class is very simple and just does:
PACKAGECONFIG_CONFARGS+= " AR=${TARGET_PREFIX}gcc-ar \
RANLIB=${TARGET_PREFIX}gcc-ranlib"
Oh I like it in a common class! We have "ugly" AC_SUBST for AR and RANLIB to gcc one in https://github.com/openbmc/phosphor-time-manager/blob/master/configure.ac#L10-L11
Let's see how upstream think about this.
Quoted 2 lines · Ross
That however leads to the question of should we just change the defaults? Does anything break if we use gcc-ar instead of ar?
Answer: yes.
| x86_64-poky-linux-gcc-ar rc libgcov.a $objects | x86_64-poky-linux-gcc-ar: Cannot find plugin 'liblto_plugin.so' | Makefile:932: recipe for target 'libgcov.a' failed
ERROR: Task (/home/ross/Yocto/poky/meta/recipes-devtools/gcc/libgcc-initial_8.2.bb:do_compile) failed with exit code '1'
I don't know enough about gcc...
Ross
Quoted 8 lines · Ross
Quoted 2 lines · Ross
That however leads to the question of should we just change the defaults? Does anything break if we use gcc-ar instead of ar?
Answer: yes.
Quoted 8 lines
Quoted 3 lines
x86_64-poky-linux-gcc-ar rc libgcov.a $objects
x86_64-poky-linux-gcc-ar: Cannot find plugin 'liblto_plugin.so' Makefile:932: recipe for target 'libgcov.a' failedERROR: Task (
/home/ross/Yocto/poky/meta/recipes-devtools/gcc/libgcc-initial_8.2.bb:do_compile)
failed with exit code '1'I don't know enough about gcc...
The -initial compiler doesn't have lto compiled into it so you probably need to use binutils ar for that part of the bootstrap.
Cheers,
Richard
Quoted 11 lines · Ross
Quoted 2 lines · Brad Bishop
I wonder if this is something they would be interested in upstream. I’ve copied the oe-core mailing list for possible comment.
Thanks for forwarding this to us. The class is very simple and just does:
PACKAGECONFIG_CONFARGS+= " AR=${TARGET_PREFIX}gcc-ar \
RANLIB=${TARGET_PREFIX}gcc-ranlib"
Quoted 6 lines
That's quite an abuse of
PACKAGECONFIG_CONFARGS, I'd recommend just setting AR and RANLIB directly in the class, they'll override the defaults in bitbake.conf.That however leads to the question of should we just change the defaults? Does anything break if we use gcc-ar instead of ar?
Dont think that is a good idea in general since gcc-ar is a wrapper around normal ar
passing --plugin=/path/to/lto/plugin/so and that may not be right thing to do always.
Quoted 7 lines
Ross
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 7 lines · Khem Raj
Quoted 2 lines
That however leads to the question of should we just change the defaults? Does anything break if we use gcc-ar instead of ar?
Dont think that is a good idea in general since gcc-ar is a wrapper around normal ar
passing --plugin=/path/to/lto/plugin/so and that may not be right thing to do always.
Well, I built core-image-sato core-image-weston with AR=gcc-ar RANLIB=gcc-ranlib globally and it worked fine.
As we build the cross gcc we know what is in it. Other toolchains be they clang, ICC, or external GCCs, can override AR just like they do the other variables.
Ross
Quoted 5 lines · Ross
Quoted 3 lines · Khem Raj
Quoted 2 lines
That however leads to the question of should we just change the defaults? Does anything break if we use gcc-ar instead of ar?
Quoted 7 lines
Quoted 4 lines
Dont think that is a good idea in general since gcc-ar is a wrapper around normal ar
passing --plugin=/path/to/lto/plugin/so and that may not be right thing to do always.Well, I built core-image-sato core-image-weston with AR=gcc-ar RANLIB=gcc-ranlib globally and it worked fine.
Please build a lot more. These images cover only handful of recipes there are problems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
which we might have to contend.
Quoted 5 lines
As we build the cross gcc we know what is in it. Other toolchains be they clang, ICC, or external GCCs, can override AR just like they do the other variables.
Yes they can, but what doe this buy us ? except we make Core toolchain gcc dependent one step more.
Quoted 1 line
Ross
Quoted 6 lines · Khem Raj
Quoted 3 lines
As we build the cross gcc we know what is in it. Other toolchains be they clang, ICC, or external GCCs, can override AR just like they do the other variables.
Yes they can, but what doe this buy us ? except we make Core toolchain gcc dependent one step more.
The core toolchain is currently GCC dependent already by definition. I'm actually about to start working on abstracting the core so it doesn't make any assumptions, like how there's no hard assumption of glibc in the core.
Ross
Quoted 9 lines · Khem Raj
Quoted 2 lines
Well, I built core-image-sato core-image-weston with AR=gcc-ar RANLIB=gcc-ranlib globally and it worked fine.
Please build a lot more. These images cover only handful of recipes there are problems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
which we might have to contend.
That bug from two years ago suggests that the gcc-ar wrapper isn't required if GCC has been configured properly. I guess we need a test case.
Ross
Quoted 8 lines · Ross
Quoted 6 lines · Khem Raj
Quoted 2 lines
Well, I built core-image-sato core-image-weston with AR=gcc-ar RANLIB=gcc-ranlib globally and it worked fine.
Please build a lot more. These images cover only handful of recipes there are problems like
Quoted 7 lines
Quoted 3 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
which we might have to contend.
That bug from two years ago suggests that the gcc-ar wrapper isn't required if GCC has been configured properly. I guess we need a test case.
cmake's approach of defined COMPILER_AR and COMPILER_RANLIB etc seems better to me. where it can be uses selectively only when LTO is in play.
Quoted 2 lines
Ross
Quoted 9 lines · Brad Bishop
Quoted 9 lines · James Feist
If you aren't planning on enabling flto in a repo you can ignore this email.
I've created a new class flto-automake https://github.com/openbmc/meta-phosphor/blob/master/classes/flto-automake.bbclass if you are enabling -flto in an autotools project you might be interested in. When using static libraries you may run into undefined references when building with Yocto. Yocto by default uses:
The changes are right but I think flto should also be a DISTRO_FEATURE and this change should become effective only when flto is in DISTRO_FEATURES
Quoted 8 lines
Quoted 8 lines
export AR = "${HOST_PREFIX}ar"
export RANLIB = "${HOST_PREFIX}ranlib"for AR and RANLIB. This new class replaces these with the gcc equivalent wrappers that can work with the flto object files. This doesn't seem to be an issue for the CI build, it only shows up for Yocto builds. Reference: http://stackoverflow.com/questions/25878407/how-can-i-use-lto-with-static-libraries#comment67660913_25878408
For Cmake I suggest looking at the way bmcweb handles it in CMakesLists:
https://github.com/openbmc/bmcweb/blob/master/CMakeLists.txt#L92
hardcoding is not right. We have cross versions of these tools installed during OE build and we also have options to use non-gcc compilers, e.g. llvm provides its own verisons of llvm-ar and llvm-ranlib and llvm-nm which should be used when using clang or other llvm based static compilers.
This is right fix for cross compiling with CMake
https://github.com/YoeDistro/meta-ti/blob/yoe/mut/recipes-bsp/rwmem/rwmem/0001-Use-CMake-provided-vars-for-ar-and-ranlib.patch
Quoted 16 lines
Quoted 4 lines
Thanks,
James
Thanks James
I wonder if this is something they would be interested in upstream. I’ve copied the oe-core mailing list for possible comment.
-brad
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core