Re: Clash of lib64 symlink and R extensions in wrappers

[Greg Troxel <gdt%lexort.com@localhost>]

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

> The gcc8 from pkgsrc also puts /foo/lib/x86_64-redhat-linux/8.3.0/ and
> /foo/lib/../lib64/ first, then all other 64-like directories, then the
> actual /foo/lib I wanted.
>
> Is this known/desired?

This is basically a collision of world views, where Linux made a
decision to put native libs in lib64, and NetBSD chose to put native
libs in lib and handle i386 compat as emulation.  It's really about
whether a system *is* a 64-bit system (BSD), or whether it's some
multi-arch 32/64 blend (Linux).

For better or for worse, pkgsrc does not support this multi-arch notion,
and puts native libraries in lib.

I am not sure that Linux really supports it either; when you have a
nominally x86_64 Linux system, and you build a program, I don't think
you get both lib and lib64 variants installed.

Arguably, gcc as built from pkgsrc on Linux should deal with lib64 as
that particular Linux flavor does, for library directories controlled by
the base system.  And for library directories controlled by pkgsrc, it
should not have any lib64 treatment.  For other directories, it probably
needs some configuration.

It's an interesting question of how to address this.   I don't think an
approach which requires per-package accomodation of lib64 is reasonable.

How many things use this LIBDIR environment variable?  I was not even
aware of that until your messages; I thought library search paths had to
be specified with -L.