-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMake: Set lapacke POSITION_INDEPENDENT_CODE=ON #932
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #932 +/- ##
=======================================
Coverage 0.00% 0.00%
=======================================
Files 1918 1918
Lines 188653 188653
=======================================
Misses 188653 188653
☔ View full report in Codecov by Sentry. |
To best honest I do not know why the build setup should always activate this option for three reasons:
It was added in commit 4c2236a. As stated above CMake can infer when this flag is needed unless one tries to create shared and static libraries at the same time so I wonder why this was done. Here is a minimal CMake example demonstrating the inference capability. Contents of cmake_minimum_required(VERSION 3.2)
project(cmake-automatic-pic-inference)
option(BUILD_SHARED_LIBS "Build shared libraries" OFF)
add_library(foo foo.c) Execution (note the presence of of the
|
indeed, this patch is needed for building static libs, sorry if this wasnt clear
it could be eventually an opt-out setting if you want to modify it after this lands |
(Emphasis mine.) No, it is not (see the first bullet item in my post). You can have CMake pass the necessary flags to compiler already: env CFLAGS='-fPIC' FFLAGS='-fPIC' cmake ../lapack/ |
of course, but the point of the patch is to make that easier |
CMake docs say when this property is used, CheckPIESupported should be used first https://cmake.org/cmake/help/latest/module/CheckPIESupported.html |
that only checks if its actually supported (we know its supported on standard linux/gcc platforms) |
If PIC is desired when compiling static libraries so they can be linked into ELF shared libraries it's probably better to make it an opt-in instead of forcing it to be set on targets as that is rather intrusive. A CMake option like if(LAPACK_PIC_STATIC_LIBS)
set_target_properties(${LAPACKLIB} PROPERTIES POSITION_INDEPENDENT_CODE ON)
set_target_properties(${LAPACKELIB} PROPERTIES POSITION_INDEPENDENT_CODE ON)
endif() This is also preferable to globally setting |
@phetdam are there any actual use-cases to enable POSITION_INDEPENDENT_CODE for some target and not all ? to be clear, this PR only makes LAPACK & LAPACKE consistent with BLAS & CBLAS target for which it is already enabled: if this is not wanted we might just as well remove it the pre-existing ones too and rely on CMAKE_POSITION_INDEPENDENT_CODE or CFLAGS/FFLAGS flags |
@jschueller sorry, I didn't realize that when BLAS/CBLAS are already compiled as PIC for static libraries. Given the fact that BLAS and LAPACK are usually used together, I think it would be unnecessarily granular in terms of build configuration and rather strange in general to require BLAS static libs to be PIC while leaving LAPACK static libs as the default non-PIC. Static libraries are not compiled as PIC by default on UNIX-like systems, so to follow the principle of least astonishment, the requirement for BLAS/CBLAS to be compiled as PIC even when built statically should be removed. It also seems that requiring PIC inhibits some compiler optimizations, but either way I think it's best to not force static libs to be PIC unless requested. I still favor having a project-specific flag, e.g. However, if that's not an issue, then using |
This ensures all static libs are compiled with -fPIC (only BLAS/CBLAS had it enabled)