|
From: | Christian Rössel |
Subject: | Re: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux |
Date: | Mon, 14 Oct 2013 15:20:05 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
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` inYou 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
[Prev in Thread] | Current Thread | [Next in Thread] |