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

[Vadim Zeitlin]

On Fri, 16 Nov 2018 11:03:40 +0000 Greg Chicares <address@hidden> wrote:

GC> [TL;DR: export LD_LIBRARY_PATH and use '-fPIC'; then everything works]

 Nice!

GC> On 2018-11-16 01:44, Vadim Zeitlin wrote:
GC> > On Thu, 15 Nov 2018 23:52:44 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2017-04-12 00:07, Greg Chicares wrote:
GC> [...]
GC> > GC> > /opt/lmi/src/lmi[0]$make $coefficiency build_type=native 
CXXFLAGS='-O2 -ggdb -m64 -Wno-pedantic' CFLAGS='-m64' LDFLAGS='-m64' unit_tests 
unit_test_targets=bourn_cast_test
GC> > GC> 
GC> > GC> This updated command:
GC> > GC> 
GC> > GC> make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 -fno-pie
GC> > GC> -Wno-pedantic -Wno-useless-cast' CFLAGS='-m64 -fno-pie' LDFLAGS='-m64
GC> > GC> -no-pie' unit_tests cli_tests >../log 2>&1
GC> > GC> 
GC> > GC> adds '-Wno-useless-cast' to ignore a pervasive boost-1.33.1 problem,
GC> > 
GC> >  I wonder why was it necessary when we already have a pragma disabling 
this
GC> > warning in boost_regex.hpp.
GC> 
GC> Because the boost filesystem library also needs it with gcc-8.2.0
GC> for x86_64-linux-gnu, e.g.:

 Hmm, I see, it looks like I just don't have -Wuseless-cast enabled for the
autotools build, which is why I didn't need it. Now I don't know if I
should enable it there or if it's better to live without it, finally, as
this warning doesn't really seem very useful to me.

GC> make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 
-Wno-pedantic' CFLAGS='-m64' LDFLAGS='-m64' unit_tests 
unit_test_targets=global_settings_test

 BTW, isn't "-g" missing in LDFLAGS here? AFAICS you won't be able to debug
the binaries built by this command.

GC> We use boost::regex in so few cases that we created a 'boost_regex.hpp'
GC> header with pragmata to suppress warnings. But we use boost::filesystem
GC> so widely as to render such a technique far less attractive.

 And, also, it should be replaced with std::filesystem, which hopefully
won't give this warnings (but I didn't check this yet).

GC> BTW, 32- vs. 64-bit speed comparison:
[...]

 This certainly looks like a nice speedup, I didn't expect it, to be
honest. I wonder if you'd be willing to rebuild it with -O3 just out of
curiosity?

GC> > GC> but perhaps $LDFLAGS needs to vary between $EXEEXT and $SHREXT,
GC> > GC> because for '.so' targets I still get:
GC> > GC> 
GC> > GC> /usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crt1.o: in function 
`_start':
GC> > GC> (.text+0x20): undefined reference to `main'
GC> > GC> collect2: error: ld returned 1 exit status
GC> > 
GC> >  This looks like a wrong linking command to me, i.e. is there a -shared in
GC> > it? It seems that the linker is trying to create an executable instead of 
a
GC> > shared library here.
GC> 
GC> Yes, '-shared' is specified for $SHREXT and not for $EXEEXT,
GC> exactly the same way it's specified for 32-bit builds.
GC> Specifying [capitalized] '-fPIC' in both $CXXFLAGS and $LDFLAGS
GC> seems to have fixed that.

 Very curious. I didn't know you could get such error due to missing -fPIC
but perhaps the linker decides to ignore -shared if it sees that it can't
do it anyhow due to the presence of position-dependent code? Anyhow, glad
to hear that this has been sorted out.

[... ASLR ...]
GC> AIUI, debian enabled it by default ("--enable-default-pie" in gcc
GC> configuration above), so it's automatically used whenever possible.

 Yes, all modern Linux distributions do it AFAIK. And it could be avoided
with -no-pie, but in lmi case all the performance-sensitive code is in a
(shared) library anyhow (as it should be, in a well-modularized project),
so I don't see why would we bother doing it.

 Regards,
VZ