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

[BradleyKuszmaul]

The intel compiler doesn't appear to include a static version of cilkrts. It includes libcilkrts.so, but no libcilkrts.a

We (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

[Brandon_H_Intel]

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.

[BradleyKuszmaul]

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.

[Brandon_H_Intel]

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.

[BradleyKuszmaul]

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

[Brandon_H_Intel]

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.

[miro_ilias]

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....

[Jim_S_Intel]

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

[GAl-G]

Hi, I am making an executable. Nobody can link to this executable. It will run on well-defined input and produce well-defined output. It is academic software and I want to distribute a static version with no dependencies (like most other software in bioinformatics, see bowtie, usearch, etc). Are you saying this is impossible with Cilk because "other people might use multi-threaded software?"

I'm sorry,  but I need help understanding how this is different from any poor use cases today. If a user runs a copy of bowtie2 with the default threads (all threads on the system, static pthreads), and pipes output as it's produced to a multithreaded SNP calling library (openMP) and simultaneously decides to run BWA to fact-check the DNA alignments, he will experience performance degradation and no tool in the world (short of the operating system's smart scheduling) can fix user idiocy. I know people like this and I've seen performance suffer. If I tell them to run each of the pieces with total cores / 3, lo and behold, things speed up nearly 30%. 

Please reconsider. The user should manage the number of threads each component is allowed. This is "terminal 101" when new informatics people are introduced to running HPC software. 

4/5 times (out of 5 attempts), people have failed to install libraries correctly and/or the system admin failed to get them installed correctly or on time. Users want a binary, not a bunch of files they have to tow along together or add to PATH etc -- and they can't deal with it. What happened to simplicity? I just want to make an executable, not be mired in dependency hell.