On Wed, Feb 10, 2021 at 1:57 AM Andre McCurdy <[email protected]> wrote: > > On Wed, Feb 10, 2021 at 12:48 AM Mikko Rapeli <[email protected]> wrote: > > > > Hi, > > > > On Tue, Feb 09, 2021 at 11:37:39PM -0800, Khem Raj wrote: > > > In this case -O will take effect sadly. and it seems to be that > > > autconf munges the compiler cmdline > > > while generating CFLAGS in generated Makefiles and appends the value > > > of -On coming from CC > > > variable last. > > > > > > I think right solution would be to add same -O<level> as specified in > > > SELECTED_OPTIMIZATION so it remains > > > in sync always, I have sent a patch to ml. Could you test it out and > > > let me know if it works for you as well. > > > > Or let it go? A lot of recipes amend their own optimization flags and > > override > > distro wide optimization and other compiler flags. I once fixes all recipes > > in a project which were not obeying Os until buildhistory showed change in > > binary > > sizes... that was a lot of work for a PoC.. > > If the goal is to ensure that the optimisation flag from > FULL_OPTIMIZATION and the -D_FORTIFY_SOURCE flag from > lcl_maybe_fortify are always applied together then isn't the easiest > solution to move -D_FORTIFY_SOURCE out of lcl_maybe_fortify and into > FULL_OPTIMIZATION ? >
The problem is that we insert the flags inconsistently and it depends on underlying build systems interpretation of these flags. e.g. We add D_FORTIFY_SOURCE to CC/CXX but -O<n> to CFLAGS/CXXFLAGS many tests e.g. do not use CC and CFLAGS together, if we remove D_FORTIFY_SOURCE from CC/CXX then it does not get tested in configure tests but final compile uses it and cause miscompiles and this all is also need to keep in mind that we might have external toolchains which are compiled with its own set of options by default. Thats why we have to be explicit about these flags so they can be customized if needed. > Putting a separate optimisation flag in lcl_maybe_fortify and trying > to arrange for it not to clash with or override the one already in > FULL_OPTIMIZATION seems like an ugly solution, even if it can be made > to work.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147935): https://lists.openembedded.org/g/openembedded-core/message/147935 Mute This Topic: https://lists.openembedded.org/mt/80425803/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
