From be73ea496657099603cce7e20413b9c6ee993c94 Mon Sep 17 00:00:00 2001 From: Mohammad Akhlaghi Date: Sun, 19 Jan 2020 21:15:37 +0000 Subject: 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'. --- reproduce/software/make/high-level.mk | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'reproduce/software/make/high-level.mk') 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 -- cgit v1.2.1