On Thu, Aug 20, 2020, 12:50 PM Bernd Zeimetz <
bernd@bzed.de> wrote:
On 8/19/20 3:56 PM, Greg Troxel wrote:
>
> I have updated pkgsrc to 3.21. Someone in pkgsrc-land tried to build
> with the hardening technique RELRO, which pkgsrc supports and most
> packages are ok with:
I had the same issue in Debian, but I thought I had fixed those issues with
commit d0e0864c2802860ff561fe0b39939b63d38b8c70
Author: Bernd Zeimetz <bernd@bzed.de>
Date: Sun Jul 28 20:46:35 2019 +0200
Fix the handling of defaults from the environment.
The way whis was handled before had various issues:
- scons' naming scheme for compiler flags is different from what we know
from autotools and (afaik) all other build systems. As it seems to
filter flags (or they are listed in the wrong environment variable and
not used at the appropriate time), most of them get lost. So far I have
not seen builds to fail becase of that.
- to make sure flags end up in the appropriate setting, use
env.MergeFlags for *FLAGS. This works well for me, but might break
special CXX/CCFLAGS settings. So far I was not able to find a better way
to handle this.
- the lower/original MergeFlags part did not work at all as
for flag in ....:
if i in os.eviron:
does not depend on the flag to be checked, but on the last checked flag
from the loop before, where i was used. As TAR is usually not in the
environment, this code was propably always dead.
- the LD/SHLINK switch was done the wrong way around and was never able
to work at all.
tl;dr: the number of newly broken things is for sure less than the
number of things that actually never worked before.
Similar issues seems to exist in the part of the code where Python build
configs are merged into the python env....
What I'm doing in debian/rules is
cflags := $(shell dpkg-buildflags --get CFLAGS)
cppflags := $(shell dpkg-buildflags --get CPPFLAGS)
cxxflags := $(shell dpkg-buildflags --get CXXFLAGS)
ldflags := $(shell dpkg-buildflags --get LDFLAGS)
SCONS_ENV := set -e ;\
export LDFLAGS="$(ldflags)" ;\
export CFLAGS="$(cflags)" ;\
export CXXFLAGS="$(cxxflags)" ;\
export CPPFLAGS="$(cppflags)";
...
$(SCONS_ENV) $${py} /usr/bin/scons $(SCONSOPTS) target_python=$${py}
So I've exported all flags - maybe this helps?
Probably scons is messing with the environment somewhere internally?
> I haven't been able to figure out in SConstruct why there are two builds
> (smells like the libtool relink before install to allow testing with not
> isntalled libs?), and more importantly why user-specified LDFLAGS are
> ignored.
So far this works as expected in 3.20. Did not yet give 3.21 a try.
My impression from looking at the (ick) CVS log of pkgsrc is that Greg was working from 3.21. I was able to replicate the issue post 3.21 with a two line example. I do not see anything post 3.21 that remotely looks like it addresses the issue.
AFAIK neither of us was exporting any flags.