LIBRARY_PATH is set accordingly based on the host

Until now, GCC wouldn't build properly on Debian-based operating systems
because `ld' needed to link with several necessary C library features like
`crti.o' and `crtn.o' (this is an `ld' issue, not GCC). The solution is to
add the directory containing them to `LIBRARY_PATH'. In the previous
commit, I actually searched for these files, but while testing on another
system, I noticed that it can be problematic (other architectures may
exist).

With this commit, we are actually finding the build architecture of the
running GCC (which is the same as the `ld') and using that to fix a fixed
directory to `LIBRARY_PATH'.

1 files changed, 7 insertions, 0 deletions

diff --git a/reproduce/software/make/high-level.mk b/reproduce/software/make/high-level.mk
index 735a24a..0afeaba 100644
--- a/reproduce/software/make/high-level.mk
+++ b/reproduce/software/make/high-level.mk
@@ -84,6 +84,13 @@ export PKG_CONFIG_LIBDIR := $(ildir)/pkgconfig
 # causes crashs (see bug #56682). So we'll just give it no value at all.
 export DYLD_LIBRARY_PATH :=
 
+# On Debian-based OSs, the basic C libraries are in a target-specific
+# location, not in standard places. Until we merge the building of the C
+# library, it is thus necessary to include this location here. On systems
+# that don't need it, `sys_library_path' is just empty. This is necessary
+# for `ld'.
+export LIBRARY_PATH := $(sys_library_path)
+
 # Recipe startup script, see `reproduce/software/bash/bashrc.sh'.
 export PROJECT_STATUS := configure_highlevel
 export BASH_ENV := $(shell pwd)/reproduce/software/bash/bashrc.sh