PGI 6.0-5 p3 dir -- old Athlon/PIII versions

I installed and tested the compilers some months ago on some of our newer Opteron based systems running 32 and 64 bit Redhat Enterprise 3. Everything worked fine. I just now tried to use the compilers on an older cluster based on Athlon MP processors. These old processors only have sse version 1. The x86rc directs the compiler to use the binaries in linux86/6.0/bin/p3. However, this directory is empty. I just tried a reinstall into a different directory running the installer on one of the older systems. No joy - the p3 directory is still empty.

A quick test:

pgcc -V x.c

pgcc 6.0-5 32-bit target on x86 Linux
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2005, STMicroelectronics, Inc. All Rights Reserved.
pgcc-Error-Required tool pgc was not found
pgcc… looked for pgc at /a/pgi/linux86/6.0/bin/p3/pgc

and so on.

I hope I’m missing something simple. Anyone know what it is?


Hi Barry,

Can you look at your install log and look for any errors? The 32-bit compilers wont install on a 64-bit system unless the system has 32-bit compatability libraries installed. But since you installed directly on a 32-bit system (yes?) it should not be a problem. Also, make sure your not installing over NFS since the installer uses information found on the local system to determine what to install.

  • Mat

Hi Mat,

Good suggestion. Thanks. It was something simple. The AFS filesystem doesn’t do hard links between directories. So something like “ln …/xxx yyy” fails (even though “ln xxx yyy” succeeds). A symbolic link works fine, or a simple copy of the file. Moreover, the tar files contain hard links because tar is smart about hard links. The files in the p3 subdirectory are hard links to those files in the parent directory. There are a bunch of permission errors when the tar file extracts because AFS does permissions differently from *nix. For example, from a script log of the install:

Note: /usr/local/pgi6 seems to contain a previous installation.
This installation may fail to install files properly.
You may see messages from tar about file permissions, etc.

Installing software into /usr/local/pgi6 (this may take some time).
tar: linux86/6.0/bin/pgc: Cannot change ownership to uid 0, gid 300: Operation not permitted

and many more, but way down in the output is:

tar: linux86/6.0/bin/p3/pgc: Cannot hard link to `linux86/6.0/bin/pgc’: No such file or directory

because the install script is using

tar cf - $i | ( cd $dir; tar xf - )

to copy the files where $dir is in AFS space. I missed these the first time around.

Later in the install process I see,

ln: creating hard link /usr/local/pgi6/linux86/6.0/PORTABLE/lib-linux86-g225/libpgc.a' to /usr/local/pgi6/linux86/6.0/lib-linux86-g225/libpgc.a’: Invalid cross-device link

This is from the postinstall script where it is doing more hard links.

I understand that hard links are good in that you can put one file many places without taking up any more disk space or having to worry about having different versions in different places. It seems to me that for the p3 directory, symbolic links would work as well. Then again, disk is cheap. Perhaps just another copy of the file would work best. (Lastly, why is there a p3 directory if the files are just the files in the parent? Do the binaries behave differently if invoked from within p3, or is this just an historical artifact?)

In any event, I’ve got things working now. I had to extract the distribution tar file on local disk (I had been extracting the installer into AFS space), and then install on local disk in order to get all the hard linked files. I could then compare my networked install to the local install and copy the missing files in p3, PORTABLE, and REDIST directories from local to network.

I think I can make the whole install work via the following recipe.

1.) Extract the tar file into local disk space.

tar xvf linux86.tar.gz

2.) Copy the result recursively into AFS space.

cp -pr . $path

where $path is in AFS.

3.) Edit postinstall in AFS space to replace ln with cp or cp -p.

4.) Run the install from AFS space.

Maybe I’ll test that tomorrow.


Hi Barry,

I’m glad you got things figured out. To answer your question:

Lastly, why is there a p3 directory if the files are just the files in the parent? Do the binaries behave differently if invoked from within p3, or is this just an historical artifact?

Our 32-bit compilers use two different code generators, one used for systems that have SSE instructions, and one for non-SSE (ie p3) systems. Note that the default is to use non-SSE instruction even on SSE enabled systems. To enable SSE add the “-Mscalarsse” or “-fastsse” flag.

  • Mat