diff options
author | Raul Infante-Sainz <infantesainz@gmail.com> | 2022-06-11 11:00:10 +0200 |
---|---|---|
committer | Mohammad Akhlaghi <mohammad@akhlaghi.org> | 2022-06-11 15:23:27 +0200 |
commit | 23783ae38b3ae9ed768d3383eb2d56cc31ea8b20 (patch) | |
tree | 32c64e70c2dead1db616502c20544bb4a88470d0 /reproduce/config/gnuastro | |
parent | c148beb5eb4553711f6c75e23b94d976c40212a7 (diff) |
Configuration: replacing hard coded PATH in SCons
Until now, SCons (a high-level Python package builder) was using the OS
PATH when building packages (like Imfit that use SCons), not Maneage's
PATH. This happened even though 'reproduce/software/make/high-level.mk'
completely removes the host's PATH to avoid any host OS dependency.
After some investigation, we recognized that SCons hard-codes operating
system directories into its source! This doesn't let the user (Maneage in
this case; that builds packages that use SCons) customize the search
directories. As a result, even though we have our own linker and compiler
in Maneage, SCons would go and use the operating system's linker and
compiler, causing a leak in the controlled environment we plan to achieve
in Maneage. Not letting users customize such critical components of a
software and hard-coding parameters is bad program design!
This wasn't noticed until now because most operating systems we tested on
were relatively recent and the versions of Maneage's linker and the OS
linker weren't too different! However, after testing on a much older
operating system (GNU/Linux 4.4.0-143-generic X86_64), the operating
system's linker couldn't build Imfit (that uses SCons) and would crash.
With this commit, after unpacking SCons's source (but before building or
installing it), we have added a step to modify SCons's source and replace
the hard-coded PATH directories with Maneage's PATH. This fixed the
problem.
This bug has been fixed with the help of Mohammad Akhlaghi.
Diffstat (limited to 'reproduce/config/gnuastro')
0 files changed, 0 insertions, 0 deletions