Portability Questions

What is the Linux portability package?

The Portability Package enables programming for multiple Linux versions using PGI compilers.

The 6.0 release of the PGI Portability Package is a minimal set of the libs needed by users that do not have PGI compilers but wish to run a program built with PGI compilers. This release supports the 6.0-x release Linux86 32-bit PGI compilers.

The Portability Package currently is now available for the 64-bit Opteron/EM64T Linux86-64 products. For technical reasons, users with executables built -mcmodel=medium may need to use shared libraries, and so a package that non-PGI subscribers can obtain and use is necessary.

Who needs the portability package?

If you do not have our compilers, but wish to run a program that was built with our compilers, you may need the Portability Package in order to run the program.

If you have our compilers on one machine, but want to run executables on another machine, this is for you. It will put the correct libs on your other machine, even if it is a different Linux than your development machine.

If you are a developer or distributor of pgi-compiled programs, this would be a way to check out the portability of your application. It would help you support your application on a larger set of platforms, by telling users where to go to get the right libs installed.

Is there some way I can avoid this?

If you do not use libpthread routines in your application, libpgc.so can sometimes be linked statically without a problem when executing elsewhere. By renaming or removing libpgc.so, libpgc.a will be used, and often results in successful execution.

64-bit applications that use -mcmodel=medium may not link statically at all, and so the package may be necessary. -fpic runtime libs have a 32-bit offset, and sometimes need to reside near other runtime libs in the shared area of Linux program memory.

What do you mean by portability?

There are libraries in Linux, like libc.so and libpthreads.so, that are shared libraries, and are dynamically linked. They contain most of the Linux-version differences between releases. If users build programs like foo with 

gcc -o foo foo.c

on Red Hat 7.3, for example, they can usually run them on a Linux release Red Hat 9.0, because the most sensitive routines from libc.so that may work very different on Red Hat 9.0, are using functions from the Red Hat 9.0 version of libc.so, because of dynamic linking. This is why you do not have to have a separately built executable for each Linux version.

We also have Linux-version dependent libs, called libpgc.so and libpgthread.so that a user can install on their system, and then run applications built elsewhere.

Will every program I build run everywhere?

No. Much depends on what system you build it on, and how much your program uses system routines that have changed from Linux release to Linux release. One area where change has been significant is libpthread.so, and this is used by pgi compilers for -Mconcur and -mp openmp programming.

Most of this portability is supported for forward execution, meaning running a program on the same or a later version of Linux, and not a prior release.

For example, a user who compiles and links a program under Suse 9.1 should not expect the program to run without incident on a Red Hat 8.0 system. It may run, but it is less likely. Developers might consider building applications on earlier Linux versions for wider usage.

What Linux versions have you tried out?

We built a number of programs on a number of systems. See the release notes for the systems we support. We try most of them.

We saw some problems when moving forward in releases, and just a few incidents going backward.

A good rule is that the later releases ought to run prior built code.

Note that we found problems running Red Hat 8.0 built code on every other system including Suse 8.1. Codes built on Suse 8.1 did not have similar problems on Red Hat 8.0.

We also found problems with code built on Red Hat 7.3 running on Red Hat 9.0. We believe the problem lies with code that uses libpghtread routines from our custom libpgthread.so trying to run on new Linux versions using the libpthread.so floating stacks. Suse 9.0 should also have this problem.

How do I install the portability package?

You can find the portability packages here. Download the one you need, untar it, and run the install script.

You can then add the installation directory to your library path. In order to use the installed libraries, you can either modify /etc/ld.so.conf and run ldconfig(1) or modify the environment variable LD_LIBRARY_PATH, as in

setenv LD_LIBRARY_PATH /usr/local/pgi
or 
export LD_LIBRARY_PATH=/usr/local/pgi

Are there licensing issues?

The installation presents our standard usage license. The libs can be distributed for use with PGI compiled applications, within the provisions of that license.

What else should developers consider?

Remember, developers, your application, when compiled without any -tp switches, generates code for the type of chip your machine is using. 

-tp px    !will generate code for any cpu type

-tp p6    !will generate Pentium 2 or greater -- most users have this.

are good choices for portable execution. If you use -Bstatic ! as in

pgcc -Bstatic foo.o

when linking an application, all the local .so files are statically linked, and you will not have the advantage of portability.

How do I run a PGI developed program on a Windows machine without PGI compilers installed?

PGI's compilers for the supported versions of Microsoft Windows include Microsoft Visual C++ 2005 Redistributable Package. This package needs to be installed on the target system. In addition, there are some dynamically linked PGI libraries that should be present, either locally or in a path.

You can remove most of the PGI dll dependencies by linking -Bstatic_pgi, but currently not pg.dll.

The Microsoft Visual C++ 2005 Redistributable Package for 32-bits (x86) is available from Microsoft. If you have problems, go to http://www.microsoft.com/downloads and follow the Visual C++ link to the Microsoft Visual C++ 2005 Redistributable Package (x86).

A Microsoft Visual C++ 2005 Redistributable Package for 64-bits (x64) is also available. If you have problems, follow the same path descibed above to the Microsoft Visual C++ 2005 Redistributable Package (x64).

Both packages must to be executed to install them. Copying over the Microsoft libraries from the PGI compiler area will not work. Once you have installed the packages, copy over the library pg.dll located in the C:\Program Files\PGI\Win32\REDIST or C:\Program Files\PGI\Win64\REDIST directory to the C:\WINDOWS\System or C:\WINDOWS\System32 directory of the target system and execute the application.

Click me