Offload compilation using -tbb fails with "ld: cannot find -ltbb"

[jiri]

We have just upgraded to Composer XE 2013 SP1 and I can no longer do offload compilation of even a simple program.

I have included the variables script (compilevars.sh intel64) and the values of those variables look OK. However, if I take the following file:

[cpp]

#include <iostream>


int main()
{
        int i;
        #pragma offload target(mic:0)
        {
                i=1;
        }
        std::cout<<i<<std::endl;
}
[/cpp]

and try to compile it using "icc -tbb empty.cpp" then I get "ld: cannot find -ltbb". If I remove the pragma offload and run the same command, it is OK. Without the pragma, even "icc -mmic -tbb -lpthread empty.cpp" works just fine. Everything works when I go back to the previous version of the compiler.

What am I doing wrong? Has anyone seen the same issue?

[Kevin_D_Intel]

Our apologies. You are not doing anything wrong. It appears we may have a problem with the icc driver in the Composer XE 2013 SP1 initial release that you upgraded to.

I reproduced the same error and confirmed it is fixed in our upcoming CXE 2013 SP1 Update 1 that should be available in a few days. I can post again once that release is available. If I can find a convenient work around I will post that also.

[jiri]

Thank you for the quick reply. For me, moving to the older version until the fixed version is released is a workaround that I can live with just fine.

[Kevin_D_Intel]

Turns out this issue was tied to including iostream so there’s no convenient work around.

The issue is resolved in the Composer XE 2013 SP1 Update 1 (l_ccompxe_2013_sp1.1.106 - Linux) that now available from the Intel Registration Center.

(Internal tracking id: DPD200356152)

(Resolution update on 10/25/2013: Resolved as noted above)

[jay_lee]

Hi,

I had the same problem in Windows environment using MPSS 3.1 and Composer SP1 for Windows.

Kevin's answer was very helpful for me.

After the update of the Composer XE SP1 + Update 1, /Qtbb problem was solved! Thanks!

I used very simple code as above... just #include and task_scheduer_init... And the compile was OK!

But another problem! When I execute the offload executable, the error message is as the following:

"The remote process indicated that the following libraries could not be loaded : libtbb.so.2"

I tried to find the reason... I found one hint from compile message...

icl /GR- /Qtbb InitTBB.cpp

-libpath:C:\Program Files(x86)\Intel\Composer XE 2013 SP1\tbb\bin..\lib\intel64\vc8

You can see the "vc8" in the path, but there is no tbb library for "vc8" in TBB 4.2...

It can be a clue?

Please help me!!!

Thanks

[Kevin_D_Intel]

Let me investigate and I will post again after I know more.

[Kevin_D_Intel]

This new error with TBB on Windows involves a related issue with MKL use on Windows where in Composer XE 2013 SP1 Update 1 the environment variable, MIC_LD_LIBRARY_PATH, is not initialized accordingly.

To resolve this issue, use the SET command shown below under the pre-initialized Intel compiler command-prompt window (or MSVS IDE Configuration Properties - refer to the article referenced below for details) to add the TBB libraries (and MKL if used) to the linker search path to enable locating Xeon Phi TBB (and MKL if used) libraries.

set MIC_LD_LIBRARY_PATH=%MIC_LD_LIBRARY_PATH%;%MKLROOT%\lib\mic;%TBBROOT%\lib\mic

Refer to this article for information about Visual Studio Property setting change and specifics of how this issue affects MKL similarly.

(Thank you Ravi for the inside tip!)

[jay_lee]

Thank you so much, Kelvin!

I've resolved this problem! Now I can compile and execute the offload TBB program!!!

I'll announce this good news to my community!

They shall be excited!

Thanks again for your greate help!

[Kevin_D_Intel]

I am really glad to hear that. I wish you and your community well going forward with Xeon Phi™.

I will update this thread again after the official fix for the MKL and TBB issue on Windows is available in a future update release. We tentatively expect to fix this in the next Update 2 currently scheduled for the first quarter 2014.

