On Tue, Mar 26, 2019 at 07:39:46PM -0500, Bruce Dubbs via blfs-dev wrote: > On 3/26/19 5:25 PM, Ken Moffat via blfs-dev wrote: > > On Tue, Mar 26, 2019 at 02:55:40PM -0500, Bruce Dubbs via blfs-dev wrote: > > > I suppose libdrm, gdk-pixbuf, glib2, pango might be interesting > > packages to look at. > > > > As an initial guess, I think I should compare (with 4 cores) : > > > > · the book's current build > > · forcing a release > > · forcing a release but passing CFLAGS, CXXFLAGS of just '-g' > > > > Does that sound sensible ? > > Seems like an interesting experiment. You don't really have to install, > just build. >
(sorry for any delay in responding, been emailing MPs about the state this country is in). Yes, for the moment, only building and DESTDIR installs (just like editing, after checking that a real install works ;-) > I have little experience using gdb, I'm > > not entirely convinced that trying to debug a -O3 build would ever > > be useful. > > I agree. -O3 removes a lot of code through things like inlining and changes > a lot with things like loop unrolling. Generally I think that a lot of > optimization is unneeded unless a profile is done and critical sections > optimized. > But that has the implication "we should specify -O2 in CFLAGS and CXXFLAGS when building a release". At the moment we have specified O2 for firefox (removed for clang) and perhaps in one or two other places. I'm all-in-favour of letting builders decide how to optimize, but unless there is an actual problem (e.g. firefox, as was) I'm not sure about forcing -O2 with -g. But perhaps we could use -Dbuildtype=release with an explanation something like: "The release build disables runtime assertions which may slow down the runtime experience (no, that is not sensible English, not sure how to indicate that libraries as well as programs may run more slowly, suggestions welcome) and also enables the highest level of optimization (-O3) while removing debug symvbols. If you need to debug, passing CFLAGS and CXXFLAGS of "-O2 -g" with this may be more useful." ?? > The default in Mesa uses -O2 -g but also enables the > > assertions, maybe a release with -O2 -g would be more useful ? > > I suspect it would be cleaner. > I'm waiting for more responses (so probably leaving this for 16 hours or more). It will be interesting to see how things turn out. > > I also start to wonder if we ought to expand 'Notes on Building > > Software' with a section about optimizations ? > > A reasonable suggestion. > > We used to only have > > to really care about CMMI packages, with CFLAGS and CXXFLAGS - some > > of those ignore the flags, and for those which accept them we assume > > experienced builders will know about the obvious -O, -O2, -O3, -g. > > But with (I think) both cmake and meson we perhaps need to spell out > > somewhere what the typical defaults are ? (as well as maybe > > specifying release builds, perhaps with notes about what that > > actually does). > > We can get into a lot of discussion there. > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > And then there are linking options to consider. > > https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html > > How much do you think is reasonable? > Initially, I'm not sure we need any of it (the old 'disparage gentoo users as ricers' argument). But perhaps pointing to the optimize and link options may be useful. I'm more concerned about highlighting whatever may turn out to be the defaults for ninja and cmake (and until now I've been happy to go with whatever the book offers for cmake programs, although my opinion of cmake is lower than my opinion of my Prime Minister :) > -- Bruce ĸen - slowly getting back to his firefox diff: does anyone know of a way to tell vim (i.e. 'view' with its nice colours) that a diff which starts with a lot of ASCII is actually UTF-8 ? I've already got: set fileencoding=utf-8 but when I eventually hit some UTF-8 in French translations (there might be who knows what encodings in other translations) I get doubled bytes for accented letters. -- It is said that there are two great unsolved problems in computer science: naming, cache invalidation, and off-by-one errors. -- Ben Bullock -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
