Re: [lmi] Inchoate support for GNU/Linux builds with lmi makefiles

[Vadim Zeitlin]

On Fri, 16 Nov 2018 22:16:12 +0000 Greg Chicares <address@hidden> wrote:

GC> For '--host=i686-w64-mingw32' (only), we now have:
GC> 
GC>   build/lmi/$(uname)/gcc/safestdlib
GC>   build/lmi/$(uname)/gcc/ship
GC>   build/lmi/$(uname)/gcc/so_test
GC> 
GC> But is $(uname) ever really useful here?

 I find it more convenient/readable/easier to type (and TAB-complete) than
the GNU host triplets, but if you prefer to use the latter, there is no
need for the former and the canonical host strings have the advantage of
being less ambiguous because they're standardized. So it's one or the
other, and both definitely don't seem useful.

GC> I've built i686-w64-mingw32 lmi in
GC>   build/lmi/CYGWIN  [years ago, with native msw]
GC>   build/lmi/Linux   [these days, cross-compiling on my debian machine]
GC> but those were all the same i686-w64-mingw32 binaries, regardless of the OS
GC> that I happen to be running. IOW, out of the usual autoconf
GC>   {build, host, target}
GC> triplet, I think all I need care about is "host",

 Yes, because "target" only makes sense for cross-compilers and "build" is
implicit: it's the canonical string of the system itself, i.e. what
config.guess script would return.

GC> Probably the only host types that matter are:
GC>  - x86_64-linux-gnu (because there's no need for i686-linux-gnu); and
GC>  - i686-w64-mingw32 or x86_64-w64-mingw32 (only the former for now, but
GC>      only the latter once we move to 64-bit msw production builds).

 Well, those could be the only two that matter now, but it doesn't seem to
be wise to explicitly restrict host strings to these 2 only.

GC> Dropping what doesn't matter, and adding the compiler, would yield a
GC> directory-structure grammar like this:
GC> 
GC>   build /
GC>     {x86_64-linux-gnu, i686-w64-mingw32, x86_64-w64-mingw32} /
GC>     {gcc, clang} /
GC>     {safestdlib, ship, so_test} /
GC> 
GC> where we could later adjust the options enumerated in {}, e.g.,
GC> 
GC>   build/x86_64-linux-gnu/gcc/asan
GC> 
GC> for "address sanitizer".

 Yes, this looks good. I guess if we now could also replace "../build"
directory with a configurable "builddir" variable, so that I could make my
builds in my own custom build directory (which is not being backed up), I
should be able to switch to using the official makefiles under Linux
instead of using autotools (not that there is anything wrong with the
latter, but if the former works well, I'd have trouble justifying spending
time on maintaining the parallel build system).

GC> > GC> make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 
-Wno-pedantic' CFLAGS='-m64' LDFLAGS='-m64' unit_tests 
unit_test_targets=global_settings_test
GC> > 
GC> >  BTW, isn't "-g" missing in LDFLAGS here? AFAICS you won't be able to 
debug
GC> > the binaries built by this command.
GC> 
GC>   https://sourceware.org/binutils/docs/ld/Options.html
GC> | -g   Ignored. Provided for compatibility with other tools.
GC> 
GC> I've never used it with gnu ld. (Does it matter for clang though?)

 Hmm, do lmi makefiles really use ld for linking? I've always linked C++
programs (and shared libraries) with g++ because it adds the required CRT
object files. And it definitely does need "-g".

GC> > GC> BTW, 32- vs. 64-bit speed comparison:
GC> > [...]
GC> > 
GC> >  This certainly looks like a nice speedup, I didn't expect it, to be
GC> > honest. I wonder if you'd be willing to rebuild it with -O3 just out of
GC> > curiosity?
GC> 
GC> TL;DR: Run time is unaffected: '-O3' doesn't help.

 This is actually somewhat reassuring, I find it suspicious when there is a
significant difference between -O2 and -O3 timings. OTOH I'm still a bit
surprised that -O3, which enables loop auto-vectorization, didn't result in
at least a modest speedup. It might be worth checking if there are any hot
loops and, if so, whether they have been effectively vectorized. Modern g++
versions are supposed to give relatively understandable diagnostics when
they fail to do it.

 Regards,
VZ