[petsc-dev] PETSC_WITH_EXTERNAL_LIB is not including the correct gcc directories

[Hector E Barrios Molano]

Satish,

My problem is that my application links with PETSc and another library 
(Iphreeqc) that uses libstdc++. I compiled this other library with a 
newer gcc (6.1). Then, during the configuration of my application (with 
CMake) it looks into petscvariables to get the additional libraries 
required and  there it gets the old gcc path.

When I am linking my  application the linker gets libstdc++ from the old 
path instead of the new path and it breaks.

This is not a problem if I use the default gcc (but for the system I am 
working now it is quite old) or if I do not link another library which 
requirements can conflict.

Best regards,

Hector


On 10/23/18 4:34 PM, Balay, Satish wrote:
> BTW: You have not stated what problem you are encountering due to this reference to old gcc libraries from ifort.
>
> Satish
>
> On Tue, 23 Oct 2018, Balay, Satish wrote:
>
>> You can check 'ifort -v test.F' - to see how its using gcc internally.
>>
>> configure.log will have the details on where the path is coming from. [you can send us this log]
>>
>> PETSc configure attempts to determine the compiler libraries - and this part could show
>> up with some paths that are not needed.
>>
>> Workaround is to manually specify these paths to petsc configure - so that it doesn't
>> try to determine from 'ifort -v' - and pick up unneed stuff.
>>
>> ./configure LIBS=/path_to/libifcore.a
>>
>> [but then ifort changes this from libifcore.a to libifcoremt.a - if openmp is enabled]
>>
>> Satish
>>
>>
>> On Tue, 23 Oct 2018, Hector E Barrios Molano wrote:
>>
>>> Thank you Satish for your response,
>>>
>>> Yes I am intended to use ifort with gcc.
>>>
>>> I changed ifort versions to one that does not include tbb.
>>>
>>> However, PETSc is still including -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 in
>>> petscvariables, attached you will find an updated petscvariables file.
>>>
>>> ifort is not including any gcc, neither there is reference to this directory
>>> in $PATH or $LD_LIBRARY_PATH, why is PETSc still including it?
>>>
>>> Thanks for your help,
>>>
>>> Hector
>>>
>>>
>>> On 10/18/18 5:28 PM, Balay, Satish wrote:
>>>>> -L/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1
>>>>> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
>>>> Its likely the gcc-4.1 stuff is coming from ifort.
>>>>
>>>> Did you intend to use ifort with gcc? [instead of gfortran?]
>>>>
>>>> Satish
>>>>
>>>> On Thu, 18 Oct 2018, Hector E Barrios Molano wrote:
>>>>
>>>>> Hi PETSc Experts!
>>>>>
>>>>> I am building PETSc from the git repository and it is strange that once
>>>>> PETSc
>>>>> is installed the petscvariables (PETSC_WITH_EXTERNAL_LIB) file shows a
>>>>> different gcc library path that the one from the compiler used and the one
>>>>> defined in LD_LIBRARY_PATH. This is causing me troubles when using PETSc
>>>>> with
>>>>> other library that requires libstdc++
>>>>>
>>>>> Here is the command used to build PETSc:
>>>>> ./configure --prefix=$DEV_lib_dir/petsc_git-debug
>>>>> --PETSC_DIR=/home/hector/dwnld_prog/petsc --PETSC_ARCH=linux-intel-debug
>>>>> --CC=mpicc --FC=mpifort --CXX=mpicxx --with-openmp=1 --with-valgrind=1
>>>>> --with-valgri
>>>>> nd-dir=/home/hector/installed --with-parmetis-dir=$DEV_lib_dir/parmetis/
>>>>> --with-metis-dir=$DEV_lib_dir/parmetis/
>>>>> --with-zoltan-dir=$DEV_lib_dir/zoltan/
>>>>> --with-hypre-dir=$DEV_lib_dir/hypre --download-ptscotch
>>>>> --with-blas-lapack-lib=\[${MKLR
>>>>> OOT}/lib/intel64/libmkl_intel_lp64.a,${MKLROOT}/lib/intel64/libmkl_core.a,${MKLROOT}/lib/intel64/libmkl_intel_thread.a\]
>>>>> --with-scalapack-include=${MKLROOT}/include
>>>>> --with-scalapack-lib=\[${MKLROOT}/lib/intel64/libmkl_scalapack_lp64.a,${MK
>>>>> LROOT}/lib/intel64/libmkl_blacs_intelmpi_lp64.a\] --with-shared-libraries=0
>>>>> --FC_LINKER_FLAGS="-qopenmp -qopenmp-link static" --FFLAGS="-qopenmp
>>>>> -qopenmp-link static" --LIBS="-Wl,--start-group
>>>>> ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${M
>>>>> KLROOT}/lib/intel64/libmkl_core.a
>>>>> ${MKLROOT}/lib/intel64/libmkl_intel_thread.a
>>>>> -Wl,--end-group -liomp5 -ldl -lpthread -lm"
>>>>>
>>>>> Here is LD_LIBRARY_PATH:
>>>>> echo $LD_LIBRARY_PATH
>>>>> /home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/libraries_intel/openmpi/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mpi/mic/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/ipp/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/compiler/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/tbb/lib/intel64/gcc4.1:/share/apps/intel3/debugger_2016/libipt/intel64/lib:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/lib/intel64_lin:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../tbb
>>>>> /li
>>>>> b/intel64_lin/gcc4.4:/share/apps/intel3/compilers_and_libraries_2016.2.181/linux/daal/../compiler/lib/intel64_lin:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/home/hector/installed/gcc-6.1/lib64:/home/hector/installed/gcc-5.1/lib64://home/hector/installed/lib:/opt/gridengine/lib/lx26-amd64:/opt/openmpi/lib
>>>>>
>>>>>
>>>>> Attached you will find the resulting petscvariables file. There in the
>>>>> definition of PETSC_WITH_EXTERNAL_LIB it is not included the gcc-6.1
>>>>> directory
>>>>> and instead gcc4.1 directory is included.
>>>>>
>>>>>
>>>>> What could be the problem? Thank you for your help.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Hector
>>>>>
>>>>>
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20181023/d3836c1c/attachment.html>