undefined reference to `__kmpc_.... and such

[philippeayala]

Hi all:

I downloaded the trial versions for both ifc and mkl. I'm trying to compile but it looks like there is something missing in my environment or i did not link the right libraries. I can't figure out what's wrong, especially since i'm not looking to turn on openMP. It looks like that:

myutil.so: undefined reference to `__kmpc_for_static_fini'
myutil.so: undefined reference to `omp_in_parallel_'
myutil.so: undefined reference to `__kmpc_end_serialized_parallel'
myutil.so: undefined reference to `omp_get_max_threads_'
myutil.so: undefined reference to `getarg_'
myutil.so: undefined reference to `__kmpc_for_static_init_4'
myutil.so: undefined reference to `kmp_set_stacksize_'
myutil.so: undefined reference to `iargc_'
myutil.so: undefined reference to `__kmpc_serialized_parallel'
myutil.so: undefined reference to `__kmpc_fork_call'
myutil.so: undefined reference to `__kmpc_global_thread_num'
myutil.so: undefined reference to `__kmpc_ok_to_fork'


Any help is greatly appreciated.
Cheers,
Philippe

[Steven_L_Intel1]

What compile and link commands did you use?

Steve

[philippeayala]

I used
ifc -O2 -tpp7 -unroll -axW -ipo -ipo_obj
along with -Vaxlib -lCEPCF90
myutil.so was linked to mkl_p4.a and mkl_lapack.a

Philippe

[Steven_L_Intel1]

I think MKL may want the OpenMP libraries - I'm not up to speed on that yet. Perhaps someone else will comment.

Steve

[TimP]

Yes, MKL would require the openmp support. That should be in the MKL notes. The supported way would be to use ifc -openmp (together with your other options) to link.

[philippeayala]

Thanks to y'all.

Adding -openmp -lpthread did the trick. I finally got my executables. I just need to understand why i get garbage out of them when i use MKL as opposed to plain BLAS....
I hope it's not due to something silly like case-sensitivity for uplo and such;-)

Cheers,
Philippe

[Martyn_C_Intel]

Just a warning - if you specify -openmp on the compile line, the default for array storage changes from static to automatic (local). This can break programs that are expecting array data to be saved from one call to another.

You can avoid this if necessary by linking to the openmp libraries explicitly (libguide followed by libpthread) and omitting -openmp

Martyn

[mike-s]

Quoting - Martyn Corden (Intel)

Just a warning - if you specify -openmp on the compile line, the default for array storage changes from static to automatic (local). This can break programs that are expecting array data to be saved from one call to another.

You can avoid this if necessary by linking to the openmp libraries explicitly (libguide followed by libpthread) and omitting -openmp

Martyn

Wouldn't a -save do the same? This is more out of curiosity than a hint, but from the ifort doc this seems to be the case. Also ifort tells me
ifort: warning #10247: explicit static allocation of locals specified, overriding OpenMP*'s implicit auto allocation

regards,
mike

[TimP]

Quoting - mike-s

Wouldn't a -save do the same? This is more out of curiosity than a hint, but from the ifort doc this seems to be the case. Also ifort tells me
ifort: warning #10247: explicit static allocation of locals specified, overriding OpenMP*'s implicit auto allocation

regards,
mike

The default, without -openmp or -save, is that local scalars aren't saved (unless declared as SAVE), while local arrays should be saved. -openmp removes default save status for local arrays. The over-ride of -openmp with -save would make both arrays and scalars default to -save, which ought to be OK if you don't have any parallel regions in the code you are compiling. It's preferable, of course, to declare SAVE where it is needed, so as to make your source code standard compliant, as -save options can't always be counted on, particularly with interprocedural optimization.

[Mike_Rezny]

Quoting - Martyn Corden (Intel)

Just a warning - if you specify -openmp on the compile line, the default for array storage changes from static to automatic (local). This can break programs that are expecting array data to be saved from one call to another.

You can avoid this if necessary by linking to the openmp libraries explicitly (libguide followed by libpthread) and omitting -openmp

Martyn

Hi,
I had a case recently where someone had built an OpenMP code by linking in the libguide and libthread libraries explicitly instead of using -openmp. This caused a problem in a part of the code that had used OpenMP sections to open and read several input files in parallel. So I suspected, but never found out,if using -openmp also loaded in some thread-safe versions of other standard libraries.

How does one find out what is going on under the covers, at link time, when -openmp is specified?

regards
Mike

[TimP]

You could add -# to your ifort command so as to see details of the linker script. There's a problem if you link an OpenMP library from an old version of MKL which conflicts with the one you need for a newer ifort. The integrated ifort Professional (all 11.x versions) should avoid such problems, as long as you use the MKL which comes with ifort. All standard libraries should be thread-safe, as long as you don't use discontinued Windows environments.