public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: xfsprogs: CFLAGS not passed in
Date: Thu, 22 Jul 2010 08:21:39 +0200	[thread overview]
Message-ID: <201007220821.44314@zmi.at> (raw)


[-- 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

             reply	other threads:[~2010-07-22  6:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-22  6:21 Michael Monnerie [this message]
2010-07-22 22:29 ` xfsprogs: CFLAGS not passed in Dave Chinner
2010-07-23  6:16   ` Christoph Hellwig

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=201007220821.44314@zmi.at \
    --to=michael.monnerie@is.it-management.at \
    --cc=xfs@oss.sgi.com \
    /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