pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_install fails when archivers/xz is installed



On 2020-08-08 06:58, Greg Troxel wrote:
Jason Bacon <outpaddling%yahoo.com@localhost> writes:

On 2020-07-29 17:26, Greg Troxel wrote:
Jason Bacon <outpaddling%yahoo.com@localhost> writes:

The point here is not to add system lib dirs, but to exclude
${PREFIX}/lib.  It's my understanding that RPATH overrides all other
search paths, so this would ensure that pkg_install binaries don't get
fooled into using the wrong libs by LD_LIBRARY_PATH and such.
That is not my understanding at all.  I expect LD_LIBRARY_PATH, any
RPATH values, and system libs, in that order.  I would suggest that you
experimentally validate this rather than make assumptions.
This was not an assumption.

 From the ld man page:

            The linker uses the following search paths to locate required
            shared libraries:

            1.  Any directories specified by -rpath-link options.

            2.  Any directories specified by -rpath options.  The difference
                between -rpath and -rpath-link is that directories
                specified by -rpath options are included in the
                executable and used at runtime, whereas the -rpath-link
                option is only effective at link time. Searching -rpath
                in this way is only supported by native linkers and
                cross linkers which have been configured
                with the --with-sysroot option.

            3.  On an ELF system, for native linkers, if the -rpath and
                -rpath-link options were not used, search the contents
                of the environment variable "LD_RUN_PATH".

            4.  On SunOS, if the -rpath option was not used, search any
                directories specified using -L options.

            5.  For a native linker, search the contents of the environment
                variable "LD_LIBRARY_PATH".
Wow, this is really different between BSD and Linux.   Is that about the
run-time linker from the binary, or about ld(1) and how it finds things
at link time?

 From ld.elf_so on NetBSD 8:

      The linker will search for libraries in three lists of paths:

      1.   A user defined list of paths as specified in LD_LIBRARY_PATH and
           ld.so.conf(5).

           The use of ld.so.conf should be avoided as the setting of a global
           search path can present a security risk.

      2.   A list of paths specified within a shared object using a DT_RPATH
           entry in the dynamic section.  This is defined at shared object link
           time.

      3.   The list of default paths which is set to /usr/lib.
ld and ld.so have basically the same priorities.  However, a little more digging revealed that rpath is dying a slow death in the linux world and at some point in the future LD_LIBRARY_PATH will likely have the highest priority even on RHEL/CentOS.

So the only option for protecting users form themselves will probably be to scrub the env, which I'm also doing already. auto-pkgsrc-setup generates two variants of env modules and startup scripts:

1. One that scrubs the env of PATH, LD_LIBRARY_PATH, CFLAGS, etc. This is necessary for clean package builds and recommended for most users running them.

2. Another tagged "-non-exclusive" which leaves the users' env intact and simply prepends pkgsrc dirs to PATH.

I don't think any core pkgsrc change is necessary since this is
already fairly well-supported by PREFER_PKGSRC/PREFER_NATIVE.  I would
only aim to educate people about their use.
If the consensus is that on Linux, because of old libs (FC derivatives)
or unstable libs, people should steer hard to PREFER_PKGSRC, we should
set the defaults that way.  As pkgsrc maintainers, we curate decisions
in the best interests of most users, in addition to providing knobs for
others.  You have made what feels like a strong argument that using base
libs that could have been avoided isn't generally a good idea.
This is based on 8 years experience using pkgsrc on CentOS and figuring out ways to prevent problems.  Except for a few edge-cases like curl requiring mozilla-rootcerts and reasonable arguments against making it a dependency, we've had almost no surprises in the past few years.

The potential issues with changing shared libs on bleeding-edge distros is more speculative, but I think pretty obvious.  On CentOS, S.O. versions almost never change, so we don't worry about ABI changes.  But we occasionally had issues early-on with Yum libraries appearing or disappearing, which causes similar results if PREFER_PKGSRC is not used.  A Yum autoremove can remove a shared lib that pkgsrc depends on, causing existing pkgsrc binaries to fail. Likewise, installing a Yum package with different build options than the pkgsrc equivalent might cause pkgsrc binaries to fail if they decide to grab the Yum version.  The same could happen with Debian's apt, Gentoo Portage, or any other foreign installations.  When pkgsrc manages most of its own dependencies, issues like these become almost non-existent.  I don't recall encountering one since I started using PREFER_PKGSRC=yes, except a few WIP packages that didn't utilize rpath properly.




Home | Main Index | Thread Index | Old Index