symbol lookup error : undefined symbol pghpf_sect1v

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

We have a mixed language (C/Fortran) shared library (.so) called true_io.so that handles I/O for our various production apps.

Recently we released a new version of this shared library built with the latest 7.0-6 compiler. Our previous release of this shared library was built with 5.2 compiler.

This new shared library (7.0-6) gives the following runtime error when run with an production executable built with 5.2

missing symbol error : a325.exe : undefined symbol : [b]pghpf_sect1v[/b]

a325.exe works perfectly well with the old shared library built with the 5.2 compiler

We also noticed that most of the PGI fortran internal symbols sect* which come from libpgf90.a had been renamed from **pgf90** to pghpf_
true_io.so built PGI 5.2

nm true_io.so | grep -i sect

000000000002dd10 T pghpf_sect
000000000002e060 T pghpf_sect1
000000000002e330 T pghpf_sect1v
000000000002e5f0 T pghpf_sect2
000000000002ea60 T pghpf_sect2v
000000000002eeb0 T pghpf_sect3
000000000002f4a0 T pghpf_sect3v

true_io.so built PGI 7.0-6

nm true_io.so | grep -i sect

0000000000033990 T pgf90_sect
0000000000033e70 T pgf90_sect1
0000000000034240 T pgf90_sect1v
00000000000345e0 T pgf90_sect2
0000000000034bf0 T pgf90_sect2v
00000000000351b0 T pgf90_sect3
0000000000035b70 T pgf90_sect3v
  ..
  ..
0000000000033630 T pghpf_sect
0000000000036430 T pghpf_sect3
0000000000036ab0 T pghpf_sect3v

Newer version of a325.exe built with (7.0-6) do not exhibit this problem as they have the correct pgf90_sect1v symbol as compared to the old executable with the pghpf_sect1v symbol

This is huge issue for us as we have tons of applications that link against the shared true_io.so library. Most of the production apps have already been compiled with 5.2 and will probably not be rebuilt.

Any suggestions or ideas on how to fix this would be greatly appreciated.

Thanks.

2

Hi Waris,

Unfortunately, there is no best solution for this. 5.2 run time is not compatible with 7.0 or later runtime.

The best solution is to compile everything with latest version. If you don’t want to do that, perhaps provide two different version of shared libraries and have a script or let the user to set LD_LIBRARR_PATH to the right one?

Hongyon

3

Is there a possibility that PG could release a compatibility runtime library that could fix the missing symbol issue ?

The fix you suggested means that we have to carry two versions of our library
true_io.so, based on what version of the compiler our application was built with. Is there a tool that could tell me what library my executable was built with ?

Currently we are using something cheesy like below :

strings a325.exe | grep -i pgi

How are we guaranteed that this situation does not repeat itself with the future versions of the PGI compilers ?

4

Hi Waris,

Sorry but there is no plan yet to release a compatibility runtime library.

After 6.1, we have add the version number after 6.1 release.

Try: strings -a a.out

and grep for PGF or PGC.

We hope that everything is settled for pgf90 and hopefully it will not change.

Hongyon