I’ve been encountering some issues with PGI 14.7 and ESMF 6.3.0rp1 today and I’ve sent emails to PGI Support about them. However, when I work around the main issue, the build ends with:
/usr/bin/ld: /opt/pgi/linux86-64/14.7/lib/libstdz.a(collate.o): relocation R_X86_64_32S against `__vtbl__Q2_3std16collate__tm__2_c' can not be used when making a shared object; recompile with -fPIC
/opt/pgi/linux86-64/14.7/lib/libstdz.a: could not read symbols: Bad value
My usual fix in this case is find the original library and recompile with -fPIC, but I can’t do that here…can I? Is this something we did bad on our end when installing PGI 14.7? If so, how can we correct it? (Note: Our sysadmins install PGI for me–my only install experience is the Free PGI for OS X–so I probably don’t know if I’m even in the right ballpark.)
Does you’re link line include “-fpic” or “-mcmodel=medium” as well?
The FPIC compiled versions of the these libraries are over in the “libso” directory (i.e. “/opt/pgi/linux86-64/14.7/libso/libstdz.a”). When “-fpic”, “-mcmodel=medium” or “-Bdynamic” are used on the link line, these versions are used.
We’ve had this set-up for several years now so I’m not sure why your just now seeing it with 14.7. Perhaps there’s something else wrong, but that would be the first thing I’d try.
I’ve taken a closer look at this and I’ve seen that this issue only appears when ESMF 6.3.0rp1 tries to link a new shared library libesmf_fullylinked.so:
# The "libesmf_fullylinked.so" version links in everything that would be
# specified in the final link step when building an executable. This
# produces a fully self-contained shared library, which has the advantage
# of being suitable to be loaded e.g. by the Python layer on top of ESMF.
# However, it does require that ALL dependencies, including all of the
# 3rd party libraries that are specified, MUST be available as
# position-independent-code (PIC). This can be difficult to ensure.
So, on one hand I’m lucky in that I don’t even link to this .so (since I never knew it existed and, well, we are a .a shop), but it does seem to indicate that maybe the collate.o in libstdz.a wasn’t compiled with -fPIC?
I’m sending a note to ESMF Support as well about this to see if they see it on their end when they build.
Yes “-shared” implies “-fpic” as well. The issue is that the linker is picking up the wrong version of the library. It needs to grab the “/opt/pgi/linux86-64/14.7/libso/libstdz.a” file instead of “opt/pgi/linux86-64/14.7/lib/libstdz.a”. The archive libraries in “libso” are built with “-fpic” while the “lib” version are not.
I’m wondering if it’s a mpicxx driver configure issue. “-shared” should cause the pgcpp driver to add “-L/opt/pgi/linux86-64/14.7/libso” your link but maybe mpicxx is calling ld directly and not adding it? What happens if you explicitly add “-L/opt/pgi/linux86-64/14.7/libso”?