[petsc-dev] petsc/master: unable to link in C++ with last night PETSC_WITH_EXTERNAL_LIB variable changes

[Éric Chamberland]

Le 18-02-10 à 12:58, Smith, Barry F. a écrit :
>
>> On Feb 10, 2018, at 11:51 AM, Éric Chamberland <Eric.Chamberland at giref.ulaval.ca> wrote:
>>
>> Ok guys!
>>
>> You found it (again...).  We are no using mpic++ to link!!!
>>
>> We are not always using the same compiler that we used to compile petsc+mpi, so we do not use mpic++ to compile (excepted for intelmpi).
>>
>> For example, I compile MPI+Petsc with g++, but I am working with clang++ and may switch to g++ for my day to day work.  This is perfectly working since... long long time ago (I won't reveal my age... ;) )
>     WOW. You are lucky this worked for you. I don't think missing C++ compilers/linkers is ever safe?
Honestly, I think yes it is safe under some constraints (not too 
different compilers).

To be sure of it we are constantly verifying our code under more than 30 
different mixes of compiler/petsc/mpi/Os each night since 17 years... 
mixing (or not) compiler used for compiling petsc vs our code with 100% 
reproducible results of our more than 2400 different validation tests 
(finite element code).

>
>
>    Eric,
>
>     Your problem is a result of Jed's constant bitching that we always list many libraries either redundantly or unnecessarily when we create our massive link line that allowed you this flexibility of linking with the "wrong" compiler. I changed the tests to not generate some redundant and unnecessary libraries to make Jed slightly less bitchy but missed the C++ one because no one uses it (except you). It would not be trivial for me to add the test because it would fail on any newer MPI that does not provide C++ bindings.
Ok, but have you tested with openmpi 1.10.x?

Maybe this is the offending library, since we do not use the MPI C++ 
API...???

Maybe I can just dump support for this "old" mpi version and it will be 
fine...

Eric