xfs
[Top] [All Lists]

Re: xfsprogs: CFLAGS not passed in

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: xfsprogs: CFLAGS not passed in
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 23 Jul 2010 08:29:00 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <201007220821.44314@xxxxxx>
References: <201007220821.44314@xxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Thu, Jul 22, 2010 at 08:21:39AM +0200, Michael Monnerie wrote:
> I saw Christian Kujau's report yesterday with a quick fix, so maybe my 
> reports of a similar problem have been missed in the thread "rsync and 
> corrupt inodes (was xfs_dump problem)" and this is a repost:
> 
> I tried to compile xfsprogs with the "CFLAGS":
> CFLAGS="-march=athlon64-sse3 -g -Os" ./configure --prefix=/usr
> 
> No matter what I use for CFLAGS, the resulting binary repair/xfs_repair 
> is always the same. So it seems to be ignored during compile anyway. 
> Smells like a bug? Because config.status gets the CFLAGS set, it's just 
> not used during compile. Comparing a "config.status" with CFLAGS set and 
> without:

Yup, include/builddefs.in needs a line at the top something like:

CFLAGS = @CFLAGS@

To initialise CFLAGS to whatever configure decided it should be.
However, the way the flags are build in builddefs means that more
work than this is needed to allow the CFLAGS env variable to
override all the compile options that get added together....

e.g:

$ CFLAGS="-Os" ./configure
....
$ make Q=
....
gcc -MM -Os -I. -g -O2 -DNDEBUG -DVERSION=\"3.1.2\" -DLOCALEDIR=.....
....

The OPTIMIZER compile options are still included here, so there's
potential conflict just by dumbly initialising CFLAGS....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>