Skip to content
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_POSITION_INDEPENDENT_CODE should be optional #1882

Open
DavidHorton5339 opened this issue Aug 6, 2024 · 2 comments
Open

CMAKE_POSITION_INDEPENDENT_CODE should be optional #1882

DavidHorton5339 opened this issue Aug 6, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@DavidHorton5339
Copy link

In order to use OQS for an embedded target (which does not use dynamic linking, and hence does not provision a Global Offset Table or Procedure Linkage Table), I would like to build it as a static library with CMAKE_POSITION_INDEPENDENT_CODE set OFF. However, the CMakeLists.txt hard codes this to ON, with no capability to override.
It would be useful to allow this setting to be chosen from externally, for example in the CMake toolchain file.
It should be noted that CMake's default choice in the absence of a setting is usually a sensible one (depending on the type of library or executable being built).

@baentsch baentsch added the enhancement New feature or request label Aug 9, 2024
@SWilson4
Copy link
Member

SWilson4 commented Aug 9, 2024

I dug through the git blame to see why we would have hardcoded this, and it led me to PR #670, citing OpenSSL build failures. I believe that PR predated oqs-provider, so presumably it refers to our deprecated OpenSSL fork. Any idea if hardcoding the option is still necessary @baentsch @christianpaquin?

@baentsch
Copy link
Member

baentsch commented Aug 9, 2024

Good "dig" @SWilson4 . Yes, the rationale given by @kevinmkane in 2020 seems sensible when building liboqs embedded into openssl -- and the PR definitely predates oqsprovider... which typically is a shared lib, though... ;-) But seriously, AFAIK oqsprovider can be configured to be built statically as well as shared, so hard-coding -fPIC does not seem a pre-requisite any more these days (and also shouldn't be).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

3 participants