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

[Vadim Zeitlin]

On Thu, 15 Nov 2018 23:52:44 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-04-12 00:07, Greg Chicares wrote:
GC> [ https://lists.nongnu.org/archive/html/lmi/2017-04/msg00015.html ]
GC> > 
GC> > /home/greg[0]$schroot --chroot=cross-lmi
GC> > /home/greg[0]$unset LMI_HOST
GC> > /home/greg[0]$cd /opt/lmi/src/lmi
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> This updated command:
GC> 
GC> make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 -fno-pie
GC> -Wno-pedantic -Wno-useless-cast' CFLAGS='-m64 -fno-pie' LDFLAGS='-m64
GC> -no-pie' unit_tests cli_tests >../log 2>&1
GC> 
GC> adds '-Wno-useless-cast' to ignore a pervasive boost-1.33.1 problem,

 I wonder why was it necessary when we already have a pragma disabling this
warning in boost_regex.hpp. Do you use a version of gcc older than 7 or is
there something else going on here that I'm missing?

GC> and '-fno-pie' and '-no-pie' to prevent numerous diagnostics like:
GC> 
GC> relocation R_X86_64_32 against `.rodata.str1.1' can not be used when
GC> making a shared object; recompile with -fPIC

 I really don't think -no-pie is the right flag to use. Why not add -fPIC
and compile all code as position-independent instead? It does impose a
slight overhead for the code which never ends up in a shared library, but I
don't think it's really noticeable.

GC> but perhaps $LDFLAGS needs to vary between $EXEEXT and $SHREXT,
GC> because for '.so' targets I still get:
GC> 
GC> /usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crt1.o: in function 
`_start':
GC> (.text+0x20): undefined reference to `main'
GC> collect2: error: ld returned 1 exit status

 This looks like a wrong linking command to me, i.e. is there a -shared in
it? It seems that the linker is trying to create an executable instead of a
shared library here.

GC> I also get:
GC> 
GC> /usr/bin/ld: skipping incompatible /opt/lmi/local/lib/liblzma.a when 
searching for -llzma
GC> 
GC> which is apparently just a nuisance stemming from
GC>   $(shell xml2-config --libs)
GC> in 'posix_fhs.make': it finds the 32-bit msw xml2-config instead of the
GC> debian native one in /usr/bin/ , which was built without lzma support;
GC> this happens even though I've installed a native liblzma-dev in my chroot.

 I'm not sure how are things expected to work exactly in this case, but I'd
strongly advise avoiding mixing MSW and native binaries under the same
directory. I.e. it seems like your native build is using xml2-config from
/opt/lmi/local/bin which it really shouldn't see at all in the first place/

GC> Another related message from the past said:
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2017-05/msg00034.html
GC> | I put host-specific
GC> | stuff in a directory called ${uname}-${uname -m} and I add a "-compiler"
GC> | suffix when more than one ABI is used. So I can have directories like
GC> | Linux-x86_64-clang, Linux-x86_64-gcc6 and even Linux-x86_64-suncc
GC> 
GC> which I reference here because it will be useful once I get this
GC> thing to build.

 Yes, the advice from the past me about not mixing binaries with different
ABIs is even better than the advice from the present me about not mixing
binaries for the different architectures.

GC> And yet another related message from the past said:
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2017-05/msg00018.html
GC> | make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 -fpic 
GC> | -Wno-pedantic' CFLAGS='-m64 -fpic' LDFLAGS='-m64' cli_tests
GC> |
GC> | and everything built, but to run the tests I needed to do this:
GC> |
GC> | LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/opt/lmi/src/build/lmi/Linux/gcc/native'
GC> 
GC> but, if I obliterate the build directory:
[...]
GC> but still I get (e.g.):
GC> 
GC> ./lmi_cli_shared: error while loading shared libraries: liblmi.so: cannot 
open shared object file: No such file or directory
GC> 
GC> Vadim, do you see anything obviously wrong in my approach?

 The only thing I can think of is that your LD_LIBRARY_PATH is not
exported, which could well be the case if you hadn't used it before. So
please try either

        $ export LD_LIBRARY_PATH
        $ ./lmi_cli_shared

or, as I typically do

        $ LD_LIBRARY_PATH=/opt/lmi/src/build/lmi/Linux/gcc/native 
./lmi_cli_shared

If this doesn't work, you should consider setting LD_TRACE_LOADED_OBJECTS
or LD_DEBUG (see ld.so(8)), but normally it really, really should work
because lmi makefiles don't do anything with rpath (they almost certainly
should, but this is another story).

GC> I don't really understand '-fpic' and '-f[no-]pie'

 With x86-64 Linux, all code used in shared libraries, including code in
the static libraries which are linked into a shared one, must be
position-independent (in 32 bits this was strongly recommended but, due to
the peculiarities of this architecture, not actually necessary and so not
imposed, while in 64 bits things just can't work without it), i.e. be
compiled with -fPIC (or -fpic, but it's the same for x86-64, I think).

 For the executables, using position-independent code is required to
support ASLR (address space layout randomization) which complicates the
exploitation of security holes in C and C++ code. Whatever you think about
ASLR (and if you think it's a hack, I won't argue with you, but it's a
pretty effective one), it's better to not disable PIE (position independent
executable) without some good reason. BTW, -fpie results in a smaller
overhead than -fPIC/-fpic, so it's a good idea to use it for the code which
only ends up in the executables and not a library.

 Sorry if this explanation is simplified too much,
VZ