[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW cross-compilation support
From: |
Ludovic Courtès |
Subject: |
Re: MinGW cross-compilation support |
Date: |
Wed, 07 Dec 2016 22:39:31 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Jan Nieuwenhuizen <address@hidden> skribis:
> Ludovic Courtès writes:
>
>> After all this time I’m happy to report that I’ve finally merged MinGW
>> cross-compilation support, woohoo!
>
> Yay, thanks Ludovic, Manolis and Mark!!!
Well, thank *you*! There were a lot of iterations on this patch series,
a lot of work, probably a lot of time waiting for compilations to finish
;-), and then a lot of time waiting for the thing to be finally merged.
>> I didn’t merge the cross-libtool patch and this one:
>>
>> Jan Nieuwenhuizen <address@hidden> skribis:
>>
>>> * gnu/packages/ncurses.scm (ncurses)[MINGW]: Build with libtool, as
>>> recommended; enables dlopen'ing.
>>
>> I’m not sure what this means (and the explanation should be as a comment
>> in the code). Could you explain a bit more?
>
> The ncurses README.MinGW says
>
> I recommend using libtool to build ncurses on MinGW, because libtool
> knows exactly how to build dll's on Windows for use with MinGW.
>
> and if you use libtool, it will generate .la files that are necessary
> to dlopen the DLLs.
>
>> The idea of Libtool is normally to bundle it in the package tarball.
>> That ncurses can optionally take an externally-provided Libtool is weird
>> and I’d rather avoid relying on that if possible.
>
> I agree; this is quite a trick silly setup, esp. using cross builds.
> I thought there was a better reason for doing this; that it was needed
> to build readline or use readline from guile.exe...I can't remember;
> we'll find out.
OK!
>> Adding a new cross-compilation target is a commitment. So I hope you
>> and others will make sure it remains functional and useful!
>
> Yes. There are two things I want to do next. I have another 10 patches
> bitrotting around that enable cross building LilyPond. I want to clean
> them up and merge them one by one. Also I'd like to look into deploying
> guile.exe on Wine/Windows; maybe this should be a first. I could do
> with some ideas here. Create packages that can be installed/unpacked,
> or port some minimal part of guix so that it can fetch and install
> binaries from the store?
When we have ‘guix pack’ (a generalization of “make
guix-binary.x86_64-linux.tar.xz”), that will be a simple way to transfer
a bunch of store items to a Windows box.
Besides, having a test that runs guile.exe in Wine could be useful.
(Though now that Windows implements the Linux syscalls we should make
sure the investment is worth it!)
Ludo’.