public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Thomas Deutschmann <whissi@gentoo.org>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: xfsprogs-5.2.0 FTBFS: ../libxfs/.libs/libxfs.so: undefined reference to `xfs_ag_geom_health'
Date: Tue, 13 Aug 2019 11:04:47 +1000	[thread overview]
Message-ID: <20190813010447.GE6129@dread.disaster.area> (raw)
In-Reply-To: <ddabd271-2820-85f3-4393-99deb5a0eaef@gentoo.org>

On Tue, Aug 13, 2019 at 12:18:04AM +0200, Thomas Deutschmann wrote:
> On 2019-08-12 23:44, Dave Chinner wrote:
> >> That's not the correct way to reproduce. It's really important to
> >> _export_ the variable to trigger the problem and _this_ is a problem in
> >> xfsprogs' build system.
> > Which means you are overriding the LDFLAGS set by configure when
> > you _run make_, not just telling configure to use those LDFLAGS.
> > 
> > That's why _make_ is getting screwed up - it is doing exactly what
> > you are telling it to do, and that is to overrides every occurrence
> > of LDFLAGS with your exported options rather than using the correct
> > set configure calculated and specified.
> > 
> > Exporting your CFLAGS and LDFLAGS is the wrong thing to doing
> > - they should only ever be passed to the configure invocation and
> > not remain to pollute the build environment after you've run
> > configure.
> 
> I disagree with the conclusion. LDFLAGS in build environment shouldn't
> cause any problems, especially when you are using a build system:
>
> 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.

> So you either use a build system or you don't.

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.... :/

Just pass your special CFLAGS/LDFLAGS to configure like the rest of
the world does and everything will work correctly.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2019-08-13  1:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-11 13:06 xfsprogs-5.2.0 FTBFS: ../libxfs/.libs/libxfs.so: undefined reference to `xfs_ag_geom_health' Thomas Deutschmann
2019-08-11 22:53 ` Dave Chinner
2019-08-11 23:30   ` Thomas Deutschmann
2019-08-12  0:23     ` Dave Chinner
2019-08-12  1:21       ` Thomas Deutschmann
2019-08-12  3:11         ` Dave Chinner
2019-08-12  4:30           ` Dave Chinner
2019-08-12 10:57             ` Thomas Deutschmann
2019-08-12 16:34               ` Eric Sandeen
2019-08-12 22:03                 ` Dave Chinner
2019-08-12 21:44               ` Dave Chinner
2019-08-12 22:18                 ` Thomas Deutschmann
2019-08-13  1:04                   ` Dave Chinner [this message]
2019-08-13 13:52                     ` Thomas Deutschmann
2019-08-14  3:42                       ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190813010447.GE6129@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=whissi@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox