-
Notifications
You must be signed in to change notification settings - Fork 411
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
Malformed generated liboqs.pc
file
#1787
Comments
Thanks for this bug report. Checking the cmake documentation seems to indicate we should indeed use "CMAKE_INSTALL_FULL_LIBDIR/INCLUDEDIR" instead. Any objections @vt-alt ? |
Well, I don't know anything about Nix. That path looks bizarre:
In ALT we have correct paths in final
(Using -libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
-includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
+libdir=@CMAKE_INSTALL_FULL_LIBDIR@
+includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@ And it produced correct paths either:
So I don't object this improvement. But who knows what it will produce on Nix.
So there are chances it will produce just the same value. There are also chances this is just Nix packaging bug which we should not try to "fix". |
Also, the docs say:
So this should be By this I conclude Nix [packager] maybe misdefining it. |
I checked on Debian 12 in Docker:
In Fedora Rawhide:
All expected correct values. |
So my thought is, while I don't oppose the change, that the values are already perfectly correct, and the change will not change much, and, perhaps, don't fix Nix packaging. |
Thanks for the analysis, @vt-alt . Based on this I tend to agree we leave things as-is.
Indeed, the NIX path appears strange: It seems it causes a full path to be appended to "${prefix}": Can you check (why/whether) this so, @Sigmanificient ? Could you check whether the change suggested by the |
@vt-alt Using the following patch: --- a/src/liboqs.pc.in 2024-05-09 14:54:04.989767336 +0200
+++ b/src/liboqs.pc.in 2024-05-09 14:54:50.361324577 +0200
@@ -1,6 +1,6 @@
prefix=@CMAKE_INSTALL_PREFIX@
-libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
-includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
+libdir=@CMAKE_INSTALL_FULL_LIBDIR@
+includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
Name: @PROJECT_NAME@
Description: Library for quantum-safe cryptographic algorithms The package build successfully and the generated
|
@Sigmanificient Do you redefine Also, can you show your full |
I use the attributes used in the derivation: patches = [
./fix-openssl-detection.patch
# liboqs.pc.in path were modified in this commit
# causing malformed path with double slashes.
./fix-pc-file-variables.patch
];
nativeBuildInputs = [ cmake ninja ];
buildInputs = [ openssl ];
cmakeFlags = [
"-DBUILD_SHARED_LIBS=${if enableStatic then "OFF" else "ON"}"
"-DOQS_DIST_BUILD=ON"
"-DOQS_BUILD_ONLY_LIB=ON"
];
dontFixCmake = true; # fix CMake file will give an error
outputs = [ "out" "dev" ]; Nix logs report the following cmake flags (I've put each on their own line):
Here is the full logs as a gist: https://gist.github.com/Sigmanificient/28ddd430f5a439f3a703b13d12818dc9 |
Thanks.
So CMAKE_INSTALL_LIBDIR with absolute path is added automatically by Nix build system. But this is "not recommended" is the docs. Perhaps, bug report should be filed to Nix authors to fix this? Or at least their opinion should be consulted. But I understand that some packages would be broken by the either choice, so they may be reluctant to change anything. And it looks like cmake is smart enough to strip LIBDIR prefix from Well, in that case, it maybe more portable to patch ps. I am curious how other Nix packages workaround this issue. |
JFYI
Looking at https://github.com/NixOS/nixpkgs I see a lot of setting like this (overriding default values):
Also sometimes they patch the sources to use postPatch = ''
substituteInPlace cmake/libappimage.pc.in \
--replace 'libdir=''${prefix}/@CMAKE_INSTALL_LIBDIR@' 'libdir=@CMAKE_INSTALL_FULL_LIBDIR@' \
--replace 'includedir=''${prefix}/@CMAKE_INSTALL_INCLUDEDIR@' 'includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@'
'';
So it seems that experienced Nix packagers already aware of the problem and workaround it on their own. |
Thanks very much for this thorough analysis of Nix packaging, @vt-alt . I take from this that |
Describe the bug
Hi, while upgrading nixpkgs's liboqs (
0.8.0
->0.10.0
), i ran into an issue concerning the generatedliboqs.pc
file. Nix kindly reported the following malformation:Reverting this commit fixes the problem, generating the proper
pc
file:Environment (please complete the following information):
NixOS 23.11
3.0.13
gcc 13.2.0
"-DOQS_DIST_BUILD=ON"
"-DOQS_BUILD_ONLY_LIB=ON"
0.10.0
The text was updated successfully, but these errors were encountered: