Description of problem: After fix of bug#1017604 32 bits versions of devtoolset libs located in /opt/rh/devtoolset-9/root/usr/lib are added to $LD_LIBRARY_PATH together with 64 bits in /opt/rh/devtoolset-9/root/usr/lib64 when script is run in *64* bits environment. However, should the opposite also be done? Of course Devtoolset is 64 bits only, however to cross build 32 bits RPMS, something like the following is used: $ setarch i686 rpmbuild -ba --target i668 foo.spec Where foo.spec contains %build . /opt/rh/devtoolset-9/enable %install . /opt/rh/devtoolset-9/enable The enable script uses the following call: rpmlibdir=$(rpm --eval "%{_libdir}") and output from rpm --eval "%{_libdir}" depend on arch: $ setarch i686 rpm --eval %_libdir /usr/lib $ rpm --eval %_libdir /usr/lib64 and this line: export LD_LIBRARY_PATH=/opt/rh/devtoolset-9/root$rpmlibdir$rpmlibdir32:/opt/rh /devtoolset-9/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} just add 32 bits versions. If devtoolset-9-elfutils is installed, rpmbuild will use /opt/rh/devtoolset-9/root/usr/bin/eu-strip (to build debuginfor packages) however, this will not work as it depend on libs in /opt/rh/devtoolset-9/root/usr/lib64, which is not added to $LD_LIBRARY_PATH. To reproduce: $ cat p.sh #! /bin/bash set -x . /opt/rh/devtoolset-9/enable /opt/rh/devtoolset-9/root/usr/bin/eu-strip --version $ setarch i686 ./p.sh + . /opt/rh/devtoolset-9/enable ++ export PATH=/opt/rh/devtoolset-9/root/usr/bin:/usr/sbin:/sbin:/usr/bin:/bin ++ PATH=/opt/rh/devtoolset-9/root/usr/bin:/home/trosten/bin:/usr/sbin:/sbin:/usr/bin:/bin ++ export MANPATH=/opt/rh/devtoolset-9/root/usr/share/man: ++ MANPATH=/opt/rh/devtoolset-9/root/usr/share/man: ++ export INFOPATH=/opt/rh/devtoolset-9/root/usr/share/info ++ INFOPATH=/opt/rh/devtoolset-9/root/usr/share/info ++ export PCP_DIR=/opt/rh/devtoolset-9/root ++ PCP_DIR=/opt/rh/devtoolset-9/root +++ rpm --eval '%{_libdir}' ++ rpmlibdir=/usr/lib ++ '[' /usr/lib '!=' /usr/lib ']' ++ export LD_LIBRARY_PATH=/opt/rh/devtoolset-9/root/usr/lib ++ LD_LIBRARY_PATH=/opt/rh/devtoolset-9/root/usr/lib ++ export LD_LIBRARY_PATH=/opt/rh/devtoolset-9/root/usr/lib:/opt/rh/devtoolset-9/root/usr/lib/dyninst/dyninst:/opt/rh/devtoolset-9/root/usr/lib ++ LD_LIBRARY_PATH=/opt/rh/devtoolset-9/root/usr/lib:/opt/rh/devtoolset-9/root/usr/lib/dyninst/dyninst:/opt/rh/devtoolset-9/root/usr/lib ++ export PKG_CONFIG_PATH=/opt/rh/devtoolset-9/root/usr/lib64/pkgconfig ++ PKG_CONFIG_PATH=/opt/rh/devtoolset-9/root/usr/lib64/pkgconfig + /opt/rh/devtoolset-9/root/usr/bin/eu-strip --version /opt/rh/devtoolset-9/root/usr/bin/eu-strip: error while loading shared libraries: libelf.so.dts.1: cannot open shared object file: No such file or directory As 64 bits execution of /opt/rh/devtoolset-9/enable already adds 32 and 64 bits, and 32 bits execution *should* also add both variants, logic can be simplified and both dirs added regardless of bits.
Fixed again. Martin, does this look OK to you now?
Looks fine now, thanks!
Verified with devtoolset-11-runtime-11.0-3.el6 and devtoolset-11-runtime-11.0-3.el7.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: devtoolset-11), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2021:4652