Here is how icc is linking a C main program:

ld    --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.2 -m elf_i386 -o 
/tmp/petsc-3SW45q/config.compilers/conftest 
-L/apps/compilers/intel/Compiler/11.1/056/lib/ia32 
-L/usr/lib/gcc/i386-redhat-linux/4.1.2/ 
-L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../ -L/lib/ -L/usr/lib 
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crt1.o 
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crti.o 
/usr/lib/gcc/i386-redhat-linux/4.1.2/crtbegin.o 
/tmp/petsc-3SW45q/config.compilers/conftest.o -ldl -Bstatic -limf -lsvml 
-Bdynamic -lm -Bstatic -lipgo -ldecimal -Bdynamic -lgcc_s -lgcc -Bstatic -lirc 
-Bdynamic -lc -lgcc_s -lgcc -Bstatic -lirc_s -Bdynamic -ldl -lc 
/usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o 
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crtn.o

   Since PETSc uses C if you use Fortran it needs to link against this same 
stuff with the intel Fortran linker. We try to rationalize the above list and 
get 

Libraries needed to link C code with another linker: ['-ldl', 
'-L/apps/compilers/intel/Compiler/11.1/056/lib/ia32', 
'-L/usr/lib/gcc/i386-redhat-linux/4.1.2', '-limf', '-lsvml', '-lipgo', 
'-ldecimal', '-lgcc_s', '-lirc', '-lirc_s', 
'-L/apps/compilers/intel/Compiler/11.1/056/lib/ia32', 
'-L/usr/lib/gcc/i386-redhat-linux/4.1.2’]

So when it uses ifort to link something it uses

/apps/compilers/intel/Compiler/11.1/056/bin/ia32/ifort  -o 
/tmp/petsc-3SW45q/config.setCompilers/conftest    -O3 
/tmp/petsc-3SW45q/config.setCompilers/conftest.o -ldl 
-L/apps/compilers/intel/Compiler/11.1/056/lib/ia32 
-L/usr/lib/gcc/i386-redhat-linux/4.1.2 -limf -lsvml -lipgo -ldecimal -lgcc_s 
-lirc -lirc_s -L/apps/compilers/intel/Compiler/11.1/056/lib/ia32 
-L/usr/lib/gcc/i386-redhat-linux/4.1.2 -ldl 

which when running the code results in 

ERROR while running executable: Could not execute 
"/tmp/petsc-3SW45q/config.setCompilers/conftest":
/tmp/petsc-3SW45q/config.setCompilers/conftest: error while loading shared 
libraries: libirc.so: wrong ELF class: ELFCLASS64

Because the -Bstatic are stripped from the link line the wrong libirc.so gets 
picked up by the linker resulting in the runtime error.

I’ve seen these perverse icc link lines mess things up before but don’t 
remember a solution. Satish must remember!

Is there a reason to use the 32bit version?  Have you tried using the 64 bit 
compilers ? Generally I don’t think there is a reason to use 32bit now a days.

Barry






On Jan 8, 2014, at 3:21 PM, Qin Lu <[email protected]> wrote:

> Hello,
>  
> I am trying to build a Linux 32-bit PETSc lib. I first built python-2.7.5 in 
> a 32-bit Linux workstation without problem, then used this python to 
> configure PETSc-3.4.2 with Intel C/C++/Fortran compilers, it got the 
> following error:
>  
> ===============================================================================
>                                                                               
>   TESTING: checkCLibraries from 
> config.compilers(config/BuildSystem/config/compilers.py:161)                  
>                                                    
> *******************************************************************************
>                     UNABLE to EXECUTE BINARIES for ./configure
> -------------------------------------------------------------------------------
> Cannot run executables created with FC. If this machine uses a batch system
> to submit jobs you will need to configure using ./configure with the 
> additional option  --with-batch.
>  Otherwise there is problem with the compilers. Can you compile and run code 
> with your C/C++ (and maybe Fortran) compilers?
> See http://www.mcs.anl.gov/petsc/documentation/faq.html#libimf
> *******************************************************************************
>  
> It seems that a test program built with the given Intel ifort does not run. 
> But I have built another program using ifort in the same workstation and it 
> runs fine.
>  
> Please see the attached configure.log file for details.
>  
> Thanks for your suggestions!
>  
> Regards,
> Qin
>  
>  
> <configure.log>

Reply via email to