This is a reply to a somewhat older thread about PGI and LAM on 64bit
GNU/Linux (thus the generous quoting). PGI support has been helpful to
discuss issues -- here's a summary of the findings so far:
* Ralf Wildenhues wrote on Fri, May 20, 2005 at 03:15:01PM CEST:
>
> There is still an unsolved question about shared library support in PGI
> compilers on 64bit platforms.
>
> * Ralf Wildenhues wrote on Wed, May 18, 2005 at 11:35:21AM CEST:
> > * Troy Telford wrote on Thu, May 05, 2005 at 09:39:18PM CEST:
> > > On Thu, 05 May 2005 11:38:31 -0600, Ralf Wildenhues wrote:
> > >
> > > >>After running configure, one of the things it appears to generate
> > > >>are a few 'libtool' scripts scattered around the source tree.
> > > >>
> > > >>After running into a few problems where the compiler is telling me I
> > > >>need to compile with -fPIC, (but PGI uses both -fpic and -fPIC; so
> > > >>whatever). I looked at the actual 'pgcc' invocation. libtool isn't
> > > >>invoking pgcc with -fPIC.
> > > >
> > > >You mean: at link time it isn't. Right?
> > >
> > > Sure. I'll start where it enters a directory and then starts running
> > > 'make'
> >
> > I changed this in Libtool-1.5.18, based solely on this discussion here.
> > Our C++ (tagdemo) tests still fail. I do not know the correct way to
> > fix this, PGI support has been informed about the issue but has stayed
> > silent so far.
>
> After all, I believe this was not enough.
>
> I can get the Libtool C++ demo to pass on x86_64 when I add the option
> -mcmodel=medium
> to the compile command lines. It seems that this is necessary when
> vtables are used. I am really asking myself why this is not enabled by
> default with pgCC? Now I am trying to evaluate whether Libtool should
> enable this by itself or whether we should leave this up to the user and
> only document it (e.g. because there might be a good reason against
> doing so).
*snip*
> Is it sufficient to pass this to pgCC only, or would pgcc/pgf77/pgf90
> need this as well in some circumstances?
>
> Does version 5.x of the PGI compilers need this as well on x86_64?
First thing: There are a couple of bugs in version 6 of the compiler.
The first issue is that, while linking, -fpic (-fPIC is an alias)
chooses the shared libraries from the libso/ directory over the static,
non-PIC ones from the lib/ directory (all below $PGI installation dir).
This might be regarded as poor design rather than an outright bug.
One interesting symptom is a C++ runtime failure:
| C++ runtime abort: internal error: static object marked for destruction more than once
followed by a core dump.
Supposedly, setting
| set COMPLIBSO=$COMPBASE/$COMPSYS/$COMPVER/libso;
| set COMPLIBOBJ=$COMPBASE/$COMPSYS/$COMPVER/libso;
| set STDRPATHSO=-rpath $COMPBASE/$COMPSYS/$COMPVER/libso;
in ones localrc file is a workaround to select the libs from libso by
default. Or adding -fPIC to the link line, which I have put in Libtool.
The second issue is incorrect code generation for PIC C++ code which
results in link errors on at least Fedora Code 3: Some vtbl relocation
is compiled R_X86_64_PC32 and will cause link failure. They are working
on this. Apparently this problem is not present in version 5.2-4, and
not exposed/apparent on other linux systems.
Regards,
Ralf
|
