Re: trivial-build-system: ld can't find existing store files
On Wed, Jan 17 2024, Simon Tournier wrote: > Hi, > > On Sun, 14 Jan 2024 at 11:10, Christina O'Donnell wrote: > >> So I'm trying to write a package with a single C file using >> trivial-build-system[1]. > > Despite its name, trivial-build-system is the less trivial > build-system. Hum, gnu-build-system appears to me better for one single > C file, even if there is no Makefile. > > Felix provided how to use trivial-build-system. Well – aside I am not > convinced that %build-inputs is a good way – as we see, many thing need > to be configured by hand, when gnu-build-system does it for you. There is the copy-build-system too :) Which is like the gnu-build-system, without bootstrap, configure, build, check, install. And you don't need all those stuff so... Thanks for your contribution! Clément
Re: trivial-build-system: ld can't find existing store files
Hi Simon, Okay I can believe this, I'm only just learning about the autoconf and co. I've already submitted a patch, but I'm happy to change it to gnu-build-system if it'll make it simpler. autoconf is more automatic than I've given it credit for! https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68502 I've put it on my list of things to get back to when I next have a clean checkout. Kind regard, Christina O'Donnell On 17/01/2024 16:40, Simon Tournier wrote: Hi, On Sun, 14 Jan 2024 at 11:10, Christina O'Donnell wrote: So I'm trying to write a package with a single C file using trivial-build-system[1]. Despite its name, trivial-build-system is the less trivial build-system. Hum, gnu-build-system appears to me better for one single C file, even if there is no Makefile. Felix provided how to use trivial-build-system. Well – aside I am not convinced that %build-inputs is a good way – as we see, many thing need to be configured by hand, when gnu-build-system does it for you. Cheers, simon
Re: trivial-build-system: ld can't find existing store files
Hi, On Sun, 14 Jan 2024 at 11:10, Christina O'Donnell wrote: > So I'm trying to write a package with a single C file using > trivial-build-system[1]. Despite its name, trivial-build-system is the less trivial build-system. Hum, gnu-build-system appears to me better for one single C file, even if there is no Makefile. Felix provided how to use trivial-build-system. Well – aside I am not convinced that %build-inputs is a good way – as we see, many thing need to be configured by hand, when gnu-build-system does it for you. Cheers, simon
Re: trivial-build-system: ld can't find existing store files
Hi Christina, On Sun, Jan 14 2024, Christina O'Donnell wrote: > /gnu/store/cv571kkg5hyk98yw48857h1d0zi9azni-binutils-2.38/bin/ld: cannot find > crt1.o: No such file or directory > /gnu/store/cv571kkg5hyk98yw48857h1d0zi9azni-binutils-2.38/bin/ld: cannot find > crti.o: No such file or directory The code below worked for me (with 'guix build -f evhz.scm') although I'm a novice myself. Thanks for using Guix! Kind regards Felix * * * (define-module (gnu packages evhz) #:use-module (guix gexp) #:use-module ((guix licenses) #:prefix license:) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix git-download) #:use-module (guix build-system trivial) #:use-module (guix utils) #:use-module (gnu packages) #:use-module (gnu packages base) #:use-module (gnu packages commencement) #:use-module (gnu packages gcc) #:use-module (gnu packages glib) #:use-module (gnu packages linux) #:use-module (gnu packages xorg)) (define-public evhz (let ((commit "35b7526e0655522bbdf92f6384f4e9dff74f38a0") (revision "1")) (package (name "evhz") (version (git-version "0.0.0" revision commit)) (source (origin (method git-fetch) (uri (git-reference (url "https://git.sr.ht/~iank/evhz;) (commit commit))) (sha256 (base32 "1m2m60sh12jzc8f38g7g67b3avx2vg8ff0lai891jmjqvxw04bcl" (build-system trivial-build-system) (arguments `(#:modules ((guix build utils)) #:builder (begin (use-modules (guix build utils)) (let ((source (assoc-ref %build-inputs "source")) (glibc (assoc-ref %build-inputs "glibc")) (gcc (assoc-ref %build-inputs "gcc")) (binutils (assoc-ref %build-inputs "binutils")) (linux-libre-headers (assoc-ref %build-inputs "linux-libre-headers")) (output (assoc-ref %outputs "out"))) (setenv "PATH" (string-join (list (string-append gcc "/bin") (string-append binutils "/bin") (getenv "PATH")) ":")) (setenv "LIBRARY_PATH" (string-join (list (string-append glibc "/lib")) ":")) (mkdir-p (string-append output "/bin")) (invoke (string-append gcc "/bin/gcc") "-o" (string-append output "/bin/evhz") "-I" (string-append linux-libre-headers "/include") (string-append source "/evhz.c")) #t (native-inputs (list binutils gcc gcc-toolchain glibc linux-libre-headers)) (home-page "https://git.sr.ht/~iank/evhz;) (synopsis "Show mouse refresh rate under linux + evdev.") (description "A simple diagnostic utility to show mouse refresh rate under linux + evdev.") (license license:apsl2 evhz
trivial-build-system: ld can't find existing store files
Hey Guix! I've been banging my head against this one for a while and I'd appreciate if someone could take a look at it quickly, and spot where I went wrong. So I'm trying to write a package with a single C file using trivial-build-system[1]. I feel like I'm almost there, except when building the linker fails to find the glibc object files that I definitely specified. What makes this seem odd to me is: the same command succeeds if I run in a container shell with only the dependencies and guile used. I've attached the following files: - evhz.scm - containing the package definition that I just have in /gnu/packages/ in my checkout. (this is the only change) - build-evhz.out - the output of ./pre-inst-env guix build evhz - manual-gcc.out - the output of the command running the invoke gcc command in a guix-shell container I've tried the following: - make clean and tried a few different master branch versions to see if that might shake it into action, but no avail. - Setting LD_LIBRARY_PATH, no effect - Specifying the library files explicitly with -l, still can't find them - Specifying native-inputs instead of just inputs, no change If someone could take a look at my package definition, I've included the body snippet below (full code attached): (build-system trivial-build-system) (arguments `(#:modules ((guix build utils)) #:builder (begin (use-modules (guix build utils)) (let ((source (assoc-ref %build-inputs "source")) (glibc (assoc-ref %build-inputs "glibc")) (gcc (assoc-ref %build-inputs "gcc")) (binutils (assoc-ref %build-inputs "binutils")) (linux-libre-headers (assoc-ref %build-inputs "linux-libre-headers")) (output (assoc-ref %outputs "out"))) (setenv "PATH" (string-join (list (string-append gcc "/bin") (string-append binutils "/bin") (getenv "PATH")) ":")) (mkdir-p (string-append output "/bin")) (invoke (string-append gcc "/bin/gcc") "-o" (string-append output "/bin/evhz") "-I" (string-append linux-libre-headers "/include") "-L" (string-append glibc "/lib") (string-append source "/evhz.c")) #t (inputs (list binutils gcc gcc-toolchain glibc linux-libre-headers)) Thanks for making Guix awesome! Christina O'Donnell [1] It's my first attempt packaging and this looked the easiest on to start with. There's no make file, so trivial-build-system seemed like it'd be the right fit.[2] [2] Aside: I saw that none of the trivial-build-system packages in Guix use Gexp. Is Gexp compatible with trivial-build-system? I couldn't make it work. ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2013, 2014 Andreas Enge ;;; Copyright © 2014, 2015, 2017, 2018, 2020 Mark H Weaver ;;; Copyright © 2014, 2015 Eric Bavier ;;; Copyright © 2015-2022 Ludovic Courtès ;;; Copyright © 2015 Eric Dvorsak ;;; Copyright © 2016 Mathieu Lirzin ;;; Copyright © 2015 Cyrill Schenkel ;;; Copyright © 2016, 2017, 2019-2023 Efraim Flashner ;;; Copyright © 2016 Nikita ;;; Copyright © 2016 Alex Kost ;;; Copyright © 2016 David Craven ;;; Copyright © 2016, 2017 John Darrington ;;; Copyright © 2017-2022 Marius Bakke ;;; Copyright © 2017, 2018, 2019 Rutger Helling ;;; Copyright © 2017, 2020 Arun Isaac ;;; Copyright © 2018–2022 Tobias Geerinckx-Rice ;;; Copyright © 2018 Kei Kebreau ;;; Copyright © 2018, 2020, 2022 Oleg Pykhalov ;;; Copyright © 2018 Benjamin Slade ;;; Copyright © 2019 nee ;;; Copyright © 2019 Yoshinori Arai ;;; Copyright © 2019 Mathieu Othacehe ;;; Copyright © 2020 Liliana Marie Prikler ;;; Copyright © 2020 Florian Pelz ;;; Copyright © 2020, 2021 Michael Rohleder ;;; Copyright © 2020, 2021, 2022, 2023 Maxim Cournoyer ;;; Copyright © 2020 Jean-Baptiste Note ;;; Copyright © 2021 Matthew James Kraai ;;; Copyright © 2021 Nicolò Balzarotti ;;; Copyright © 2021 Matthew James Kraai ;;; Copyright © 2021 Brice Waegeneire ;;; Copyright © 2021 Matthew James Kraai ;;; Copyright © 2021 Maxime Devos ;;; Copyright © 2021 qblade ;;; Copyright © 2021 Lu Hui ;;; Copyright © 2023 Zheng Junjie <873216...@qq.com> ;;; Copyright © 2023 Janneke Nieuwenhuizen ;;; Copyright © 2023 John Kehayias ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the
