We now have the reverse problem with the Intel 15.0.1 compiler on RHEL6 x86_64: building a shared...

[tjahns]

We now have the reverse problem with the Intel 15.0.1 compiler on RHEL6 x86_64: building a shared object with -shared but without -static-intel still results in the inclusion of libifcore_pic.a in the corresponding shared object. This is a problem because when later an OpenMP-enabled Fortran program wants to use the library, the incompatible run-times cause the binary to segfault at launch.

Is this already known? Should I prepare a test case?

[tjahns]

Okay, I have prepared a test case now that works with Intel 14.0.x compilers but generates programs that often crash because the wrong runtime gets used. The attached program uses internal WRITE in a library function that gets linked into a shared object, which then contains a copy of the non-thread-safe run-time function for_write_int_fmt and also in an OpenMP parallel program that is linked to the mt-runtime but interpositioned by the runtime included in the library.

[Georg_Z_Intel]

Hello Thomas,

I've moved this to a new thread because it's not related to the other one. We're already discussing it and it seems "write" is not thread safe.

Even though OpenMP regards a "write" within a parallel region as unspecified (section 2.5 of the OpenMP 4.0 spec), this should only affect I/O. However, if character arrays are created with it (formatting), it should work w/o problems. So, it seems like a bug.

We've an internal ticket (DPD200567186) for this already. Once there is some further outcome I'll update the thread at hand.

Best regards,

Georg Zitzlsberger

[tjahns]

That's the expected outcome, the non-thread-safe function write was explicitely chosen as an example of the wrong run-time library being linked.

[Georg_Z_Intel]

Hello Thomas,

We have a thread-safe implementation of the system functions. It can be enabled when compiling & linking with the option -threads.

Alternatively you can link the "mt" versions of our libraries (e.g. libifcoremt.a).

Nevertheless, I'll discuss with engineering whether it makes sense to enable the thread-safe versions when compiling with -openmp automatically.

Best regards,

Georg Zitzlsberger

[tjahns]

Georg Zitzlsberger (Intel) wrote:

We have a thread-safe implementation of the system functions. It can be enabled when compiling & linking with the option -threads.

Alternatively you can link the "mt" versions of our libraries (e.g. libifcoremt.a).

Nevertheless, I'll discuss with engineering whether it makes sense to enable the thread-safe versions when compiling with -openmp automatically.

But -openmp already enables the thread-safe run-time automatically. The problem is that any shared object compiled with ifort 15.0.1 or 15.0.2 at this time includes the runtime matching the flags given when compiling the shared object because libifcore_pic.a or libifcoremt_pic.a is statically linked into the .so instead of dynamically linking libifcore.so which would then be overridden by the choice of the binary being linking to the shared object later.

The whole issue is if I can in the future build shared objects with some ifort version, e.g. 15.0.x and later create a program using the library with 15.0.(x+1).
 Such usage was a non-issue with older versions, but no longer works with the 15.0.[12] compilers.

[Georg_Z_Intel]

Hello Thomas,

I see the general issue now. The root cause is that we link libifcore_pic with 15.x and not libifcore (pre-15.x). For the latter an SO is available but for the former we only provide a static version. That static version is causing the problem - it should have been a SO.

I need to find out why we don't provide a libifcore_pic.so and why we made the change at all.

You could use -nodefaultlibs and add the libifcore.so.5 manually to restore the previous behavior. However, I'm not yet sure about the side-effects. Please use this workaround with caution.

Best regards,

Georg Zitzlsberger

[tjahns]

The following thread contains the details of why the feature was introduced: linking self-contained shared objects that can be linked without access to Intel run-time:

https://software.intel.com/en-us/forums/topic/359002

-nodefaultlibs would work if we installed our libraries manually, but to get the corresponding flags through various configure-scripts would be near impossible (considering that libraries generate files that document the intended link line like e.g. nf-config)

[Georg_Z_Intel]

Hello Thomas,

I already knew this has crossed my way but did not remember where and when :-)

Yes that was the motivation for the change. Unfortunately we now need an SO for the PIC version to provide a proper solution. Further updates follow...

Best regards,

Georg Zitzlsberger

[tjahns]

No, I don't think you need another .so: the symbols from libifcore(mt)_pic.a are already in libifcore.so, ifort just needs to link the latter for shared objects.

[Georg_Z_Intel]

Hello Thomas,

In approx. a month from now we'll release Intel(R) Composer XE 2015 Update 5 which should have a fix. Please try this version and let me know about the outcome.

Best regards,

Georg Zitzlsberger