Re: LDFLAGS going missing?

[Bernd Zeimetz]

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.


Bernd



-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F