Re: Clash of lib64 symlink and R extensions in wrappers

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Tue, 26 May 2020 07:01:30 -0400
schrieb Greg Troxel <gdt%lexort.com@localhost>:

> So you are saying that even given a search path that puts /usr/pkg/lib
> before /usr/lib64, the base system gcc on ? flavor of GNU/Linux is
> choosing the one in /usr/lib64 first?

This is the case for specifying library search paths via environment
variables. -L/foo/lib on the command line does work, but setting
LIBRARY_PATH=/foo/lib makes gcc look in /foo/lib/../lib64, then in all
those system library directories with lib64 and other arch names, and
after that finally the /foo/lib that I intended to put in front.

This is the normal behaviour of gcc, maybe on Linux, but maybe on
others, too … everywhere where multilib or multiarch is a thing, I
suppose. I did not hit that before with a minimal base system, but
recently I started to build a software tree on a system that had lots
of software installed from the official repository (Ubuntu) and noticed
system libs creeping into my builds despite having installed a newer
version with pkgsrc.

> > Suggestions? Of course I'd like to have a sane search behaviour for
> > gcc, but I won't be able to change distro compilers like on CentOS.  
> 
> Why can't you just apply a patch to the gcc package to fix it, rebuild
> it, and install the upgraded package on your package build system?

First, I am not sure how that patch should look to avoid breaking
things. Also, out of principle, I'd rather not have to hack the distro
compiler. I figure that it's a valid use case for pkgsrc to use a
present default compiler on the platform and live/work around its
specifics, to some degree.

> You could also build a gcc from pkgsrc and use that instead.

For most installs, I actually do install my own gcc and I might end up
patching it for proper handling of library search. But there might be
reasons why nobody did that yet and why the current behaviour is as it
is. I'm not the first one stumbling over this, see

	https://stackoverflow.com/questions/12419363/why-does-g-look-in-library-path-lib64-and-where-is-this-documented

for some discussion.

I am actually not sure how a gcc from pkgsrc would behave. I never
tried the packaged gcc as my usual build is

1. base toolchain, compiler, binutils, MPI from OS distro or from my
   own build
2. pkgsrc on top of that base
3. some scientific application using dependencies from pkgsrc

I guess I should check if pkgsrc's gcc doesn't have that search order
thing. I'd not be surprised if it still has the same behaviour, though.

I repeat: This is not about directories specified with -L on command
line. It is about the environment variables for default library
locations. We manage those in environment modules, like PATH for user
binaries. I guess you don't see this as an issue unless you do the
same. But once you do, and basically every HPC installation does, this
may bite you.

The beauty is that with LD_RUN_PATH and LIBRARY_PATH set, along with
PATH for the correct compiler and CPATH for headers, a simple

	gcc -o bin src.c -lfoo

does the right thing, even buring RPATH/RUNPATH into the binary so that
it works in future without any environment variables set.


Alrighty then,

Thomas


-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg