What creates ld link in devtoolset-4/root/usr/bin?
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?
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.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