(Internal tracking id: DPD200383051 - MKL/TBB Windows link error)
(Resolution Update on 09/08/2014): This defect is fixed in the Intel® Composer XE 2013 SP1 Update 2 release (Version 14.0.2.144)

[jay_lee]

Hello,

I have another question for the warning message:

C:\Program Files (x86)\Intel\Composer XE 2013 SP1\tbb\Include\tbb\task_scheduler_init.h(53): warning #3441: a class marked shared may not have a base class whose size is not a multiple of 8

I already enclosed the tbb header file with #pragma push & pop :

#pragma offload_attribute (push,target(mic))

#include <tbb\task_scheduler_init.h>

#pragma offload_attribute (pop)

Please let me know the reason...

I'll also try to find the reason...

Thanks a lot!

[Kevin_D_Intel]

We received the same report yesterday from another customer and our C++ Front-end team is investigating now. I will post another update after learning more and whether there is a convenient work around.

(Internal tracking id: DPD200249490 - warning #3441)   (See updated post below for new tracking id)

[jay_lee]

Thanks for the quick reply!

[jay_lee]

Hello,

I'm testing for the native exucution but get failed continously.

Please let me know the procedure and command line for the Windows host.

I tried:

1. icl /GR- Matrix.cpp

2.  Connected to Xeon phi using Putty.

3. Copy Matrix.o to Xeon Phi using Winscp

4. Copy the library for Cilk plus to same folder.

5. Execute -> ./Matrix.o

Error!!!

Please check my procedure and correct.

Thanks a lot

[Kevin_D_Intel]

You need to set the LD_LIBRARY_PATH environment variable on the card. So after step 4, in the window connected to the card, issue a command like:

$ export LD_LIBRARY_PATH=/tmp

Where you replace /tmp shown above with the name of the folder where you placed your executable and Cilk plus shared lib.

[jay_lee]

Thanks, Kelvin!

Your comment is very helpful~

[Kevin_D_Intel]

Glad to hear that helped.

With regard to the earlier new warning #3441, Developers are still looking into this. This was a specific diagnostic added in Update 1 and at least the one earlier case where it appears erroneous. The earlier case does not use TBB so our Developers are interested in seeing your case.

Is it possible we could obtain a test case from you?

[jay_lee]

Sure of course!

I pasted the code that I tested. It's vey simple code!

InitTBB.cpp

-------------------------------------------------------

#include <stdio.h>

#pragma offload_attribute (push,target(mic))
#include <tbb\task_scheduler_init.h>
#pragma offload_attribute (pop)
using namespace tbb;

__declspec(target(mic))
void _Init() {
    task_scheduler_init init;
}

void Init() {
#pragma offload target(mic)
    _Init();
}

int main(int argc, char* argv[]) {
    printf("TBB Init...\n");
    Init();
    printf("Success!\n");
    return 0;
}

>icl /GR- /Qtbb InitTBB.cpp

It can be compiled with warnings and executed fine! (In Intel 64 Visual Studio 2012 mode)

But too many warnings!

Thanks a lot!

[Kevin_D_Intel]

Thank you for the quick reply and test case. I'll update again soon.

[Dave_O_]

I am having the same probelm! ld error with -ltbb.

I have the new update sp1.1.106 of icc. when I run icc main.c -tbb I get the error. What do I do?

[Kevin_D_Intel]

Please show me your complete reproducer program (or attach it) and the error and also include the compiler sign-on as I have shown below.

What’s shown below is the original example in this forum thread which now compiles with the CXE 2013 SP1 Update 1 compiler.

If you still experience the error with Update 1 then you must have something different/unique that we may not know about yet.

$ cat empty.cpp
#include <iostream>
int main()
{
        int i;
        #pragma offload target(mic:0)
        {
                i=1;
        }
        std::cout<<i<<std::endl;
}

$ icc -V
Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.1.106 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

$ icc empty.cpp -tbb
$

[jiri]

Sorry for the delay, we had to postpone updating the compiler (we also wanted to update MPSS and that had to wait until some experiments were finished). We are now running sp1.1.106 and as far as I can tell the issue has been resolved. Thank you for your help.