On Wed, 16 Apr 2014, Jed Brown wrote: > Satish Balay <[email protected]> writes: > > > On Wed, 16 Apr 2014, Jed Brown wrote: > > > >> "Borazjani, Iman" <[email protected]> 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. > >> >
