Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'

  • Open
  • quality assurance status badge
Details
5 participants
  • Danny Milosavljevic
  • Jan Nieuwenhuizen
  • Mathieu Othacehe
  • P
  • Vivien Kraus
Owner
unassigned
Submitted by
Vivien Kraus
Severity
normal
V
V
Vivien Kraus wrote on 14 Sep 2019 09:53
(address . bug-guix@gnu.org)
87a7b7l3f3.fsf@planete-kraus.eu
Hello guix,

Trying to run 'guix build --target=x86_64-w64-mingw32 perl' results in
the following exception in the latest stages of the build:

phase `install' succeeded after 36.7 seconds
starting phase `remove-extra-references'
Backtrace:
13 (primitive-load "/gnu/store/qnavzfxvw5rng7z8rzlx9zw0ji9…")
In ice-9/eval.scm:
191:35 12 (_ _)
In srfi/srfi-1.scm:
863:16 11 (every1 #<procedure 61edc0 at /gnu/store/gfprsx2m62cvq…> …)
In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm:
799:28 10 (_ _)
In ice-9/eval.scm:
619:8 9 (_ #(#(#(#(#(#(#<directory (guile-user)…>) …) …) …) …) …))
In ice-9/boot-9.scm:
841:4 8 (with-throw-handler _ _ _)
In ice-9/ports.scm:
444:17 7 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm:
641:26 6 (_ _)
667:26 5 (_ #<input: /gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssq…> …)
In srfi/srfi-1.scm:
466:18 4 (fold #<procedure 7ffff5d2b0c0 at /gnu/store/gfprsx2m6…> …)
In ice-9/eval.scm:
202:51 3 (_ #(#(#(#(#(#(#<directory (guile-user)…> …)) …) …) …) …))
163:9 2 (_ #(#(#(#(#(#(#<directory (guile-user)…> …)) …) …) …) …))
In unknown file:
1 (string-append "incpth='" #f "/include'\n")
In ice-9/boot-9.scm:
752:25 0 (dispatch-exception _ _ _)

ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
In procedure string-append: Wrong type (expecting string): #f
builder for
`/gnu/store/2khcqc5rpc0wizhihpq69x6qn3f7nw5l-perl-5.28.0.drv' failed
with exit code 1


I have the full log. Do you wish to see it?

Did I do something wrong? Is it the same for you? Is there a
workaround?

Best regards,

Vivien
P
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)(name . 37403@debbugs.gnu.org)(address . 37403@debbugs.gnu.org)
_R48piXJzyD-bjGwWPFtNQxovaCS0VZl-zNZ2ymCKm_140q_hQnpTI1O4BZN4SqX2Y_JxfSrFE9Ile1No4dPWJUe0ehhtNJmgJNC44uhT2I=@protonmail.com
??????? Original Message ???????
On Saturday, September 14, 2019 7:53 AM, Vivien Kraus <vivien@planete-kraus.eu> wrote:

Toggle quote (49 lines)
> Hello guix,
>
> Trying to run 'guix build --target=x86_64-w64-mingw32 perl' results in
> the following exception in the latest stages of the build:
>
> phase `install' succeeded after 36.7 seconds starting phase`remove-extra-references'
> Backtrace:
> 13 (primitive-load "/gnu/store/qnavzfxvw5rng7z8rzlx9zw0ji9…")
> In ice-9/eval.scm:
> 191:35 12 (_ _)
> In srfi/srfi-1.scm:
> 863:16 11 (every1 #<procedure 61edc0 at /gnu/store/gfprsx2m62cvq…> …)
> In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm:
> 799:28 10 (_ )
> In ice-9/eval.scm:
> 619:8 9 ( #(#(#(#(#(#(#<directory (guile-user)…>) …) …) …) …) …))In ice-9/boot-9.scm:
> 841:4 8 (with-throw-handler _ _ _)
> In ice-9/ports.scm:
> 444:17 7 (call-with-input-file _ _ #:binary _ #:encoding _ # )
> In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm:
> 641:26 6 ( )
> 667:26 5 ( #<input: /gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssq…> …)In srfi/srfi-1.scm:
> 466:18 4 (fold #<procedure 7ffff5d2b0c0 at /gnu/store/gfprsx2m6…> …)
> In ice-9/eval.scm:
> 202:51 3 (_ #(#(#(#(#(#(#<directory (guile-user)…> …)) …) …) …) …))
>
> 163:9 2 (_ #(#(#(#(#(#(#<directory (guile-user)…> …)) …) …) …) …))
>
>
> In unknown file:
> 1 (string-append "incpth='" #f "/include'\n")
> In ice-9/boot-9.scm:
> 752:25 0 (dispatch-exception _ _ _)
>
> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> In procedure string-append: Wrong type (expecting string): #f
> builder for
> `/gnu/store/2khcqc5rpc0wizhihpq69x6qn3f7nw5l-perl-5.28.0.drv' failed
> with exit code 1
>
> I have the full log. Do you wish to see it?
>
> Did I do something wrong? Is it the same for you? Is there a
> workaround?
>
> Best regards,
>
> Vivien

Seems like cross compiling with mingw is broken for other packages too, I tried the guile example about a week ago and also Lua (which is a super portable language, so it should work everywhere, usually without modifications) and neither worked.
V
V
Vivien Kraus wrote on 14 Sep 2019 13:28
(name . P)(address . pronaip@protonmail.com)(name . 37403@debbugs.gnu.org)(address . 37403@debbugs.gnu.org)
878sqrktge.fsf@planete-kraus.eu
P writes:
Toggle quote (2 lines)
> Seems like cross compiling with mingw is broken for other packages too, I tried the guile example about a week ago and also Lua (which is a super portable language, so it should work everywhere, usually without modifications) and neither worked.

Oops. I was hoping I could build my Gtk+ application with guix,
and thus get rid of the Fedora container.

This bug is so depressing though: perl builds just fine, installs just
fine, but guix fails at the very end, in the 'remove-extra-references' step.

Vivien
D
D
Danny Milosavljevic wrote on 14 Sep 2019 13:59
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)(address . 37403@debbugs.gnu.org)
20190914135953.6adaef8b@scratchpost.org
Looking at the source code of phase "remove-extra-references" and assuming that
the "out" output exists, probably the "libc" input doesn't exist.

set-cross-path/mingw guards against this case, so apparently it is normal that
"libc" input can be missing and perl should be guarding against it, but doesn't.

Otherwise I don't know mingw, so can't help much further.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl181jkACgkQ5xo1VCww
uqXOoAf/R73ZO9y3DgclLAhh9ai21ILF4xodO7o7uaW6YsZsZkXGLXN81AboXSjv
Ag2HILoGTP9sxND91emhcX5IOPxnDtwmYf7aoe1PzFw6yrBzY5Ex11ic6tAnP1n3
G1o+etj1SrbNGvIshXIn5CWl6Inpi/2ulk7+XgiI9aJ8IDQ5pmZYkjNs0vyckBds
YQSknM366XRhUtQeXqvqsoaWmtkwMU7PbZjA5n0xii/9879gfF+SRSJj0zMqPAgK
C3OJOBcahc9iWsgEiV+SZjC92PQX110BqBfVdoyhhIcc4NTvfJQSvR4fTSrsE1Ps
Cmrq3udK1kKhVOFQ3YZEbUB38PeHbw==
=vnjX
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 14 Sep 2019 14:23
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)(address . 37403@debbugs.gnu.org)
20190914142338.41be36cb@scratchpost.org
Further information:

According to gnu/packages/cross-base.scm, cross-gcc contains either "libc" or
"mingw-source" in the mingw case--I don't know why, but that's what it says.

The purpose of "remove-extra-references" seems to be to shrink the
number of recorded dependencies, so maybe compare it with the unshrinked
list of dependencies by printing the latter out (apparently it should be
inside Config_heavy.pl and Config.pm in the temporary build
directory--could you post those?).

I tried it myself (with mingw target) and I got:

loclibpth='/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib'

Hmm.

Also, perl seems to fetch libc from the %build-inputs just fine earlier.

So try putting (assoc-ref native-inputs "libc") instead of
(assoc-ref inputs "libc") in the perl package definition (make sure to
accept native-inputs in the function in the first place) in order to debug
the problem (or maybe (assoc-ref inputs "mingw-source")).

When cross compiling it's important to get right which parts you get
from the host libs and which from the target libs, maybe that's messed
up there.

Also possible would be not to do that shrinking if libc is unavailable,
but not sure whether we want that.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl1828oACgkQ5xo1VCww
uqXy/Af+NzKn64Jry3qM5Agm+Bh5JaViJ/MXRxXqN3FCs689N+YCAhZuk2o+UgPb
AqUrCjzwAp5QcVMY874nycjJsiSIwFFcCVpOuyOVJtMiTgTBfr9KHhBcOJ7PvGsS
+/vDvSlOPByxBcOxeOQ0Qqaoue5UMZOIQGWlWFH7eNeZcC4Xu8t4ALBVvZCEZeyo
dERLP9CsahglyIUtaFl5SE0Rk4oIePzioxg7dYzfvRoKEsI7aHjDvXkjcDI9ikms
F4c7cHHhrZnc4VQfAefChJYR5iDE/uIUqpHujHkIMZz7NVrAq7dEw4fjp6GeJpcE
FESeK1y3HulyfpZjnwN7mz+B+L//kw==
=dqiB
-----END PGP SIGNATURE-----


J
J
Jan Nieuwenhuizen wrote on 14 Sep 2019 15:16
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)(address . 37403@debbugs.gnu.org)
877e6b81d7.fsf@gnu.org
Vivien Kraus writes:

Toggle quote (3 lines)
> Trying to run 'guix build --target=x86_64-w64-mingw32 perl' results in
> the following exception in the latest stages of the build:

Are you using the core-updates-next branch? It has a many
cross-compilation fixes, notably


Greetings,
janneke

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
V
V
Vivien Kraus wrote on 14 Sep 2019 19:24
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 37403@debbugs.gnu.org)
877e6alrk2.fsf@planete-kraus.eu
Hello,


Danny Milosavljevic writes:

Toggle quote (6 lines)
> The purpose of "remove-extra-references" seems to be to shrink the
> number of recorded dependencies, so maybe compare it with the unshrinked
> list of dependencies by printing the latter out (apparently it should be
> inside Config_heavy.pl and Config.pm in the temporary build
> directory--could you post those?).

I have several Config.pm files:

./lib/perl5/5.28.0/Net/Config.pm
./lib/perl5/5.28.0/ExtUtils/MakeMaker/Config.pm
./lib/perl5/5.28.0/x86_64-linux-thread-multi/Config.pm
./lib/perl5/5.28.0/x86_64-linux-thread-multi/Encode/Config.pm

In doubt I attach all four, plus the Config_heavy one :)
Attachment: Config_heavy.pl
Attachment: Config.pm
package ExtUtils::MakeMaker::Config;

use strict;

our $VERSION = '7.34';
$VERSION = eval $VERSION;

use Config ();

# Give us an overridable config.
our %Config = %Config::Config;

sub import {
my $caller = caller;

no strict 'refs'; ## no critic
*{$caller.'::Config'} = \%Config;
}

1;


=head1 NAME

ExtUtils::MakeMaker::Config - Wrapper around Config.pm


=head1 SYNOPSIS

use ExtUtils::MakeMaker::Config;
print $Config{installbin}; # or whatever


=head1 DESCRIPTION

B<FOR INTERNAL USE ONLY>

A very thin wrapper around Config.pm so MakeMaker is easier to test.

=cut
# This file was created by configpm when Perl was built. Any changes
# made to this file will be lost the next time perl is built.

# for a description of the variables, please have a look at the
# Glossary file, as written in the Porting folder, or use the url:

package Config;
use strict;
use warnings;
our ( %Config, $VERSION );

$VERSION = "5.028000";

# Skip @Config::EXPORT because it only contains %Config, which we special
# case below as it's not a function. @Config::EXPORT won't change in the
# lifetime of Perl 5.
my %Export_Cache = (myconfig => 1, config_sh => 1, config_vars => 1,
config_re => 1, compile_date => 1, local_patches => 1,
bincompat_options => 1, non_bincompat_options => 1,
header_files => 1);

@Config::EXPORT = qw(%Config);
@Config::EXPORT_OK = keys %Export_Cache;

# Need to stub all the functions to make code such as print Config::config_sh
# keep working

sub bincompat_options;
sub compile_date;
sub config_re;
sub config_sh;
sub config_vars;
sub header_files;
sub local_patches;
sub myconfig;
sub non_bincompat_options;

# Define our own import method to avoid pulling in the full Exporter:
sub import {
shift;
@_ = @Config::EXPORT unless @_;

my @funcs = grep $_ ne '%Config', @_;
my $export_Config = @funcs < @_ ? 1 : 0;

no strict 'refs';
my $callpkg = caller(0);
foreach my $func (@funcs) {
die qq{"$func" is not exported by the Config module\n}
unless $Export_Cache{$func};
*{$callpkg.'::'.$func} = \&{$func};
}

*{"$callpkg\::Config"} = \%Config if $export_Config;
return;
}

die "$0: Perl lib version (5.28.0) doesn't match executable '$^X' version ($])"
unless $^V;

$^V eq 5.28.0
or die sprintf "%s: Perl lib version (5.28.0) doesn't match executable '$^X' version (%vd)", $0, $^V;


sub FETCH {
my($self, $key) = @_;

# check for cached value (which may be undef so we use exists not defined)
return exists $self->{$key} ? $self->{$key} : $self->fetch_string($key);
}

sub TIEHASH {
bless $_[1], $_[0];
}

sub DESTROY { }

sub AUTOLOAD {
require 'Config_heavy.pl';
goto \&launcher unless $Config::AUTOLOAD =~ /launcher$/;
die "&Config::AUTOLOAD failed on $Config::AUTOLOAD";
}

# tie returns the object, so the value returned to require will be true.
tie %Config, 'Config', {
archlibexp => '/gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssqw-perl-5.28.0/lib/perl5/5.28.0/x86_64-linux-thread-multi',
archname => 'x86_64-linux-thread-multi',
cc => 'gcc',
d_readlink => 'define',
d_symlink => 'define',
dlext => 'so',
dlsrc => 'dl_dlopen.xs',
dont_use_nlink => undef,
exe_ext => '',
inc_version_list => ' ',
intsize => '4',
ldlibpthname => 'LD_LIBRARY_PATH',
libpth => '/gnu/store/571zsgw2bby7vrz8201br40snlvl0xbl-gcc-cross-x86_64-w64-mingw32-5.5.0/lib /gnu/store/j74aabxwayjl9yfyrm6ni482gykxq48b-bzip2-1.0.6/lib /gnu/store/9425b5dwpfc04bb4p58hsjypxghliyr3-xz-5.2.4/lib /gnu/store/ypiyk8ngn79cz655jrl0hng37xv54yjr-file-5.33/lib /gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/lib /gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/lib /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib /gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include-fixed',
osname => 'linux',
osvers => '',
path_sep => ':',
privlibexp => '/gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssqw-perl-5.28.0/lib/perl5/5.28.0',
scriptdir => '/gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssqw-perl-5.28.0/bin',
sitearchexp => '/gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssqw-perl-5.28.0/lib/perl5/site_perl/5.28.0/x86_64-linux-thread-multi',
sitelibexp => '/gnu/store/fa7x5xq709dvsx0rnz167f5ba2h6ssqw-perl-5.28.0/lib/perl5/site_perl/5.28.0',
so => 'so',
useithreads => 'define',
usevendorprefix => undef,
version => '5.28.0',
};
Attachment: Config.pm
Toggle quote (4 lines)
>
> I tried it myself (with mingw target) and I got:
>
> loclibpth='/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib'
I have exactly this one in Config_heavy.pl.

Toggle quote (4 lines)
> So try putting (assoc-ref native-inputs "libc") instead of
> (assoc-ref inputs "libc") in the perl package definition (make sure to
> accept native-inputs in the function in the first place) in order to debug
> the problem (or maybe (assoc-ref inputs "mingw-source")).
I am not 100% sure I understood everything, but I tried that and it
changed nothing.

Toggle quote (4 lines)
>
> When cross compiling it's important to get right which parts you get
> from the host libs and which from the target libs, maybe that's messed
> up there.
I am trying to build Gtk+ for mingw. This gives me an error in the perl
dependency. I have the same error if I build perl for mingw, but it is
a little confusing: perl should be a "maintainer" dependency for Gtk+ (I
guess? Maybe for automake or some code generators like the
gobject-introspection tools?), so it should be
built to run on the build machine (x86_64-linux) and not on the
host/target (mingw). Why is there an error if I build perl for mingw,
or if I build perl as a dependency for mingw Gtk+, but not if I build
perl for my native system? Or maybe native-perl and target-perl are
both dependencies for target-gtk+?


Best regards,

Vivien
V
V
Vivien Kraus wrote on 14 Sep 2019 19:25
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 37403@debbugs.gnu.org)
875zlulri8.fsf@planete-kraus.eu
Hello,

Jan Nieuwenhuizen writes:
Toggle quote (2 lines)
> Are you using the core-updates-next branch?

No, how do I do that?

Best regards,

Vivien
J
J
Jan Nieuwenhuizen wrote on 15 Sep 2019 14:16
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)(address . 37403@debbugs.gnu.org)
87v9ttah5e.fsf@gnu.org
Vivien Kraus writes:

Toggle quote (4 lines)
>> Are you using the core-updates-next branch?
>
> No,

Ah. In that case it's a `know bug' that is being worked on.

Toggle quote (2 lines)
> how do I do that?

I looked into core-updates-next and at the moment it does not seem to be
in a really usable state, in other words: work in progress.

Theoretically one might do `guix pull --branch=<branch-name>'. However,
branches other than master and version-1.0.x are generally not suited
for general use. See `14.6 Submitting Patches'

Using a developer branch like core-updates-next is usually done by
working on a clone of the Guix Git archive. See `14.1 Building from

Greetings,
janneke

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
M
M
Mathieu Othacehe wrote on 25 Mar 2020 20:49
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
87v9ms9puo.fsf@gmail.com
Hello,

A small update on this bug, cross-compilation to x86_64-w64-mingw32 does
not fail anymore on core-updates.

However, the native gcc is used to build perl so there is still some
work required!

Mathieu
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 37403@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 37403
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch