Message ID | 20220327122956.524901-2-sl@eauchat.org |
---|---|
State | Accepted |
Headers | show |
Series | Fix cross-compilation for libfido2 | expand |
Sébastien Lerique schreef op zo 27-03-2022 om 21:29 [+0900]: > + ,(%current-target-system) > + "-pkg-config")))) This can be simplified with 'pkg-config-for-target': #:configure-flags (list (string-append "-DPKG_CONFIG_EXECUTABLE=" (search-input-file %build-inputs (string-append "/bin/" ,(pkg-config-for-target))))) Greetings, Maxime.
On 27 Mar 2022 at 14:36, Maxime Devos <maximedevos@telenet.be> wrote: > This can be simplified with 'pkg-config-for-target': > Indeed, thanks! Just tried again with a v2. Best, Sébastien
Hi, Maxime Devos <maximedevos@telenet.be> writes: > [[PGP Signed Part:Undecided]] > Sébastien Lerique schreef op zo 27-03-2022 om 21:29 [+0900]: >> + ,(%current-target-system) >> + "-pkg-config")))) > > This can be simplified with 'pkg-config-for-target': > > #:configure-flags > (list (string-append "-DPKG_CONFIG_EXECUTABLE=" > (search-input-file %build-inputs > (string-append "/bin/" ,(pkg-config-for-target))))) For my own benefit trying to get better at writing gexps, I was wondering how to write in order to remove the %build-inputs reference. I came up with the following: --8<---------------cut here---------------start------------->8--- (arguments (list #:configure-flags #~(list #$@(if (%current-target-system) (list #~(string-append "-DPKG_CONFIG_EXECUTABLE=" #+pkg-config "/bin/" #$(pkg-config-for-target))) '())) #:phases #~(modify-phases %standard-phases ;; regress tests enabled only for debug builds (delete 'check)))) --8<---------------cut here---------------end--------------->8--- Would this a the better way to do this? It looks a bit complex to me so I wonder if there's a simpler way. I'm also not entirely sure if it's #+pkg-config or #$pkg-config, both seem to work, however I thought we should be using #+ for native inputs and #$ for regular inputs. Thanks, Pierre
Pierre Langlois schreef op zo 27-03-2022 om 15:04 [+0100]: > I'm also not entirely sure if it's > #+pkg-config or #$pkg-config, both seem to work #+pkg-config, given that it is a thing that needs to be run during compilation. I'm wondering, do you have transparant QEMU emulation enabled? If so, both seeming to work is expected since QEMU will emulate the cross-compiled cross-compiling (IIUC a canadian cross, in GCC terminology) pkg-config. If not, I would expect some kind of error ... Or, to allow for package transformations: #+(file-append (this-package-native-input (pkg-config-for-target)) "/bin/" (pkg-config-for-target)) though maybe package transformations should just transform the G-exp as well, dunno. ('file-append' is not strictly required here.) Maybe we can have a macro (pkg-config-binary) that expands to that thing, and use it in other packages? Possibly interesting or irrelevant: the following will produce an x86_64-linux-gnu-pkg-config that can be run on a aarch64-linux-gnu computer to find libraries for x86_64-linux-gnu. $ guix build -e '(parameterize (((@ (guix utils) %current-target-system) "x86_64-linux-gnu")) (@ (gnu packages pkg-config) pkg-config))' --target=aarch64-linux-gnu Greetings, Maxime.
Pierre Langlois schreef op zo 27-03-2022 om 15:04 [+0100]: > #~(modify-phases %standard-phases > ;; regress tests enabled only for debug builds > (delete 'check)))) FWIW, given that this is old code, '#:tests #false' + comment would suffice here and is a bit simpler. Greetings, Maxime.
Maxime Devos <maximedevos@telenet.be> writes: > [[PGP Signed Part:Undecided]] > Pierre Langlois schreef op zo 27-03-2022 om 15:04 [+0100]: >> I'm also not entirely sure if it's >> #+pkg-config or #$pkg-config, both seem to work > > #+pkg-config, given that it is a thing that needs to be run during > compilation. I'm wondering, do you have transparant QEMU emulation > enabled? If so, both seeming to work is expected since QEMU will > emulate the cross-compiled cross-compiling (IIUC a canadian cross, in > GCC terminology) pkg-config. If not, I would expect some kind of error > ... Ooooh I do have qemu emulation enabled, that must be it, thanks! I'll need to be careful about that, seems too easy to make a mistake. > > Or, to allow for package transformations: > > #+(file-append (this-package-native-input (pkg-config-for-target)) > "/bin/" (pkg-config-for-target)) > > though maybe package transformations should just transform the G-exp as > well, dunno. ('file-append' is not strictly required here.) Maybe we can > have a macro (pkg-config-binary) that expands to that thing, and > use it in other packages? Yeah, if we have this pattern often it sounds like a good idea. However, better yet maybe could be to make the cmake build-system handle it automagically. I see `PKG_CONFIG_EXECUTABLE' is part of cmake itself so that might be OK? https://cmake.org/cmake/help/latest/module/FindPkgConfig.html > > Possibly interesting or irrelevant: the following will produce an > x86_64-linux-gnu-pkg-config that can be run on a aarch64-linux-gnu > computer to find libraries for x86_64-linux-gnu. > > $ guix build -e '(parameterize (((@ (guix utils) %current-target-system) "x86_64-linux-gnu")) (@ (gnu packages pkg-config) pkg-config))' --target=aarch64-linux-gnu Ha! That's pretty cool :-). Thanks, Pierre
Pierre Langlois schreef op zo 27-03-2022 om 18:27 [+0100]: > Yeah, if we have this pattern often it sounds like a good idea. > However, better yet maybe could be to make the cmake build-system > handle > it automagically. I see `PKG_CONFIG_EXECUTABLE' is part of cmake > itself > so that might be OK? > > https://cmake.org/cmake/help/latest/module/FindPkgConfig.html Seems reasonable to me, though it that probably needs to be on core- updates due to many impacted packages, so that's more of a long-term thing. Greetings, Maxime.
Maxime Devos <maximedevos@telenet.be> writes: > [[PGP Signed Part:Undecided]] > Pierre Langlois schreef op zo 27-03-2022 om 18:27 [+0100]: >> Yeah, if we have this pattern often it sounds like a good idea. >> However, better yet maybe could be to make the cmake build-system >> handle >> it automagically. I see `PKG_CONFIG_EXECUTABLE' is part of cmake >> itself >> so that might be OK? >> >> https://cmake.org/cmake/help/latest/module/FindPkgConfig.html > > Seems reasonable to me, though it that probably needs to be on core- > updates due to many impacted packages, so that's more of a long-term > thing. IMHO the most correct way to fix this problem is in CMake itself. If it's cross-compiling and there's a $TARGET_PREFIX-pkg-config in path, then it ought to use it automatically. I'm not volunteering to champion that solution though. :-) So of course the next best thing is to make Guix's build system do that for us.
diff --git a/gnu/packages/security-token.scm b/gnu/packages/security-token.scm index 6853d5bc9e..903da686f9 100644 --- a/gnu/packages/security-token.scm +++ b/gnu/packages/security-token.scm @@ -906,7 +906,16 @@ (define-public libfido2 (inputs (list zlib eudev libcbor openssl)) (build-system cmake-build-system) (arguments - '(#:phases + `(#:configure-flags (list ,@(if (%current-target-system) + `((string-append + "-DPKG_CONFIG_EXECUTABLE=" + (search-input-file %build-inputs + (string-append + "/bin/" + ,(%current-target-system) + "-pkg-config")))) + '())) + #:phases (modify-phases %standard-phases ;; regress tests enabled only for debug builds (delete 'check))))