What creates ld link in devtoolset-4/root/usr/bin?

Latest response

I have two systems...a development system that was setup for me and a mock environment that I've created to test rpm builds.

I have an issue in my mock environment where it is not seeing the linker included with devtoolset-4. Comparing it to my development system, I find that in /opt/rh/devtoolset-4/root/usr/bin there is a link "ld" which points to /opt/rh/devtoolset-4/root/etc/alternatives/ld, which is also a link which points to /otp/rh/devtoolset-4/root/usr/bin/ld.bfd.

On my mock system, there is no "ld" links in any directories (and as a result, the system only sees /usr/bin/ld).

What creates the links in the above directories? Is that something manually done in a system, or is it a configuration that happens when something is installed?

I've confirmed that the devtoolset-4-runtime and devtoolset-4-binutils packages are installed in my mock environment, as I saw that they were involved with the ld.bfd and alternatives files/dirs.

Thanks for any help.

Rob

Responses

Those links are generally produced by the "alternatives system", which includes the /sbin/alternatives command and the /etc/alternatives and /var/lib/alternatives directories. In RHEL 7, it seems to be provided by... the chkconfig RPM??? (an odd choice in my opinion, but whatever).

It is a system for allowing the administrator to install two or more pieces of software that provide the same functionality (e.g. two linkers) and easily select between them. The competing pieces of software are renamed (e.g. with a suitable suffix) and the "well known filename" is replaced by a symlink which points to /etc/alternatives/, which then points back to the currently-favored version of the software.

The alternatives system will handle groups of such links, so when you use the alternatives command to switch from one linker to another, it will e.g. have the linker's man page similarly symlinked, and will change the man page link at the same time as the "main" link, so that "man ld" will always give you the man page of the linker that is currently available as "ld".

If you are familiar with the "update-alternatives" script in the Debian/Ubuntu circles, it is exactly the same thing, adapted to RedHat world.

I guess your mock environment does not include the /opt/rh/devtoolset-4/root/sbin/alternatives command, because the chkconfig RPM is not included in the mock environment?

Ok, that makes some sense.

Here is what I've found so far.... I have mock do "install @development", which installs the basic development environment. When it gets to binutils, I see this:

  Installing : devtoolset-4-binutils-2.25.1-8.el6.x86_64                                                                   128/160 
altdir /opt/rh/devtoolset-4/root/etc/alternatives invalid
altdir /opt/rh/devtoolset-4/root/etc/alternatives invalid
altdir /opt/rh/devtoolset-4/root/etc/alternatives invalid

I have found that if, after everything else is installed, I go back and uninstall binutils and then reinstall it (along with any other required packages that were automatically removed when binutils was), then the link to ld is created and is where it should be, and all is right with the world.

It would appear that something installed after binutils might be causing the problem, so that installing binutils again afterwards fixes it. But it's nothing I'm installing, because the link for ld is gone even if I only install @development.

Edit: I did check (by going into mock --shell after the linking failed) and chkconfig as a package is installed.

Binutils includes the ld command. If the binutils package wants to use the alternatives system, the installation should somehow ensure that the chkconfig package gets installed before binutils is installed, otherwise the setting up of the alternatives links for ld will fail as the alternatives tool won't be there yet.

And when the binutils package is reinstalled, it fixes the problem because /usr/sbin/alternatives is now actually present and usable during the reinstallation of binutils.

The binutils package seems to have a Requires: /usr/sbin/alternatives, but I don't know if that's enough to tell the rpm command that the alternatives command - and thus the chkconfig package - should already be completely installed (with any post-install actions already completed) at the point the binutils package is installed.

I went back and tried:

mock -r <config file> --clean
mock -r <config file> --init  (the chroot_setup_cmd only installs shadow-utils)
mock -r <config file> --install chkconfig
mock -r <config file> --chroot "ls -l /usr/sbin"  (alternatives dir is there now)
mock -r <config file> --install devtoolset-4-toolchain

Doing this, I still get the altdir invalid messages seen in the previous posts. So installing chkconfig first does not appear to matter.

Playing around with the loading of packages that devtoolset-4-binutils was dependent on (and vice versa), however, did let me find a sequence that fixes the issue for me, though I admit I do not know why it works. If I put this as my chroot_setup_cmd, then it all works fine:

config_opts['chroot_setup_cmd'] = 'install shadow-utils tar libtasn1 p11-kit p11-kit-trust openssl python-libs python libssh2 libcurl curl rpm-libs rpm policycoreutils iptables iproute libdrm iputils plymouth util-linux-ng initscripts udev libcgroup setools-libs-python libsemanage-python libselinux-python audit-libs-python policycoreutils-python devtoolset-4-runtime devtoolset-4-binutils devtoolset-4-toolchain rpm-build Lmod'

I can do a mock --clean, mock --init, and from that point on, I can load anything and run my rebuild and it uses the correct ld (no linking issue).

Unless there's some compelling not to use what I've found, I can consider this issue closed (though not resolved). It feels much less like a questionable workaround than my install/remove/install did.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.