Re: xfsprogs-5.2.0 FTBFS: ../libxfs/.libs/libxfs.so: undefined reference to `xfs_ag_geom_health'

Thomas Deutschmann
2019-08-13T13:52:45Z

[-- Attachment #1.1: Type: text/plain, Size: 3899 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]