Issue866

Title MKL Warning during linking
Priority feature Status resolved
Superseder Nosy List augusto, florian, jendrik, malte
Assigned To Keywords
Optional summary

Created on 2018-11-06.18:13:29 by augusto, last changed by jendrik.

Messages
msg8158 (view) Author: jendrik Date: 2018-12-05.20:11:46
This issue was solved by the changes in issue870.
msg8115 (view) Author: florian Date: 2018-11-28.12:22:00
The case that there are no full builds looks like a bug in the buildbot setup to
me. Someone should probably review the setup I did there. I created issue871 for
that.
msg8100 (view) Author: malte Date: 2018-11-27.01:09:46
All builders now look green, but I think this is misleading. The builds of
November 10 were orange, and I think the recent ones are only green because the
last commits didn't change any code and hence cmake didn't actually rerun the
linker. (They do incremental builds, so if nothing needs rebuilding, nothing is
rebuilt.) Once we commit something with a code change, I assume we'll see these
linker warnings again.

That makes me wonder; how do the buildbots know when a full rebuild is
necessary, e.g. due to changes in the cmake files? I remember we used to do full
rebuilds in the past, but currently we clearly don't. I see lots of build times
of ~10 seconds, and some even ~1 second.
msg8091 (view) Author: jendrik Date: 2018-11-26.14:21:50
Let's discuss the last point in issue870.
msg8088 (view) Author: malte Date: 2018-11-26.12:50:01
According to our current buildbot status, this seems to happen not just with gcc
5.4 but with all Linux 64-bit compilers.

The comment about this getting fixed with the next version is already a bit old
(2016), so I'm not sure if we should hold our breath for it. So I think it would
be good if we could get rid of the warning on our end. As far as I understand,
there is no good way for us to address the root cause of this, and it does
affect what will become our standard build (Linux, 64-bit).

Some options:

- Try to silence the warning or filter it out.

- Detect the warning and add some output that explains why it can be ignored,
pointing to this issue.

- See if we can avoid the warning by using different linker options.

Regarding the last point, I wonder if we should give up on the idea of forcing a
static build and should instead go with the system default everywhere. Many of
the build issues and complications we have when using CPLEX, OSI etc. seem to be
related to the fact that we want to do a custom thing. If it helps avoid
warnings, simplify the setup instructions and CMake file and would allow us to
use more vanilla configurations of the libraries we use, I wouldn't mind some
mild performance loss. (We should measure first.)

Anyone willing to look into this?
msg8068 (view) Author: augusto Date: 2018-11-06.18:13:29
The compilation of Fast Downward with GCC 5.4 and using CPLEX 12.8 generates a
warning during the linking phase. (I could not test on the grid because I have
CPLEX 12.71 there)
The warning is the following (and apparently it comes from Math Kernel Library,
MKL, of CPLEX):

mkl_memory.c:(.text+0x5a9): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc version
used for linking

(for a detailed output, please check the linux64-build-worker-gcc5-lp worker in
the buildbot)


There is a thread in the IBM forums about this specific warning
(https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/560666). The
suggestion given in this thread was to ignore the warning if the executable
works fine and it is also mentioned that they will remove it in future releases
of the Math Kernel Library.

We believe that it should be fine to ignore this warning in our case as well.
However, we do not know yet what is the correct (and safest) way to ignore it,
since this problem does not have a number and it is not 100% clear who is
triggering it.

One caveat: This is not the first warning generated during the linking phase: we
also ready this warning about the use of 'mktemp' vs 'mkstemp', but since it
only occurred on the grid, we never added an exception to the Fast Downward
source code to ignore it.
History
Date User Action Args
2018-12-05 20:11:46jendriksetstatus: chatting -> resolved
messages: + msg8158
summary: Might get solved by issue870, so let's wait for the outcome there. ->
2018-11-28 12:22:00floriansetmessages: + msg8115
2018-11-27 01:09:46maltesetmessages: + msg8100
2018-11-26 14:21:50jendriksetmessages: + msg8091
summary: Might get solved by issue870, so let's wait for the outcome there.
2018-11-26 12:50:01maltesetmessages: + msg8088
2018-11-06 18:13:29augustocreate