windows improvements, mainly cross: linux -> mingw#14920
windows improvements, mainly cross: linux -> mingw#14920vcunat merged 23 commits intoNixOS:stagingfrom
Conversation
For every *.{exe,dll} in $output/bin/ we try to find all (potential)
transitive dependencies and symlink those DLLs into $output/bin
so they are found on invocation.
(DLLs are first searched in the directory of the running exe file.)
The links are relative, so relocating whole /nix/store won't break them.
The hook is activated on cygwin and when cross-compiling to mingw.
They seem not needed anymore.
In particular, this makes 64-bit libpng create DLL now, and thus depending packages won't fail anymore (e.g. freetype).
The whole expression is rather a mess, mainly due to upstream often behaving badly with non-standard configurations.
After closure-size merge we need to disable python support, as python upstream doesn't support cross-building linux -> mingw.
It's only static, as libxml2 is only static ATM.
Also clean up the expression a little. It fixes at least libpng's DLL.
By porting a patch from msys2.
lcms, openjpeg and curl don't seem to be so necessary.
The minimal version should be fine now.
The output gets rather large (67 MB) as *each* executable gets ~5 MB of magick stuff statically. It seems we would have to fix or disable libxml2 first to get around this blowup.
`concatMapStringsSep` actually needs a function to work on the list items, but it was probably a leftover from the refactor in af8654d. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Otherwise, Boost.Build is trying to compile against pthread and desperately searches for icu/iconv. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I guess the "set -x" was only left there for debugging, so I'm removing it because it let's the scrollback buffer explode ;-) Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The upstream sources only compile with masm, so we need to add a patch that translates the masm sources to GNU assembler. Unfortunately, this means, that "generic.nix" is no longer very much generic, but the versions we currently include work fine with the patch. Unfortunately, the boost build still doesn't finish, but we're getting there soon enough. The patch is from https://svn.boost.org/trac/boost/ticket/7262 and following the discussion it seems that the upstream authors are unwilling to add a gas version for the Windows platform. So in the long term we might need to find a better solution to that, like for example using Wine to run MASM. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Dynamic linking won't work, it seems. - When using a native python, the extension isn't built, so let's not depend on it. - Replace flags missing on this branch, such as `isCrossWin`.
- Dynamic linking won't work, it seems. - When using a native python, the extension isn't built, so let's not depend on it.
|
By analyzing the blame information on this pull request, we identified @wkennington, @edolstra and @copumpkin to be potential reviewers |
|
By analyzing mingw-related PRs, I identified @mcmtroffaes as potentially interested. @aszlig: I used some of your unmerged commits, but I suppose you're no longer interested in mingw... |
|
And perhaps /cc @chaoflow due to https://ternaris.com/lab/nix-on-windows.html, especially the stuff around finding DLLs. |
|
Hmm, this PR may worsen some stuff due to #14965, although probably not significantly except for mingw. |
This doesn't fix the cross-build by itself due to NixOS#14965 But in this case one can hack around that "easily" by: (html-tidy.override { inherit (/*non-cross nixpkgs eval*/) cmake; }).crossDrv
|
Thanks for all your work on this! I quite like the idea to autolink dll files. I've only inspected the bzip2 cross build patch in detail so far (as I worked on it previously). Instead of making the nix expression more complicated to handle all the oddities caused by the makefile which ships with bzip2, can't we use the upstream autoconf build system for all builds (cross and native)? In fact, once we had this in the repository: but this had to be reverted due to lack of https during bootstrap, and bzip2 is required during bootstrap. Here are the relevant pull requests: IIUC https support during bootstrap was added to nix a while ago (I failed right now to track down the relevant commit, so it would be good if someone else could confirm). If that's correct, then perhaps maybe now is a good time to revert back to the simpler nix expression for bzip2? |
|
Found the relevant commit that enables https during bootstrap: e6f61b4 |
|
I can see little advantage in applying a mingw-specific patch on other platforms. In particular, the added dependency on autotools would probably lengthen stdenv bootstrapping. |
|
The autotools patch isn't mingw specific; it originates from SUSE: http://ftp.suse.com/pub/people/sbrabec/bzip2/ and it just happens to fix most of the cross build issues too. I assumed that the current bootstrap process depended on autotools already, I apologize if that's not the case and of course I agree that it is better to keep the bootstrap dependencies as minimal as possible. |
|
Oh, I see, it might allow us to delete half of all those hacks. It is possible we have the autotools dependency in there already, I don't know, but it's probably worth it anyway. |
|
Exactly, the autotools patch allows us to remove almost all the ugly hacks. I'm not sure how to check whether we have autotools or not in the bootstrap. There is probably a very simple command that gives us the immediate answer to that question... I'll try to figure it out. In any case I certainly don't mean to hold up the whole effort, which I like very much. |
|
It's just an improvement atop, no hold-up really. |
The main point point of this is to make some particular packages cross-compile to mingw. I'll merge in a few days if there's noone interested.
A specific change that may be of interest is a kindof-replacement for RPATH on Windows: 6e7787e. It allows me to just
wine ./result-bin/bin/fooon dynamically linked binaries. I activated that hook for cygwin as well, although I have only tested it on cross: linux -> mingw.The linux non-cross stdenv is unchanged, but this PR is probably still a non-cross mass rebuild.
Things done
nix-build --option build-use-chroot trueor nix.useChroot on NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)