On Tue, Apr 23, 2019 at 11:18:47AM -0500, Bruce Dubbs via lfs-dev wrote: > On 4/23/19 12:24 AM, Thomas Trepl via lfs-dev wrote: > > > > Is there a reason why we won't add that sed to the book? > > Inertia plus we just found out about it. > > sed -i 's/67]/6789]/' Configure > > ought to do it. I'll do that today. > > -- Bruce > Thanks. And this is the sort of change which attempts at reproducible builds (or "can it build itself" - my other topic for today) will never catch :-(
Meanwhile, I'm slowly looking through every package in my normal desktop builds to see if they respect my CFLAGS (I'm usually building with -march=native nowadays, so that is easy to look for). Unfortunately, many CMMI packages are not verbose. So far, one or two oddities (such as perl), a long way to go before I can try a "baseline" build. After that, a series of builds to see what difference certain flags make. This was all prompted by thoughts on LTO - see https://github.com/inBetweenNames/gentooLTO - and an interest in tuning my builds. Certain random things mentioned there which might be beneficial - (But finding tests, apart from "is the system stupidly bigger" or "do builds take longer" for many of these will be hard!) -falign-functions=32 for intel SandyBridge and newer, but NOT for AMD where the default of 16 is preferred. Perhaps add -flimit-function-alignment on intel. -malign-data= options (abi is the default and packs more objects in the same space, cacheline should reduce cache misses, compat is a compromise to avoid wasting space) - these look very machine-specific in terms of balancing memory against speed. -flto (turn on LTO) - this is supposed to offer reduced code size, but at a cost of increased compile times and possible incompatability with non-gcc compilers (so, needs to be tested re clang). -D_FORTIFY_SOURCE=2 q.v. (requires -O2 or higher) and -fstack-protector-strong : for general use, these probably should be used together. Hopefully, no noticeable runtime slowdown. NB with FORTIFY_SOURCE=2 detected buffer overflow will terminate the program. -fno-semantic-interposition : apparently allows lto optimisation of shared libraries, and said to be the default in llvm/clang. Can break things (e.g. can't override parts of lib using LD_PRELOAD). Clearly, it is going to take a lot of time to test if any of this seems beneficial (and like my past efforts to force gold, it might mostly be not beneficial). At the moment I'm going through my package logs one-by-one. Meanwhile, a few comments on specific packages - perl : add -D"optimize=$CFLAGS" to use own CFLAGS. Where a (separate) module compiles C source, this will (hopefully) ensure that the module is similarly optimized. Qt : add -ltcg to the configure options to enable link-time code generation, i.e. LTO. Not even tested to see if it is accepted. Also, this will turn it on for all packages built by that qt instance, so the measurements will not be valid for BLFS :) At the moment Qt does not use my CFLAGS, see Arch for examples of editing the mkspecs files to do this. Again, it will apply to all packages built by that instance of qt. Pythons: Python3 will append CFLAGS to its own, and its own use -O3 so CFLAGS ought to be pruned in this case (upstream wants to use -O3). Python2 adds -O3 and -g *after* CFLAGS. I've got a sed to remove the -g, but 'find' still says "not stripped". More interestingly, both versions have an option of '--enable-optimizations' for release builds, which enables PGO (profile guided optimizations) and LTO if that is available. I tried adding this to a test build of python2 while I playing with the 2 configure, and the build took a *lot* longer. Whether it is worth the extra build time, other than for people who regularly use python for scripting, I have no idea. I might test this for py2 at some point (firefox and qtwebengine both use 2), but it is probably near the end of the list of things to try. ĸen -- With a few red lights, a few old bits, we made the place to sweat. No matter what we get out of this, I know, I know we'll never forget. Smoke on the water, a fire in the sky. Smoke, on the water. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
