public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* xfsprogs: CFLAGS not passed in
@ 2010-07-22  6:21 Michael Monnerie
  2010-07-22 22:29 ` Dave Chinner
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Monnerie @ 2010-07-22  6:21 UTC (permalink / raw)
  To: xfs


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

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:

# diff config.status config.status.default
360c360                                                                 
<   with options \"'--prefix=/usr' 'CFLAGS=-march=athlon64-sse3 -g -
Os'\"
---
>   with options \"\"
439c439
<   set X '/bin/sh' './configure'  '--prefix=/usr' 'CFLAGS=-
march=athlon64-sse3 -g -Os' $ac_configure_extra_args --no-create --no-
recursion
---
>   set X '/bin/sh' './configure'  $ac_configure_extra_args --no-create 
--no-recursion
488c488
< max_cmd_len='1572864'
---
> max_cmd_len='3458764513820540925'
507c507
< CFLAGS='-march=athlon64-sse3 -g -Os'
---
> CFLAGS='-g -O2'
591c591
< LTCFLAGS='-march=athlon64-sse3 -g -Os'
---
> LTCFLAGS='-g -O2'
717c717
< S["have_zipped_manpages"]="true"
---
> S["have_zipped_manpages"]="false"
835c835
< S["CFLAGS"]="-march=athlon64-sse3 -g -Os"
---
> S["CFLAGS"]="-g -O2"


I even set all variables with "GCC" in config.status to random 
content, and it compiles. Then I found that the one in 
"include/builddefs" gets always set to this:
GCCFLAGS = -funsigned-char -fno-strict-aliasing -Wall

So I changed it manually:
GCCFLAGS = -march=athlon64-sse3 -g -Os -funsigned-char -fno-strict-
aliasing -Wall
and now the resulting binary is different. I guess that should not be 
happening? I'm used to setting "CFLAGS=" during configure to have 
smaller bins, and CFLAGS normally get passed through during compile, but 
not with xfsprogs. Maybe worth a fix?

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Aktuelles Radiointerview! ******
http://www.it-podcast.at/aktuelle-sendung.html

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: xfsprogs: CFLAGS not passed in
  2010-07-22  6:21 xfsprogs: CFLAGS not passed in Michael Monnerie
@ 2010-07-22 22:29 ` Dave Chinner
  2010-07-23  6:16   ` Christoph Hellwig
  0 siblings, 1 reply; 3+ messages in thread
From: Dave Chinner @ 2010-07-22 22:29 UTC (permalink / raw)
  To: Michael Monnerie; +Cc: xfs

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: xfsprogs: CFLAGS not passed in
  2010-07-22 22:29 ` Dave Chinner
@ 2010-07-23  6:16   ` Christoph Hellwig
  0 siblings, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2010-07-23  6:16 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Michael Monnerie, xfs

On Fri, Jul 23, 2010 at 08:29:00AM +1000, Dave Chinner wrote:
> The OPTIMIZER compile options are still included here, so there's
> potential conflict just by dumbly initialising CFLAGS....

Given that gcc always takes the latests of a set of conflicting option
just aqdding the flags from configure last should fix it.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-07-23  6:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-22  6:21 xfsprogs: CFLAGS not passed in Michael Monnerie
2010-07-22 22:29 ` Dave Chinner
2010-07-23  6:16   ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox