From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
Subject: xfsprogs: CFLAGS not passed in
Date: Thu, 22 Jul 2010 08:21:39 +0200
User-Agent: KMail/1.12.4 (Linux/2.6.34.1-zmi; KDE/4.3.5; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart2768252.boLvVLKaT8";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201007220821.44314@zmi.at>

--nextPart2768252.boLvVLKaT8
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I saw Christian Kujau's report yesterday with a quick fix, so maybe my=20
reports of a similar problem have been missed in the thread "rsync and=20
corrupt inodes (was xfs_dump problem)" and this is a repost:

I tried to compile xfsprogs with the "CFLAGS":
CFLAGS=3D"-march=3Dathlon64-sse3 -g -Os" ./configure --prefix=3D/usr

No matter what I use for CFLAGS, the resulting binary repair/xfs_repair=20
is always the same. So it seems to be ignored during compile anyway.=20
Smells like a bug? Because config.status gets the CFLAGS set, it's just=20
not used during compile. Comparing a "config.status" with CFLAGS set and=20
without:

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


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

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

=2D-=20
mit freundlichen Gr=C3=BCssen,
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=C3=A4user zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

--nextPart2768252.boLvVLKaT8
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEABECAAYFAkxH43gACgkQzhSR9xwSCbQSLQCff93XuIPXI0nncQzEG9iS7p2Z
mSsAoI0Gh2F3PbjWXnGErzPKNepqELqO
=60Sz
-----END PGP SIGNATURE-----

--nextPart2768252.boLvVLKaT8--