This is because autoconf is passing -print-prog-name=ld to the
cross-gcc, which in turn assumes a FHS compliant filesystem hierarchy
and searches ../../../../$crossConfig/bin/ld for the correct ld.
Of course, this won't work on Nix, hence we're explicitly passing the
correct LD program name.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This adds a new function in vmTools, called runInWindowsVM, which allows
to run a derivation within a Windows + Cygwin environment.
To use it, you need to pass a Windows ISO and product key, for example:
------------------------------------------------------
vmTools.runInWindowsVM (stdenv.mkDerivation {
name = "hello-from-windows";
windowsImage = {
isoFile = /path/to/windows/image.iso;
productKey = "ABCDE-FGHIJ-KLMNO-PQRST-UVWXY";
};
buildCommand = ''
echo 'Look, I am running inside Windoze!'
uname -a > "$out"
'';
})
------------------------------------------------------
The derivation is then run within a special build process, which roughly
does something like this:
____________
| |
| controller |
|____________|
/ | \
_________ / ____|____ \___________ _______
| | | | | | | |
| install | -> | suspend | -> | suspended | -> | build |
|_________| |_________| |___________| |_______|
There are three steps necessary to produce the builder, which in the end
is just a suspended Windows VM, running Cygwin and OpenSSH.
Those steps are essentially:
* install: Install the base Windows VM with Cygwin and OpenSSH.
* suspend: Run the installed VM and dump the memory into a state file.
* suspended: Resume from the state file and execute the build.
Every build is based on the "suspended" step, which throws away all
changes except to the resulting output store path(s).
All of these steps are based on the controller, which is described in
greater detail in commit 276b72fb93.
The reason I'm merging this right in is because it actually adds a
feature that doesn't break existing functionality and only hooks into
vmTools with a single line.
To the contrary it even duplicates a bit of the code from vmTools, which
might be a good start for refactoring. I didn't do that within that
branch, because it otherwise *could* break existing functionality - VM
tests in particular.
Also, this implementation currently *only* supports Windows XP, because
the implementation was originally made for building a Software where the
majority of the users are using Windows XP and we need to do extensive
testing on that platform.
However, adding support for more recent versions is rather trivial. All
there needs to be done is adding a new unattended installation config in
unattended-image.nix.
Also update 64bit setup.ini and check whether we have a 64 bit stdenv in
order to choose the proper Cygwin version. Otherwise we now have the
setup.ini for 32bit available as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Matthew Sackman