no libcilkrts.a (that is no static version of cilkrts)

no libcilkrts.a (that is no static version of cilkrts)

The intel compiler doesn't appear to include a static version of cilkrts. It includes libcilkrts.so, but no libcilkrts.aWe (at Tokutek) use Cilk in our product, but we want to statically link everything. (Dynamic linking creates opportunities for something to go wrong...)Can we get a static version of libcilkrts?-Bradley

8 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

There is a knowledge base article on this (at http://software.intel.com/en-us/articles/intel-cilk-plus-runtime-library-libcilkrts-can-only-be-linked-dynamically/), but it just says what you already know. This is a design decision, as we've run into many problems historically with having multiple static instances of threading runtimes that create problems that are extremely difficult to debug. I want to make sure I track your feedback here though, so I'll create a feature request for this.

Brandon Hewitt
Technical Consulting Engineer

For 1:1 technical support: http://premier.intel.com

Software Product Support info: http://www.intel.com/software/support

Just a reminder. We really want a statically linked library. I don't know what it means to have multiple static instances, but I think for software we are shipping, we can expect to link it properly.

Hi Bradley,

This article- http://threadingbuildingblocks.org/wiki/index.php?title=Using_TBB#Is_there_a_version_of_TBB_that_provides_statically_linked_libraries.3F -although it refers to Intel Threading Building Blocks, explains the reasons for why we don't offer a Cilk Plus static runtime and the problems associated with multiple static instances of threading runtimes. I thought I had linked this as part of the knowledge base article I linked to earlier, but it looks like I need to update the article.

Brandon Hewitt
Technical Consulting Engineer

For 1:1 technical support: http://premier.intel.com

Software Product Support info: http://www.intel.com/software/support

That section of that article seems bogus. Either that or it's not telling the whole story. Why would I end up with multiply linked static schedulers? As an ISV, we can be expected to link our software properly (e.g., not linking it in twice).
We need a static library: I don't want to be debugging my customers' placement of dynamic libraries. You are creating a situation where Cilk is likely not to work for some fraction of my customers. How am I supposed to explain that to my CEO?
-Bradley

Just to update the thread here, our policy continues to be that only the dynamic runtime will be distributed with the Intel C++ Composer XE and Parallel Composer 2011 products. We are continuing to explore other options going forward.

Brandon Hewitt
Technical Consulting Engineer

For 1:1 technical support: http://premier.intel.com

Software Product Support info: http://www.intel.com/software/support

Hi,

I have similar problem - missing static library libcilkrts.a for static buildup of our software, http://www.cmake.org/pipermail/cmake/2012-November/052833.html . In this case the CMake system is automatically assigning "-lcilkrts", a no static libcilkrts.a is present....

The link to the TBB article does not appear to work for me. But I suspect that the some of the relevant text is repeated in our Cilk FAQ.
http://www.cilkplus.org/faq/15

The fundamental concern is one of composability. Even though an ISV may correctly link in a single static copy of the Cilk runtime library, if the customer's code was also directly using Cilk keywords, that code would bring in a second copy of the Cilk runtime. A static library would work as intended only if you are able to guarantee that no one else in the system will use Cilk anywhere. While this fact might be true today, in general, it might not be true tomorrow, if a customer decideds to parallelize some other part of their codebase. In that case, the introduction of parallelism somewhere else in the code introduces multiple statically linked versions of the runtime library, and becomes a subtle performance bug that can lurk in the system. The even worse situation would be if a customer brings in another component which, unknown to them, has also been parallelized with Cilk. Requring a dynamically linked library can make a system setup more complicated. But it arguably has an advantage that bugs can be more obvious to detect and diagnose.

Of course, each use case is slightly different. These issues may or may not apply, especially if you can reasonably expect to control the entire system.

Cheers,

Jim

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!