Linker error using icc Version 11.1 Build 20091130 Package ID: l_cproc_p_11.1.064

[saurabh636]

I am getting the following error while using icc to build metis/laspack and other LA softwares.

--- Building LASPACK -------------------------
make[2]: Entering directory `/home/libmesh/contrib/laspack'
<<< laspack is disabled, not building >>>
make[2]: Leaving directory `/home/libmesh/contrib/laspack'

--- Building Metis ---------------------------
make[2]: Entering directory `/home/contrib/metis/Lib'
Linking /home/libmesh/contrib/lib/x86_64-unknown-linux-gnu_opt/libmetis.so
icc: command line warning #10156: ignoring option '-s'; no argument required
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[2]: *** [/home/libmesh/contrib/lib/x86_64-unknown-linux-gnu_opt/libmetis.so] Error 1
make[2]: Leaving directory `/home/libmesh/contrib/metis/Lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/libmesh/contrib'
make: *** [/home/lib/x86_64-unknown-linux-gnu_opt/libmesh.so] Error 2

It seems the *.C files are compiled fine but linking with the host code (also compiled with same set of compilers) does not work ... I have previously compiled successfully using version 8.x icc.

Any suggestions?

Thanks
-ss

[mecej4]

You did not state which version of Laspack you are trying to build. Secondly, it appears that the build of Laspack was disabled, so the real question is about building libmetis.so rather than about building Laspack. In that case the version of Metis needs to be stated.

It is typical of the build process of such packages that some customization of the makefile is needed for a more recent OS or when the default compiler (GCC ? ) is not being used.

On Linux x64, you need to compile with -fPIC and link with the -shared option to build a shared library.

The fraction of users at this forum who have built a specfic package with ICC is often quite small. You are more likely to receive help if you ask in terms of the compiler messages. The error message from ICC regarding the -s option suggests that all is not well with the makefile. It would be useful if you display the entire makefile (if that is not too long) or display the relevant lines of the makefile.

I suggest that you complete a successful build with GCC before attempting to do the same with ICC.

[saurabh636]

Yes, the build for laspack was diabled in this case but it broke down with the same error as before, and I do use -fPIC and shared flags to build position independent shared libraries. And as you can see the error does not occur during compilation it does so during linking process. The make files seem to be all correct, but it seems from the error message perhaps that the compiled icc code is linking to gcc libs and not to corresponding icc? I cant seem to find this path in any of the makefiles. Not sure if icc objects should link to gcc libs for smooth functioning?

thanks
-ss

[TimP]

Generally speaking, icc should be compatible with gcc built libraries, at least when the active versions of gc and glibc are compatible with those with which the libraries were built, and neither icc -ipo nor gcc -flto options were invoked.

[mecej4]

I use Metis myself, and I just tried building a x64 shared library on Linux x64 using the Metis 4.0 sources. The build, for which I used -O3 -fPIC -I. for the compiles, and icc -shared -o ../libmetis.so *.o for building the shared library, went fine.

The Intel C compiler does rely upon system (GCC) libraries, CRT objects and headers on Linux. Similarly, ICC on Windows uses MS SDK or VC libraries, headers and tools. These things are needed even for building a 'Hello World' program.

I remember having to scrounge around for the sources for drand48 and its siblings, when building a Metis DLL on Windows some time ago.

You can use the -v flag with the Intel compiler to obtain more details of the linking.