creating new offload libraries

creating new offload libraries


I am working on a part of a project in C. The project includes a large library which is creating of many objective files.

I am changing one of the code using in the library to offload the corresponding work to MIC.

Assume lib1.c (lib1.o is the corresponding objective file in the library) is the code. when I compile again, I don't have the lib1.o but new lib1MIC.o.

How can I make some changes to everything works well?

All the best

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

If you are changing a source file that contains language extensions for offload and recompiling then the compiler should be producing new <file>.o and <file>MIC.o object files.

You should not manipulate the <file>MIC.o file(s) directly. You need to allow the compiler driver and associated tools handle the MIC.o file(s) invisibly through your reference only to the CPU (host-side) .o file(s) on the compiler/associated tools command-line.

Thank you,

yes, I change source file lib1.c. The compiler generates both 2 new files lib1.o and lib1MIC.o.


Assume, for simplicity,

     We have lib1.c, lib2.c and lib3.c. We creat a static library liblarge.a with objective files lib1.o, lib2.o and lib3.o.

     Now we change lib1.c (including #pragma offload ...) and recompile it. This time we have lib1.o, lib1MIC.o. Should we creat liblarge.a as before including lib1.o, lib2.o and lib3.o.? What about lib1MIC.o now? Do we need a new static liblargeMIC.a for MIC too?

     Finally there is another objective file main.o too which is compiled before. How should we compile and link these files now?

All the best

It is best/easiest to ignore that MIC.o objects (and MIC.a files) are created and allow the compiler and associated tools to manipulate those invisibly and you just use the same build methods you are accustomed to using before you added offload code.

Even with offload code present, you simply build and link the static library just as you do when no offload code is present. The creation of the object files, library, and offload executable are all done invisibly. So for what you described, you might do that like this:

icc -c lib1.c lib2.c lib3.c
xiar crv liblarge.a lib1.o lib2.o lib3.o
icc main.c -L. -llarge

Now modify lib1.c and recompile it and replace ONLY it in the static archive:

icc -c lib1.c
xiar crv liblarge.a lib1.o
icc main.c -L. -llarge


Thank you Kevin,

I did what you said.

Now I have the 2 following errors:

  1. /home/lib1.c:337: undefined reference to `__offload_target_acquire1'
  2. /home/lib1.c:337: undefined reference to `__offload_offload1'

In a function in lib1.c, I used a "#pragma omp target map(to:...)" in line 337

When main() does not include any offload language extensions or OpenMP 4.0 target constructs, it will not link in the offload run-time. On the compile/link for main(), add the compiler option: -offload

Thank you Kevin,

I made a smal project like the large one and did some tests.

My main() didn't include any offload language extensions or OpenMP 4.0 target constructs. But it worked without option -offload.

I just added lib1.o to the final command too:

icc main.o lib1.o -L. -llarge

Best regrads

Ok, that would work too if that is what you prefer. Without trying it, it seems like that may lead to linker warnings about symbols already being defined earlier as soon as the linker cracks open liblarge and starts processing it since it would have processed lib1.o ahead of liblarge unless you aren't adding lib1.o to the static archive now with this change. My preference would be to use -offload but definitely use what works best for you.

I am glad to hear you resolved it.

Leave a Comment

Please sign in to add a comment. Not a member? Join today