bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
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
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Vivien Kraus writes: >> Are you using the core-updates-next branch? > > No, Ah. In that case it's a `know bug' that is being worked on. > 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='. However, branches other than master and version-1.0.x are generally not suited for general use. See `14.6 Submitting Patches' (https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html). 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 Git' (https://guix.gnu.org/manual/en/html_node/Building-from-Git.html). Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Hello, Jan Nieuwenhuizen writes: > Are you using the core-updates-next branch? No, how do I do that? Best regards, Vivien
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Hello,
Danny Milosavljevic writes:
> 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 :)
# 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.
package Config;
use strict;
use warnings;
our %Config;
sub bincompat_options {
return split ' ', (Internals::V())[0];
}
sub non_bincompat_options {
return split ' ', (Internals::V())[1];
}
sub compile_date {
return (Internals::V())[2]
}
sub local_patches {
my (undef, undef, undef, @patches) = Internals::V();
return @patches;
}
sub _V {
die "Perl lib was built for 'linux' but is being run on '$^O'"
unless "linux" eq $^O;
my ($bincompat, $non_bincompat, $date, @patches) = Internals::V();
my @opts = sort split ' ', "$bincompat $non_bincompat";
print Config::myconfig();
print "\nCharacteristics of this binary (from libperl): \n";
print " Compile-time options:\n";
print "$_\n" for @opts;
if (@patches) {
print " Locally applied patches:\n";
print "$_\n" foreach @patches;
}
print " Built under linux\n";
print " $date\n" if defined $date;
my @env = map { "$_=\"$ENV{$_}\"" } sort grep {/^PERL/} keys %ENV;
if (@env) {
print " \%ENV:\n";
print "$_\n" foreach @env;
}
print " \@INC:\n";
print "$_\n" foreach @INC;
}
sub header_files {
return qw(EXTERN.h INTERN.h XSUB.h av.h config.h cop.h cv.h
dosish.h embed.h embedvar.h form.h gv.h handy.h hv.h hv_func.h
intrpvar.h iperlsys.h keywords.h mg.h nostdio.h op.h opcode.h
pad.h parser.h patchlevel.h perl.h perlio.h perliol.h perlsdio.h
perlvars.h perly.h pp.h pp_proto.h proto.h regcomp.h regexp.h
regnodes.h scope.h sv.h thread.h time64.h unixish.h utf8.h
util.h);
}
##!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh
##
## This file was produced by running the Configure script. It holds all the
## definitions figured out by Configure. Should you modify one of these values,
## do not forget to propagate your changes by running "Configure -der". You may
## instead choose to run each of the .SH files by yourself, or "Configure -S".
##
#
## Package name : perl5
## Source directory : .
## Configuration time: 1970-01-01
## Configured by : guix
## Target system : linux
#
#: Configure command line arguments.
#
#: Variables propagated from previous config.sh file.
our $summary = <<'!END!';
Summary of my $package (revision $revision $version_patchlevel_string) configuration:
$git_commit_id_title $git_commit_id$git_ancestor_line
Platform:
osname=$osname
osvers=$osvers
archname=$archname
uname='$myuname'
config_args='$config_args'
hint=$hint
useposix=$useposix
d_sigaction=$d_sigaction
useithreads=$useithreads
usemultiplicity=$usemultiplicity
use64bitint=$use64bitint
use64bitall=$use64bitall
uselongdouble=$uselongdouble
usemymalloc=$usemymalloc
default_inc_excludes_dot=$default_inc_excludes_dot
bincompat5005=undef
Compiler:
cc='$cc'
ccflags ='$ccflags'
optimize='$optimize'
cppflags='$cppflags'
ccversion='$ccversion'
gccversion='$gccversion'
gccosandvers='$gccosandvers'
intsize=$intsize
longsize=$longsize
ptrsize=$ptrsize
doublesize=$doublesize
byteorder=$byteorder
doublekind=$doublekind
d_longlong=$d_longlong
longlongsize=$longlongsize
d_longdbl=$d_longdbl
longdblsize=$longdblsize
longdblkind=$longdblkind
ivtype='$ivtype'
ivsize=$ivsize
nvtype='$nvtype'
nvsize=$nvsize
Off_t='$lseektype'
lseeksize=$lseeksize
alignbytes=$alignbytes
prototype=$prototype
Linker and Libraries:
ld='$ld'
ldflags ='$ldflags'
libpth=$libpth
libs=$libs
perllibs=$perllibs
libc=$libc
so=$so
useshrplib=$useshrplib
libperl=$libperl
gnulibc_version='$gnulibc_version'
Dynamic Linking:
dlsrc=$dlsrc
dlext=$dlext
d_dlsymun=$d_dlsymun
ccdlflags='$ccdlflags'
cccdlflags='$cccdlflags'
lddlflags='$lddlflags'
!END!
my $summary_expanded;
sub myconfig {
return $summary_expanded if $summary_expanded;
($summary_expanded = $summary) =~ s{\$(\w+)}
{
my $c;
if ($1 eq 'git_ancestor_line') {
if ($Config::Config{git_ancestor}) {
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
Vivien Kraus writes: > 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 https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-next=659a2d0f4fff889dff902e32b569e4ca0ae5384a Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
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. pgpPClSD86cWZ.pgp Description: OpenPGP digital signature
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
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. pgp7L7_kX2xtC.pgp Description: OpenPGP digital signature
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
P writes: > 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
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
‐‐‐ Original Message ‐‐‐ On Saturday, September 14, 2019 7:53 AM, Vivien Kraus wrote: > 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 # …) > In > /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm: > 799:28 10 (_ ) > In ice-9/eval.scm: > 619:8 9 ( #(#(#(#(#(#(#) …) …) …) …) …))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 ( # …)In > srfi/srfi-1.scm: > 466:18 4 (fold # …) > In ice-9/eval.scm: > 202:51 3 (_ #(#(#(#(#(#(# …)) …) …) …) …)) > > 163:9 2 (_ #(#(#(#(#(#(# …)) …) …) …) …)) > > > 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.
bug#37403: Cannot 'guix guix build --target=x86_64-w64-mingw32 perl'
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 # …) In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm: 799:28 10 (_ _) In ice-9/eval.scm: 619:8 9 (_ #(#(#(#(#(#(#) …) …) …) …) …)) 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 (_ # …) In srfi/srfi-1.scm: 466:18 4 (fold # …) In ice-9/eval.scm: 202:51 3 (_ #(#(#(#(#(#(# …)) …) …) …) …)) 163:9 2 (_ #(#(#(#(#(#(# …)) …) …) …) …)) 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
