[bug#68263,0/2] libsmbios: Restrict to only supported systems.

Hello,

> I'm not seeing that error, I'm getting json-glib failing to
> cross-compile. Is it possible you have some stale .go files? (guix
> platforms) changed recently.

That was the issue! I have a new error, but this this in gnupg:

--8<---------------cut here---------------start------------->8---
%exception #<&invoke-error program: "/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash" arguments: ("./configure" "CC_FOR_BUILD=gcc" "CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash" "SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash" "--prefix=/gnu/store/0ksgybn4n10j0b3wcqfl1jpcjr79xq8l-gnupg-2.2.39" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--host=aarch64-linux-gnu" "--enable-gnupg-builddir-envvar" "--enable-all-tests") exit-status: 1 term-signal: #f stop-signal: #f> 
phase `configure' failed after 9.4 seconds
command "/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash" "./configure" "CC_FOR_BUILD=gcc" "CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash" "SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash" "--prefix=/gnu/store/0ksgybn4n10j0b3wcqfl1jpcjr79xq8l-gnupg-2.2.39" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--host=aarch64-linux-gnu" "--enable-gnupg-builddir-envvar" "--enable-all-tests" failed with status 1
note: keeping build directory `/tmp/guix-build-gnupg-2.2.39.drv-1'
builder for `/gnu/store/qac9bix1331g6f12dgyrk4wvn2dpgp3k-gnupg-2.2.39.drv' failed with exit code 1
build of /gnu/store/qac9bix1331g6f12dgyrk4wvn2dpgp3k-gnupg-2.2.39.drv failed
--8<---------------cut here---------------end--------------->8---

I fixed it with the attached patch. Now libsmbios itself fails to
cross-compile:

--8<---------------cut here---------------start------------->8---
src/libsmbios_c/cmos/cmos_linux.c:25:10: fatal error: sys/io.h: No such file or directory
   25 | #include <sys/io.h>
      |          ^~~~~~~~~~
compilation terminated.
--8<---------------cut here---------------end--------------->8---

Thanks,

Mathieu
  

Mathieu Othacehe <othacehe@gnu.org> writes:
>> I'm not seeing that error, I'm getting json-glib failing to
>> cross-compile. Is it possible you have some stale .go files? (guix
>> platforms) changed recently.
>
> That was the issue!

How exactly did you get past this?  I have the same issue myself now,
even after running "make distclean" and "git clean -fxd" and rebuilding:

[env]$ ./pre-inst-env guix build --dry-run --target=x86_64-linux-gnu --verbosity=2 fwupd
Backtrace:
In guix/packages.scm:
  1618:16 19 (package->bag _ _ _ #:graft? _)
  1719:48 18 (thunk)
  1512:25 17 (inputs _)
In srfi/srfi-1.scm:
   586:29 16 (map1 (("coreutils" #<package coreutils@9.1 guix/b?>) ?))
   586:29 15 (map1 (("grep" #<package grep@3.8 gnu/packages/com?>) ?))
   586:29 14 (map1 (("xz" #<package xz@5.2.8 gnu/packages/comme?>) ?))
   586:29 13 (map1 (("locales" #<package glibc-utf8-locales@2.3?>) ?))
   586:29 12 (map1 (("bash" #<package bash-minimal@5.1.16 gnu/p?>) ?))
   586:17 11 (map1 (("gcc" #<package gcc@11.3.0 gnu/packages/co?>) ?))
In guix/packages.scm:
  1469:20 10 (rewrite ("gcc" #<package gcc@11.3.0 gnu/packages/com?>))
In guix/memoization.scm:
    101:0  9 (_ #<hash-table ffffa8b4ba80 14/31> #<package gcc@11.3?> ?)
In guix/packages.scm:
  1483:13  8 (_)
In guix/build-system/gnu.scm:
   158:33  7 (cut? _)
In gnu/packages/commencement.scm:
  3241:36  6 (arguments #<package gcc@11.3.0 gnu/packages/commenceme?>)
In gnu/packages/gcc.scm:
   748:34  5 (arguments #<package gcc@11.3.0 gnu/packages/gcc.scm:73?>)
   218:48  4 (arguments #<package gcc@4.8.5 gnu/packages/gcc.scm:398?>)
In gnu/packages/bootstrap.scm:
   338:11  3 (_)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
dynamic linker name not known for this system "x86_64-linux-gnu"
  

On Mon, Jan 08, 2024 at 12:58:52PM -0500, Simon South wrote:
> Mathieu Othacehe <othacehe@gnu.org> writes:
> >> I'm not seeing that error, I'm getting json-glib failing to
> >> cross-compile. Is it possible you have some stale .go files? (guix
> >> platforms) changed recently.
> >
> > That was the issue!
> 
> How exactly did you get past this?  I have the same issue myself now,
> even after running "make distclean" and "git clean -fxd" and rebuilding:
> 
> [env]$ ./pre-inst-env guix build --dry-run --target=x86_64-linux-gnu --verbosity=2 fwupd
> Backtrace:
> In guix/packages.scm:
>   1618:16 19 (package->bag _ _ _ #:graft? _)
>   1719:48 18 (thunk)
>   1512:25 17 (inputs _)
> In srfi/srfi-1.scm:
>    586:29 16 (map1 (("coreutils" #<package coreutils@9.1 guix/b?>) ?))
>    586:29 15 (map1 (("grep" #<package grep@3.8 gnu/packages/com?>) ?))
>    586:29 14 (map1 (("xz" #<package xz@5.2.8 gnu/packages/comme?>) ?))
>    586:29 13 (map1 (("locales" #<package glibc-utf8-locales@2.3?>) ?))
>    586:29 12 (map1 (("bash" #<package bash-minimal@5.1.16 gnu/p?>) ?))
>    586:17 11 (map1 (("gcc" #<package gcc@11.3.0 gnu/packages/co?>) ?))
> In guix/packages.scm:
>   1469:20 10 (rewrite ("gcc" #<package gcc@11.3.0 gnu/packages/com?>))
> In guix/memoization.scm:
>     101:0  9 (_ #<hash-table ffffa8b4ba80 14/31> #<package gcc@11.3?> ?)
> In guix/packages.scm:
>   1483:13  8 (_)
> In guix/build-system/gnu.scm:
>    158:33  7 (cut? _)
> In gnu/packages/commencement.scm:
>   3241:36  6 (arguments #<package gcc@11.3.0 gnu/packages/commenceme?>)
> In gnu/packages/gcc.scm:
>    748:34  5 (arguments #<package gcc@11.3.0 gnu/packages/gcc.scm:73?>)
>    218:48  4 (arguments #<package gcc@4.8.5 gnu/packages/gcc.scm:398?>)
> In gnu/packages/bootstrap.scm:
>    338:11  3 (_)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> dynamic linker name not known for this system "x86_64-linux-gnu"

Taking what you've written exactly for the moment, did you rerun
bootstrap and configure and make first? the pre-inst-env script needs to
get regenerated after cleaning the repo.

I always do my building with --no-grafts.  Also, are you building
x86_64-linux -> x86_64-linux-gnu? I often get weird errors when I try to
do things like that.
  

Efraim Flashner <efraim@flashner.co.il> writes:
> Taking what you've written exactly for the moment, did you rerun
> bootstrap and configure and make first?

I did, yes:

./bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc && make -j6

after cleaning out the source tree.

I get the same result also whether I run "./pre-inst-env guix build
--target=..."  outside of a "guix shell --pure --development guix"
environment, inside of one using the system instance of Guix, or inside
of one invoked from the built source tree (i.e. "./pre-inst-env guix
shell...") before rebuilding with "./bootstrap..." again.

I'm really at a loss.  What else could cause this error?  I seem to
recall this working a short while ago so I may try bisecting the source
tree if nothing else comes to mind.

> Also, are you building x86_64-linux -> x86_64-linux-gnu?

No, I'm on AArch64, but trying to cross-build from my x86-64 machine to
aarch64-linux-gnu produces the same (well, equivalent) error, even after
the same steps above.
  

Hello,

So, here is what happens:

You are adding 
--8<---------------cut here---------------start------------->8---
    (supported-systems (list "i686-linux" "x86_64-linux"))
--8<---------------cut here---------------end--------------->8---

to libsmbios. That is fine, it prints:

--8<---------------cut here---------------start------------->8---
package libsmbios@2.4.3 does not support aarch64-linux
--8<---------------cut here---------------end--------------->8---

when running `guix build -s aarch64-linux libsmbios`. It doesn't print
anything when cross-compiling this way: `guix build
--target=aarch64-linux-gnu libsmbios`, tries to cross-compile and fails
because of the <sys/io.h> header as you noticed.

It makes me think that we should turn `supported-systems` into
`supported-platforms` so that we get the same kind of warning when
trying to cross-compile. But that's another topic.

Now regarding your second patch, this part:

--8<---------------cut here---------------start------------->8---
(if (supported-package? libsmbios
                        (or (%current-target-system)
                            (%current-system)))
--8<---------------cut here---------------end--------------->8---

will actually call (supported-package? libsmbios "aarch64-linux-gnu")
when cross-compiling, which prints this error message:

--8<---------------cut here---------------start------------->8---
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
dynamic linker name not known for this system "aarch64-linux-gnu"
--8<---------------cut here---------------end--------------->8---

It has nothing to do with ABI break and .go files. It is just that
supported-package? is expecting a system not a target.

What you could do is rewriting this part as:

--8<---------------cut here---------------start------------->8---
(if (supported-package? libsmbios
                        (if (%current-target-system)
                            (platform-target->system
                             (%current-target-system))
                            (%current-system)))
--8<---------------cut here---------------end--------------->8---

which works as expected because the target is translated into a
system. A better fix would be to have supported-package? deal with
both systems and targets internally.

Then fwupd cross-compilation fails because other dependencies such as
gts fail to cross-compile, but that irrelevant here.

Thanks,

Mathieu
  

Mathieu Othacehe <othacehe@gnu.org> writes:
> It has nothing to do with ABI break and .go files. It is just that
> supported-package? is expecting a system not a target.

Ah, that makes perfect sense.  Thank you for the explanation.  It never
occurred to me (%current-system) and (%current-target-system) would be
returning different types.

I'll submit an updated patchset shortly.