Re: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux

Brooks,

On 10/10/2013 12:44 AM, Brooks Moses wrote:
> Christian,
>
> I'm going through old libtool patches that haven't been reviewed, and
> came across this one.  (Sorry that these have been ignored so long.)
>
> On 09/21/2012 10:34 AM, Christian Rössel wrote:
>> please find attached a patch that fixes the erroneous detection of PIC
>> flags in case when CXX is a MPI wrapper that uses pgCC or pgcpp on
>> GNU/Linux as well as the wrong rpath option.
>
> I do have one small question about the patch, before I commit it:
>> -        case `$CC -V 2>&1 | sed 5q` in
>> +        case `$CC -V 2>&1` in
>
> You make this change in a couple of places where we match verbose
> compiler output looking for (among other things) "*Portland\ Group*".
> The "sed 5q" simply has the effect of trimming off the first 5 lines of
> the output and ignoring the rest -- presumably to avoid spurious matches
> to things in later output.
>
> Is this change required in order to correctly match the Portland Group
> compilers?  That is, is the expected "*Portland\ Group*" coming
> somewhere after the first five lines?  That seems odd.

the change is required when using MPICH2 (tested with version 1.3.2p1) 
as the output of mpicxx -V 2>&1 | sed 5q is

/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 
has invalid symbol index 12
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 
has invalid symbol index 13
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 
has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 
has invalid symbol index 2
/usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 
has invalid symbol index 12


> The rest of the patch looks good to me, though I'd be curious to see a
> copy of the "$CC -V" output that you're matching.  (In particular, I'd
> like to see output from both pre-version-6 and post-version-6 versions
> to see how the version-matching relates to the expected input.)

Most of the patch is copy-paste from locations where cc_basename matches 
"pgCC* | pgcpp*)", the version-matching was copied as well.

As I wrote in [1], I'm not sure if copy-pasting is the best approach to 
deal with compilers used through a wrapper. Extending _LT_CC_BASENAME 
might be a more robust approach.

If you prefer an improvement of _LT_CC_BASENAME over copy-pasting, 
please ignore my patch. Please let me know if patching _LT_CC_BASENAME 
is an option.

Thanks,
Christian

[1] https://lists.gnu.org/archive/html/libtool-patches/2013-10/msg00021.html

> Also, thanks for the test reports that you included.
>
> Thanks,
> - Brooks
>
>