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

[Greg Chicares]

On 2018-11-16 11:53, Vadim Zeitlin wrote:
> On Fri, 16 Nov 2018 11:03:40 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> [TL;DR: export LD_LIBRARY_PATH and use '-fPIC'; then everything works]
> 
>  Nice!

And now '-fPIC' is built in, so, with a few other just-pushed changes:

/opt/lmi/src/lmi[0]$export LMI_TRIPLET=x86_64-pc-linux-gnu                      
/opt/lmi/src/lmi[0]$make clean                                                  
GUI build not yet supported.
rm --force --recursive /opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship
/opt/lmi/src/lmi[0]$LD_LIBRARY_PATH=: make $coefficiency cli_tests 2>&1 |less -S
/opt/lmi/src/lmi[0]$lmipath=/opt/lmi/gcc_x86_64-pc-linux-gnu/build/ship; export 
LD_LIBRARY_PATH=$lmipath; $lmipath/lmi_cli_shared --accept 
--data_path=/opt/lmi/data --selftest
Test speed:
  naic, no solve      : 1.899e-02 s mean;      18725 us least of  53 runs
  naic, specamt solve : 3.297e-02 s mean;      32651 us least of  31 runs
  naic, ee prem solve : 3.029e-02 s mean;      29882 us least of  34 runs
  finra, no solve     : 7.584e-03 s mean;       7139 us least of 100 runs
  finra, specamt solve: 2.041e-02 s mean;      19798 us least of  50 runs
  finra, ee prem solve: 1.898e-02 s mean;      18661 us least of  53 runs

"GUI build not yet supported" is just a reminder that there's still
work to be done. Perhaps debian provides prebuilt wx libraries that
would just work, but then again it's probably better to build them
ourselves so that we're using an exact wx version that's known to
be compatible with the latest lmi.

This message:
  wx-config: Command not found
appears a few times in the redirected 'make' invocation above,
but can be ignored for CLI builds.

I'll discuss "LD_LIBRARY_PATH" in a separate message.

> GC> On 2018-11-16 01:44, Vadim Zeitlin wrote:
> GC> > On Thu, 15 Nov 2018 23:52:44 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> 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

No {C,CXX}FLAGS workarounds needed now.

> 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.

While working on the valyuta branches, it's been useful for
finding and removing unnecessary explicit conversions.

With HEAD now, that and other issues have been addressed, and
no manual overrides are needed, except for LD_LIBRARY_PATH.

> 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.

I just added a makefile variable:
  # 'c_l_flags' are to be used in both compiler and linker commands.
for options like '-pg' and '-fPIC'. I guess I should do this:

- c_l_flags := $(gprof_flag)
+ c_l_flags := $(debug_flag) $(gprof_flag)

(with some natural cleanup) next.

> 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?

Yes--see:
  https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#FOOT1