xfsprogs: CFLAGS not passed in
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'\" ---
Quoted 1 line
with options \"\"
439c439
< set X '/bin/sh' './configure' '--prefix=/usr' 'CFLAGS=-
march=athlon64-sse3 -g -Os' $ac_configure_extra_args --no-create --no- recursion
---
Quoted 1 line
set X '/bin/sh' './configure' $ac_configure_extra_args --no-create
--no-recursion
488c488
< max_cmd_len='1572864'
---
Quoted 1 line
max_cmd_len='3458764513820540925'
507c507
< CFLAGS='-march=athlon64-sse3 -g -Os'
---
Quoted 1 line
CFLAGS='-g -O2'
591c591
< LTCFLAGS='-march=athlon64-sse3 -g -Os'
---
Quoted 1 line
LTCFLAGS='-g -O2'
717c717
< S["have_zipped_manpages"]="true"
---
Quoted 1 line
S["have_zipped_manpages"]="false"
835c835
< S["CFLAGS"]="-march=athlon64-sse3 -g -Os"
---
Quoted 1 line
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?
Signature · 13 lines
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/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Michael Monnerie
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_dumpproblem)" and this is a repost:
Quoted 8 lines
I tried to compile xfsprogs with the "CFLAGS":
CFLAGS="-march=athlon64-sse3 -g -Os" ./configure --prefix=/usrNo 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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Dave Chinner
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs