Opened 10 years ago
Closed 7 months ago
#46432 closed defect (wontfix)
scons messes up the environment and removes ${prefix}/bin from $PATH
Reported by: | jeremyhu (Jeremy Huddleston Sequoia) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | Cc: | ||
Port: | scons |
Description
scons messes up the environment in processes it spawns.
Most horrifically, it messes up $PATH, removing ${prefix}/bin. This can cause it to not find the correct tools when it does things like executing install-name-tool to workaround other horrific design decisions in the build system (specifically, not setting the dylib id at link time).
---
I verified that the environment was this in pre_destdir:
TMPDIR=/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/.tmp NO_PROXY=*.local,169.254/16 USER=root CCACHE_DIR=/opt/local/var/macports/build/.ccache COLUMNS=164 PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin PWD=/opt/local/var/macports LANG=en_US.UTF-8 LINES=45 SHLVL=1 HOME=/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/.home _=/usr/bin/env
But when scons executed install-name-tool, it picked it up from /usr/bin instead of /opt/local/bin, and this was the path in that process (I replaced /usr/bin/install-name-tool with a shell script to verify this):
PATH=/opt/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin _=/usr/bin/env PWD=/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/serf-1.3.4 PATHOSX=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin SHLVL=2
This pretty much prevents the scons build system from being used with modern toolchains on older systems because older install-name-tool will fail like:
scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... Install file: "libserf-1.a" as "/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.a" Install file: "libserf-1.1.3.4.dylib" as "/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib" install_name_tool -id /opt/local/lib/libserf-1.dylib /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib install_name_tool: for architecture x86_64 object: /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib malformed object (unknown load command 7)
Change History (4)
comment:1 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:2 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | changed from landonf@… to macports-tickets@… |
---|
comment:3 Changed 8 years ago by larryv (Lawrence Velázquez)
I’ve updated scons
to 2.5.1. Is this still an issue?
comment:4 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
It is an intentional misfeature of scons that it does not inherit the environment of the calling process. It is up to the author of each SConscript or SConstruct file to import the environment variables that they want to import.
https://scons.org/doc/latest/HTML/scons-user/ch07s03.html
For this any many other reasons, I recommend all projects move from scons to any other build system.
Some of this mess is the fault of serf1's Sconstruct file, but the PATH issue seems to be from scons itself and not serf-specific bits.