Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

undefined symbol: __svml_logf4 linker bug?

fullung
Beginner
1,754 Views
Hello all,

I'm in the process of using a C++ MEX file for MATLAB that is being compiled with Intel C++ Compiler 10.1.018 and linked against Intel MKL 10.0.4.023.

I have been developing my code on a Linux 64-bit server running Fedora Core 9.

I am now trying to redeploy the code on a Linux 64-bit server running openSUSE 10.3.

My code on the two machines is identical (copied using rsync). My versions of MATLAB are identical (R2008a). My versions of the Intel C++ compiler and Intel MKL are identical.

On the Fedora machine the Intel products are installed to /opt. On the openSUSE machine they are installed in my home directory. Except for these path differences, the mexopts.sh files used by MATLAB to call the compiler is identical.

The commands MATLAB executes when compiling the MEX file are:

/opt/intel/cce/10.1.018/bin/icpc -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -I/opt/intel/mkl/10.0.4.023/include -fast -DNDEBUG -openmp "myfunc.cpp"

/opt/intel/cce/10.1.018/bin/icc -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -fast -DNDEBUG -openmp "/opt/matlab/extern/src/mexversion.c"

/opt/intel/cce/10.1.018/bin/icpc -fast -pthread -shared -Wl,--version-script,/opt/matlab/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -L/opt/intel/mkl/10.0.4.023/lib/em64t -lmkl_intel_ilp64 -lmkl_sequential -lmkl_core -liomp5 -lpthread -lm -o "myfunc.mexa64" myfunc.o mexversion.o -Wl,-rpath-link,/opt/matlab/bin/glnxa64 -Wl,-rpath,/opt/intel/cce/10.1.018/lib -Wl,-rpath=/opt/intel/mkl/10.0.4.023/lib/em64t -L/opt/matlab/bin/glnxa64 -lmx -lmex -lmat -lm

On the Fedora machine, the my test script runs without problems. On the openSUSE machine, it fails:

/path/to/myfunc.mexa64: undefined symbol: __svml_logf4

The only difference between the machines that I can think of that could cause this is the linker. On Fedora:

GNU ld version 2.18.50.0.6-5.fc9 20080403


On openSUSE:

GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)

The missing symbol seems to be located in libsvml.so, which comes with the compiler. Using ldd on the MEX file, I can confirm that it finds this library on both machines.

Any idea what could be going wrong here?

Cheers,

Albert
0 Kudos
8 Replies
TimP
Honored Contributor III
1,754 Views
If you haven't moved the icc libraries since you installed the compiler, the iccvars script should set up the paths correctly. If you are depending on specifying all the paths in your command line, instead of using the environment variable setting scripts, you will have to make certain that they agree with the location where you installed the libraries; if you used a different location on one computer than the other, that would make the difference.
0 Kudos
fullung
Beginner
1,754 Views
Hello,

Thanks for the feedback. I recompiled the library on each machine, while specifying the paths on the command line, so I'm pretty sure the paths are correct even on the machine where it fails to find the symbol.

A check with ldd confirms that the dynamic linker can find the libraries on both machines.

Cheers,

Albert
0 Kudos
fullung
Beginner
1,754 Views
I did another quick check: I compiled the library on the Fedora machine, with the Intel tools in /opt, then copied it to the openSUSE machine. Then I sourced iccvars.sh and mklvarsem64t.sh there to prepare the environment for the Intel tools installed in my home directory.

After doing this, ldd again finds the Intel libraries for the MEX file, but I still get the same undefined symbol error. So something else is going wrong...

FC9 has glibc-2.8, while openSUSE has glibc-2.6.1. Could this make a difference to the runtime behavior?

Regards,

Albert
0 Kudos
TimP
Honored Contributor III
1,754 Views
glibc 2.8 hasn't been tested thoroughly with your version of the compiler, but that doesn't account for failing to link an Intel library with the other installation. I thought you were complaining about a link error; now you say there is a run time problem.
You could not have recompiled the libraries in question, as the source code isn't available, so it seems you are giving misleading information.
You could see the contents of the link scripts by adding -# to the options, and check whether libsvml is searched at the same stage of each link. I got the impression you were running the x86-64 OS and 64-bit compiler in both cases; if you use the 32-bit compiler, you will need an SSE option such as -xW to get -lsvml added implicitly to the link script.
0 Kudos
fullung
Beginner
1,754 Views
Hello,

1. The MEX file works on the Fedora Core 9 system with glibc 2.8 without problems.

2. When I said "my test script runs without problems" I meant my MATLAB script. Sorry for not being more clear. So, on the openSUSE 10.3 machine, with glibc 2.6, it is failing at *runtime* with the undefined symbol error.

3. I don't quite understand your comment about non-default paths. In the commands I showed, all the Intel tools were installed to their default location (/opt/intel/*).

4. I recompiled the MATLAB MEX file, myfunc.cpp, on both machines, using the proper paths to the Intel tools on each machine. I'm not sure what misleading information I am giving.

5. Thanks. I'll look at the -# option.

6. I am running a x86-64 OS and 64-bit compiler in both cases.

I'll report back if I find out anything more.

Regards,

Albert
0 Kudos
TimP
Honored Contributor III
1,754 Views
Sorry about my confusion about default paths. If the linker finds the library at link time, but dynamic link fails at run time, the question is whether you have set LD_LIBRARY_PATH correctly at run time, as the iccvars scripts are set up to do.
0 Kudos
fullung
Beginner
1,754 Views
Hello,

Setting or not setting LD_LIBRARY_PATH using iccvars.sh has no effect on the error.

Regards,

Albert
0 Kudos
John_O_Intel
Employee
1,754 Views


Hello,

Setting or not setting LD_LIBRARY_PATH using iccvars.sh has no effect on the error.

Regards,

Albert


Hi,

Sorry you're having problems with this. You can search for symbols in Intel libs with this command, it shows the symbol is in libsvml.

[jjoneill@dpd22 tmp]$ for i in `ls /opt/spdtools/compiler/ia32/cc-10.1.018/lib/lib*`; do nm $i | grep __svml_logf4 > /dev/null && echo Found symbol in $i; done
nm: /opt/spdtools/compiler/ia32/cc-10.1.018/lib/libcxaguard.so: File format not recognized
nm: /opt/spdtools/compiler/ia32/cc-10.1.018/lib/libintlc.so: File format not recognized
Found symbol in /opt/spdtools/compiler/ia32/cc-10.1.018/lib/libsvml.a
Found symbol in /opt/spdtools/compiler/ia32/cc-10.1.018/lib/libsvml.so

I would run ldd command to show what shared libs your shared lib myfunc.mexa64 is linked to, and where these libs are found. I'd guess on your Fedora machine libsvml.so is found, but on OpenSuSE it's not. Hopefully you can figure out why not. Another option is using -static-intel option, this statically links in all Intel provided libs & should avoid this problem.

Additional commands can be useful to understand what icc is doing ...

You can see what commands icpc is passing to the linker by using the -dryrun option (this doens't run the compiler, only dumps the commands it would issue), and you can check if svml is being passed to the linker.

[jjoneill@dpd22 tmp]$ icpc test.cpp -dryrun >& icpc-link.txt
[jjoneill@dpd22 tmp]$ grep svml icpc-link.txt
-lsvml
You can create a memory map file to show what libs the linker is using, what symbols are pulled from what static libs, etc. It can be useful for debugging linking problems:

[jjoneill@dpd22 tmp]$ icpc test.cpp -Wl,-M > link-map.txt

Hope this helps,
John O
0 Kudos
Reply