[petsc-dev] [petsc-maint] problem installing petsc 3.4

[Borazjani, Iman]

Thanks a lot! It is installed successfully!

Iman

On 4/16/2014 2:48 PM, Satish Balay wrote:
> On Wed, 16 Apr 2014, Jed Brown wrote:
>
>> Satish Balay <balay at mcs.anl.gov> writes:
>>
>>> On Wed, 16 Apr 2014, Jed Brown wrote:
>>>
>>>> "Borazjani, Iman" <iman at buffalo.edu> writes:
>>>>
>>>>> Hi Jed,
>>>>>
>>>>> I tried both ways and still get a compiler error, but this time I think
>>>>> it is the -g option:
>>>>>     CLINKER
>>>>> /share/apps/petsc-petsc-7cd361a5361c/linux-gnu-debug/lib/libpetsc.so.3.04.4
>>>>> /usr/bin/ld:
>>>>> /share/apps/open64/lib/gcc-lib/x86_64-open64-linux/4.2.4/libopen64rt.a(cacheinfo.o):
>>>>> relocation R_X86_64_32S against `a local symbol' can not be used when
>>>>> making a shared object; recompile with -fPIC
>>>>> /share/apps/open64/lib/gcc-lib/x86_64-open64-linux/4.2.4/libopen64rt.a:
>>>>> could not read symbols: Bad value
>>>> Looks like this compiler claims to be able to link with shared
>>>> libraries, but in fact cannot (since no shared version of libopen64rt.a
>>>> is available).  Configure --with-shared-libraries=0 to get a static
>>>> build of PETSc.
>>> There was a discussion about this on petsc-maint a couple of years ago with a reference to
>>>
>>> http://devgurus.amd.com/thread/159277
>>>
>>> i.e the compiler links to libopen64rt_shared.a when -shared options is specified.
>>>
>>> But we detect the compiler libraries libraries without using '-shared'
>>>
>>>
>>> Workarround discussed at that time:
>>>
>>> --with-shared-libraries=1 --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS='-lfortran -lmv -lffio'
>>>
>>> [but we mignt need --with-cxx-autodetect=0 aswell [with -lstdc++ in LIBS]
>> Would we have more or less failures if we used the Fortran linker and
>> passed -lstdc++ when needed (with no other autodetect)?  I hate
>> second-guessing the compilers.
> Whenever we make such assumptions - there is always a corner case
> where something else fails.
>
> [the current issue is an example of one such assumption.]
>
> Satish
>
>>>> This is something we should be able to detect in our configure tests.
>>>>
>

-- 
Iman Borazjani, Ph.D.
Assistant Professor
Mechanical and Aerospace Engineering Department
SUNY University at Buffalo
Tel. 716-645-1468
Web. http://www.eng.buffalo.edu/~iman/