Correctly link OpenMP with GCC on old Ubuntus #156
Conversation
For more information, see the comment inside the changes (site_cons/SGppConfigure.py).
valentjn
left a comment
There was a problem hiding this comment.
Thanks, that would be really cool if this solved the problems with the tests.
|
@leiterrl What would be the impact now for the Debian packaging? Because it seems adding libomp-dev as default depends should be avoided... |
Thanks @valentjn for the suggestion
|
Maybe to resolve a bit of confusion, sorry, I forgot to mention that in the initial description: libomp is LLVM's OpenMP implementation. |
Isn't libomp-dev already added as a default dependency in the new debian package build script? We link against openmp no matter what so I guess we do need it anyways. |
The py script only enforces the libsgpp dependency for the python module, everything else can (and should!) be controlled from the .sh script. Of course default things, i.e. libz or numpy, should always stay, but you can always change libomp-dev to libgomp1 there if that fixes things. The current version of the .sh script dependency list is meant to exemplify, not be enforced as is for all cases. |
|
Note that a user might have libomp-dev installed anyway, so just removing this from the list of dependencies does not fix the problem. However, it is true that libomp-dev is not a dependency at all if you either deliver precompiled binaries or compile with gcc. If you compile with clang, then libomp-dev is a dependency. |
Well, we deliver the binaries, but for them to work we need to also make sure the target system has the right setup. I think that if we compile the right way and install libgomp1 on the target machine (whether they have already libomp-dev or not) we should be fine. Either way, worst case scenario we add not just the Depends field for our Debian packaging, but also things like Breaks, Replaces or Conflicts if we want to reconfigure the target system in a way that avoids the misuse of the binaries or wrong linkages... @leiterrl Do we plan to deliver binaries also for clang, or just gcc? |
|
I'd say the way to go is to just deliver gcc binaries and use libgomp1 as a dependency. |
|
At least for now Jenkins is happy again. Hopefully, this fixed the tests for good. |
This is a fix mainly for the Ubuntu versions on neon and helium. I will take the liberty and just use my source code comment as PR description :)
Mitigation for old Ubuntu (should probably be also applied to Debian?):
Package 'libomp-dev' installs a symlink 'libgomp.so' to 'libomp.so' in /usr/lib/x86_64-linux. If this path is manually added (-L...), then ld uses this symlink and, thus, links against
the wrong openmp library. The mitigation is to ask gcc for its LIBRARY_PATH in combination with -fopenmp and manually add this as the very first LIBPATH.
Note, that this code also disables openmp if the mitigation command did not produce an
adequate path.
You can verify that the fix works as follows:
Not fixed:
$ ldd lib/sgpp/libsgppbase.so [...] libomp.so.5 => /usr/lib/x86_64-linux-gnu/libomp.so.5 [...]Fixed:
$ ldd lib/sgpp/libsgppbase.so [...] libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 [...]//Edit: @leiterrl ping
//Edit2: Should resolve #152