When using worktrees or submodules, you'll see a `.git' plain text file
at the root of your working tree instead of the usual `.git' directory.
This plain text file will point to the real GIT_DIR, under the
GIT_COMMON_DIR. From experimentation, the full GIT_COMMON_DIR is
required to exist for operations such as git-archive(1), so we expose it
as readonly inside the container.
Any -O argument will enable optimizations in GNU ld. We can use -O2
here, as this matches our compile flags. Note that this would also
enable additional optimizations if using the lld or gold linkers,
when compared to -O0.
The libtool unsorted 'find' determinism issue seemed to have been solved
in gcc-9's git: d41cd173e23ebea7c758644d6ad6e0fde1c2e3a6 or SVN: r262451
Furthermore, it seems that Ubuntu Focal 20.04 LTS is going to ship with
gcc 9 and mingw-w64 7, which will match what we have now.
-----
A note on this:
Careful observers will see that previously I stated that all released
versions of gcc were bootstrapped with a libtool 2.2.7a, meaning that
they all had the unsorted 'find' determinism issue first resolved in
libtool 2.2.7b.
However, I was mistaken, gcc's ltmain.sh CLAIMS it was generated by
libtool 2.2.7a, but it was in fact edited manually. It seems that gcc
maintains their own versions of ltmain.sh and libtool.m4, and only
sometimes backports patches from upstream.
Quite confusing.
This is no longer needed after 3bef7c22 in the mingw-w64 git repository,
which is first included in mingw-w64 v7.0.0.
As of the previous bump to our Guix time machine, we now use mingw-w64
v7.0.0.
Most of the mingw-w64 toolchain changes have now been upstreamed, we can
point to a commit that exists upstream.
NOTE: I'm not changing the URL yet until we see that Guix upstream will
accept all my patches for macOS.
-----
The Guix tree that's referred to by this commit contains the following
changes relevant to our mingw-w64 build:
b066c25026
Adds a PACKAGES-WITH-*PATCHES procedure which we can use in the future
to apply patches to packages if those patches are not considered
appropriate to upstream Guix
4719b71572
Adds mingw-w64 (the libc itself) reproducibility patches, taken from
debian.
79825bee07 + 401d28e433 + c1c50cb5b0
Add mingw-w64 specific binutils patches, taken from debian.
Specifically, the "Make DLL import libraries reproducible" patch made
libbitcoinconsensus.dll.a build reproducibly. The followup commits
were hotfixes for my mistakes.
0f864175dc
Bumps mingw-w64 to v7.0.0. This is the first release that enables
secure APIs by default (which we need), and gains _FORTIFY_SOURCE
support. This will also be what Ubuntu Focal 20.04 LTS releases with.
cdf00cf75d
Bumps NSIS to v3.05. This is the first release that includes a fix for
a reproducibility bug found by some of the electrum developers. See
details here: https://sourceforge.net/p/nsis/bugs/1230/
This bump will includes a couple of commits which improve the
reproducibility of the mingw-w64 toolchain. Most of which came from
debian. They will be upstreamed as upstream Guix release timeline
allows.
- Add "--no-insert-timestamp" LDFLAG for x86_64-w64-mingw32 builds
"The option --no-insert-timestamp can be used to insert a zero value for
the timestamp, this ensuring that binaries produced from identical
sources will compare identically." - ld(1)
- Set "SetDateSave off" in NSIS script
From https://nsis.sourceforge.io/Docs/Chapter4.html#flags
"This command sets the file date/time saving flag which is used by the
File command to determine whether or not to save the last write date and
time of the file, so that it can be restored on installation. Valid
flags are 'on' and 'off'. 'on' is the default."
- Add commented out NSIS options for reproducibility debugging in NSIS
script
- Make ZIPs deterministic by reseting file modification times to
SOURCE_DATE_EPOCH using touch(1) (Reference:
https://reproducible-builds.org/docs/archives/)
Previously, Guix would produce a gcc which did not know to use the SSP
function from glibc, and required a gcc make flag for it to do so, in my
attempt to fix it upstream I realized that this is no longer the case.
This can be verified by performing a Guix build and doing
readelf -s ... | grep __stack_chk
to check that symbols are coming from glibc, and doing
readelf -d ... | grep NEEDED | grep ssp
to see that libssp.so is not being depended on
- store_path() previously only worked for cross compilation packages, we
remove this assumption here
- Add CROSS_GCC_LIB variable which points to where gcc libs/headers are
located
- Add gcc libs/headers to our CROSS_*_PATH environment variables
- Check that all directories in CROSS_*_PATH are sane
- Clearer and more accurate prose
- Pin `guix pull' to commit rather than branch
- Just use `use-module' instead of `define-module'
- Use `bash-minimal' instead of `bash'
- Remove unneeded `tcsh' from manifest
- Explicitly use `python-3.7'
- Add comments about how {native,cross}-toolchains are produced and
why
