[Build-common-hackers] Bug#521872: Bug#521872: makefile-vars.mk clobbers LDFLAGS and others

Jonas Smedegaard dr at jones.dk
Mon Mar 30 21:10:24 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Martin,

On Mon, Mar 30, 2009 at 06:58:43PM +0200, Martin Pitt wrote:
>In https://launchpad.net/bugs/138981 it was reported that cdbs'
>makefile-vars.mk clobbers LDFLAGS/CFLAGS set by upstream makefiles.
>
>DEB_MAKE_INVOKE = $(DEB_MAKE_ENVVARS) $(MAKE) $(if $(DEB_MAKE_MAKEFILE), -f $(DEB_MAKE_MAKEFILE),) -C $(DEB_BUILDDIR) CFLAGS=$(if $(CFLAGS_$(cdbs_curpkg)),"$(CFLAGS_$(cdbs_curpkg))","$(CFLAGS)") CXXFLAGS=$(if $(CXXFLAGS_$(cdbs_curpkg)),"$(CXXFLAGS_$(cdbs_curpkg))","$(CXXFLAGS)") CPPFLAGS=$(if $(CPPFLAGS_$(cdbs_curpkg)),"$(CPPFLAGS_$(cdbs_curpkg))","$(CPPFLAGS)") LDFLAGS=$(if $(LDFLAGS_$(cdbs_curpkg)),"$(LDFLAGS_$(cdbs_curpkg))","$(LDFLAGS)")
>
>This is wrong, since if $LDFLAGS is not set in the environment, but in the
>upstream Makefiles, this ends up as
>
>  make LDFLAGS=""
>
>and thus upstream makefiles which only provide defaults (instead of 
>overriding) break.
>
>Patching this is obvious, the "LDFLAGS=" simply needs to be moved into 
>the conditional substitution, but I wouldn't like to change this in 
>Ubuntu without having it changed in Debian as well, to avoid toolchain 
>diversion.
>
>Thanks for considering,

Thanks for sharing and coordinating this issue across distros!

Hmm.  I see your point, but do not agree with your proposed solution: At 
least for automake, LDFLAGS is a user flag, so upstream (automade) 
makefiles are broken if they do not allow the user to set (or reset) 
that option.

Non-automake makefiles can off course do whatever they like, but a 
makefile allowing the user to change LDFLAGS but breaking when done is 
mildly broken IMO.

CDBS has been in production use for a long time, treating CFLAGS, 
CXXFLAGS and LDFLAGS similarly: Resetting user-options and reaplying 
both user-provided options and system-default options. Changing LDFLAGS 
to no longer clear might break existing packages, and also makes the use 
of the variable less intuitive as it no longer behaves similar to CFLAGS 
and CXXFLAGS.

New packages needing to preserve upstream flags can reinstate them.

With your proposed change, how would a package suppress an unwanted 
upstream LDFLAGS setting?


(the comment in your referenced Ubuntu bugreport about AM_LDFLAGS being 
similarly broken wroories me more: that is not a user flag, I 
believe...)


Please do try harder to convince us.  I do not claim to be an expert in 
make, and certainly not in C.


Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknRNUAACgkQn7DbMsAkQLg3hACaArD1ApThG1eQ4wprXf2tgXzH
msYAnAzNzPI0JCQ+H4Lk2e5iH7Lx2TOR
=4JJG
-----END PGP SIGNATURE-----





More information about the Build-common-hackers mailing list