On 2019-08-13 03:04, Dave Chinner wrote: >> Normally, configure will get the value and the Makefiles will use the >> value _from_ configure... but using configure _and_ reading _and adding_ >> values from environment _in addition_ seems to be wrong. > > <sigh> > > xfsprogs-2.7.18 (16 May 2006) > - Fixed a case where xfs_repair was reporting a valid used > block as a duplicate during phase 4. > - Fixed a case where xfs_repair could incorrectly flag extent > b+tree nodes as corrupt. > - Portability changes, get xfs_repair compiling on IRIX. > - Parent pointer updates in xfs_io checker command. > - Allow LDFLAGS to be overridden, for Gentoo punters. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Back in 2006 we added the ability for LDFLAGS to be overriden > specifically because Gentoo users wanted it. Well, you got us :-) Sorry, I wasn't around 2006 and don't know all details. Looks like commit https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=4d32d744f07ce74abac7029c3ee7c6f5e4238d25 caused that changelog entry. The request itself, that user should be able to overwrite CFLAGS/LDFLAGS, is valid. However, I haven't check implementation yet and I guess that it was implemented the wrong way: It was and it still is a common problem that people do autotools wrong when it comes to CFLAGS/LDFLAGS handling. I.e. project should define two values: - Initial CFLAGS/LDFLAGS in case user didn't provide these flags. However, this value will be _overwritten_ when user provided these flags - Additional, required general flags. This value will get appended to previous value. Autotools will now define one single variable containing these two values which should be used. If you are now going to link against an additional dependency you will set CFLAGS/LDFLAGS just for this component which usually starts with the variable from above (=the general CFLAGS/LDFLAGS variable) but will usually contain component specific CFLAGS/LDFLAGS in addition (for example when linking against a library which will provide pkg-config file you will import lib specific CFLAGS/LDFLAGS). Sorry if this will sound like I am teaching you something. I guess you all know that (and probably far better than me). Back to xfsprogs: When you pass your default CFLAGS/LDFLAGS to configure and different to make, i.e. CFLAGS="-O2 -pipe -march=ivybridge -mtune=ivybridge -mno-xsaveopt -frecord-gcc-switches" \ LDFLAGS="-Wl,-O1 -Wl,--as-needed" \ ./configure and CFLAGS="-O2 -pipe -march=native" \ LDFAGS="-Wl,-fno-lto" \ make V=1 you will see > /bin/bash ../libtool --quiet --tag=CC --mode=link gcc -o mkfs.xfs -Wl,-fno-lto -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -static-libtool-libs proto.o xfs_mkfs.o ../libxfs/libxfs.la ../libxcmd/libxcmd.la ../libfrog/libfrog.la -lrt -lpthread -lblkid -luuid So we still have 3x "-Wl,-O1 -Wl,--as-needed" which is LDFLAGS value passed to configure. LDFLAGS from environment is only picked up once (which is still wrong). > Yup, but Gentoo wanted it both ways, and so we gave them that > capability. And now you're complaining that Gentoo users can shoot > themselves in the foot with it.... :/ Where is that coming from? From reading a few bugs from that time in Gentoo and reading our ebuild sources I can say that we were already using autotools for xfsprogs. So it looks like xfsprogs was facing the problem I mentioned in the beginning. To make it clear: Makefile should only use configure values (which isn't the case at the moment) and configure should of course honor environment variables (which it already does). -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Attachment:
signature.asc
Description: OpenPGP digital signature
