PATH issue with makelocalrc

On our automated build systems we use non-standard gcc installations (gcc not located in /usr/bin). When trying to build with PGI 19.10 / 19.4 this has caused some problems due to the following line at the top of makelocalrc:

PATH=/usr/bin:/bin:$PATH

This finds an older version of gcc without c++ 11 support, which causes problems later in the build.

In future releases would it be possible to modify this line to put the user PATH entries first to avoid this issue?

PATH=${PATH}:/usr/bin:/bin

Thanks,

-David

Hi David,

For non-default GNU paths, you should be using the “-gcc”, “-gpp”, and “-g77” options with the full path to these compilers as the argument.

For example, here’s what I use to configure to use the GNU 9.2 compilers in a non-standard location:

% makelocalrc -d . -x -gcc /home/thirdparty/gcc/gcc-9.2.0/linux86-64/bin/gcc -gpp /home/thirdparty/gcc/gcc-9.2.0/linux86-64/bin/g++ -g77 /home/thirdparty/gcc/gcc-9.2.0/linux86-64/bin/gfortran

Hope this helps,
Mat

Hi Mat,

Thanks for the feedback.

I should probably give a bit more information about how we have things set up. We have a centralized network installation of the CE PGI compilers for general developer use, and a node-locked licensed version on a tightly controlled build machine for formal package preparation. The CE installation is accessed from a number of physical systems and virtual machines running docker containers with GCC installations from 4.4 to 7.4. The developers do not directly generate a localrc file, instead we have a system of compilation scripts that generate a localrc file “on-the-fly” when PGI is selected. All together there are quite a few different locations where the GCC installations could reside, making it difficult to specify the full path.

ndir=$(dirname $0)
export PGI_LOCALRC=`readlink -f ${ndir}/../../$PLATFORM`/pgilocalrc
 export PGI_LOCALDIR=`readlink -f ${ndir}/../../$PLATFORM`
/common/pgi/linux86-64/latest/bin/makelocalrc -installdir /common/pgi/linux86-64/latest/ -net ${PGI_LOCALDIR} -o > ${PGI_LOCALRC}
echo "switch -pthread is append(LDLIB1=-lpthread);" >> ${PGI_LOCALRC}
echo "Using localrc = " ${PGI_LOCALRC}

In the short term I simply commented out the “PATH=/usr/bin:/bin:$PATH” line in makelocalrc, which is the same workaround I used for older versions. This seems to have worked, however I now have a different problem that seems to be specific to PGI 19.10:

At link time I see the following
/usr/bin/ld: cannot find /usr/lib64/crt1.o: No such file or directory

This seems to be a duplicate of the post here (https://forums.developer.nvidia.com/t/ld-cannot-find-usr-lib64-crt1-o-usr-lib64-crti-o/136410/1).

Manually adding DEFSTDOBJDIR to the generated localrc allowed me to proceed further, but the final link still fails with:

/usr/bin/ld: BFD version 2.20.51.0.2-5.48.el6 20100205 internal error, aborting at reloc.c line 443 in bfd_get_reloc_size

I should also note that this only occurs with V19.10, not 19.4, and it only occurs when compiling within a docker container. Maybe if I know what changed from 19.4 -> 19.10 it will point me in the right direction. Are you aware of any recent changes that could be related?

Thanks for your help,

-David

Hi David,

I’ve put in an RFE (TPR #28440) to see if we can have makelocalrc pick up the GNU version in the user’s PATH first, rather than the system default. I’m thinking just changing the script so it includes “/usr/bin” after the $PATH (i.e. PATH=$PATH:/usr/bin:/bin), but will our installation folks to make sure that there’s no unintended consequences.

As for the DEFSTDOBJDIR not getting set, I should have reported this one myself since I hit it all the time. It’s typically only a problem for folks that use non-default GNU installs, which isn’t very many, but now that we have two UF post about it, I went ahead and filed an RFE. (TPR#28441)

As for the linker error, I’m not sure. It looks like an internal error in the linker itself and doing a web search, show many other users encountering the same error. This ld looks to be quite old (circa 2010). Are you able to use a newer version?

-Mat

Thanks for the reply, I came to the same conclusion last night about the internal ld error. I’m going to ask our sysadmin to upgrade binutils in our containers. I’ll let you know if this resolves the issue, but it may take a few days.

Thanks for submitting the RFEs for the DEFSTDOBJDIR and non-standard GNU install path issues, it will definitely make thing cleaner on my end in the long run.

Have a great weekend,

-David