topic Re: Version 9 to 10 Update 2 Link Error in Intel® oneAPI Math Kernel Library

Version 9 to 10 Update 2 Link Error

brianlamm — Sat, 08 Mar 2008 23:34:53 GMT

When I was using MKL 9 (last release), inside a driver for pardiso I called "omp_get_max_threads()" to set iparm(3) in pardiso. I delcared omp_get_max_threads as INTEGER and the line after that as EXTERNAL in that driver procedure. I linked against libguide.lib (static, I know, but it Worked) and the other libraries, at MKL 9 they were mkl_solver.lib, mkl_c.lib (when building for 32bit, did not use mkl_c.lib for em64t), mkl_lapack.lib. I had set environment variable OMP_NUM_THREADS equal to env NUMBER_OF_PROCESSORS.

This is Fortran, and I always use IVF latest public release to build (inside MSVS 2005 Pro).

"Everyting" built fine and application results were correct for test harness.

With MKL 10, update 2, things are "different" (talk about growing pains, but I suppose it's for the best for greater compatibility with other than INTEL compilers).

I used the exact libraries as shown in the user manual to statically link pardiso. So I am using the static libraries in MKL, except (because highly recommended by Intel MKL) for libguide40.lib. The MKL libraries I linked against were:
libguide40.lib
mkl_core.lib
mkl_intel_lp64.lib
mkl_intel_thread.lib
mkl_solver_lp64.lib

Now, in DEBUG I get no build errors ( I use debug dlls), but I do get a message libguide.dll (via libguide40.lib) has no debug symbols. In RELEASE I get the following link errors:

Error 159 error LNK2005: OMP_GET_MAX_THREADS already defined in libguide40.lib(libguide40.dll) libguide.lib
Error 160 fatal error LNK1169: one or more multiply defined symbols found x64Release/LoTekDLL.dll

There are two "projects": one for an exe and one (big) one for the dll which does all the work (please don't comment on this bad style, app is under development).

When I run first member of test on debug I get a crash I cannot run down, yet hopefully. And as I just wrote above, release does not successfully build so I cannot test it.

Any ideas on what the problem might be? Thanks.

I am running, and use, the latest release of both IVF and MKL on windows _64 machine, and the builds I referenced above were for Intel 64 target.

Brian

Re: Version 9 to 10 Update 2 Link Error

brianlamm — Mon, 10 Mar 2008 21:21:57 GMT

Must I file a problem report to get any Intel feedback?

Note, everything being identical, except using "mkl_get_max_thdreads( )" the problem went away. I of course also had "mkl_get_max_threads" declared as integer and external, replacing the "omp_get_max_threads" in those two places.

-Brian

Re: Version 9 to 10 Update 2 Link Error

Todd_R_Intel — Mon, 10 Mar 2008 22:17:36 GMT

Filing a problem report at Premier supportis certainly your best option for getting responses and follow-up. As stated here...

A very short note about what the forum is not: This is not a forum for technical support for the library. Rather, please go to the library support site which is staffed and set up to register and respond to support issues you may have.

My first impression would be that somehow you are linking both libguide40.lib and libguide.lib. Unless this was a simple slip up I don't know why that would be. Is use of the mkl_* functions an option?

Todd

Re: Version 9 to 10 Update 2 Link Error

brianlamm — Wed, 12 Mar 2008 02:34:50 GMT

Thanks Todd,

Unless libguide.lib was linked somehow "behind the scene", I don't know either since you can see above I linked against libguide40.lib (and the others listed in original post). And as I wrote in my next post changing omp_get_max_threads( ) to mkl_get_max_threads ( ) ( and declaring mkl_... INTERGER and EXTERNAL in the host referencing it ) with absolutely no other changes "fixed" (read "most likely bypassed") the problem.

When I get some time, perhaps before my billion year road trip ends, I'll take a closer look, but I've only 32-bit laptop at my disposal, but I can still use my IVF to target Intel 64 ... .

If it persists I'll file a problem report.

Hey, I know this forum is not technically for technical support, but you gotta' admit a lot of very bright, involved people supply and post for at least er ... psuedo-tech support. I mean, you MAD guys are no slackers and often circumvent the consumer problem report avenue, but, alas, load balancing applies in all kinds of domains ...

-Brian