From: Bernhard Fischer <rep.dot.nop@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS)
Date: Sat, 7 Jul 2007 15:01:32 +0200 [thread overview]
Message-ID: <20070707130132.GU4096@aon.at> (raw)
In-Reply-To: <000201c7c087$9e70d0a0$dcc4af0a@atmel.com>
On Sat, Jul 07, 2007 at 12:06:09PM +0200, Ulf Samuelsson wrote:
>>> * Update mtdutils (which is really old)
>>>
>> Please do not check in changes to this until running the patch by
>> me. This package is critical for a lot of embedded systems and has
>> been working well up to this point and there are no bugs in the
>> bug tracker.
>>
>
>Before looking at introducing my new version (as an option)
>I tried rebuilding the current svn and ran into a problem with mtd.
>
>When building for arm, the target mtdutils are built using the *host* compiler
>and stored in $(TARGET_DIR)/usr/sbin.
>
>When the arm-linux-uclibc-strip is invoked on
>"$(TARGET_DIR)/usr/sbin/flash_erase"
>compiled by gcc (not arm-linux-uclibc-gcc), the make fails.
>
>I think someone got it wrong in the "package/mtd/mtd.mk" which says
>
> $(TARGET_CONFIGURE_OPTS) $(MAKE) ... - build using gcc
>
>which should be:
>
> $(MAKE) $(TARGET_CONFIGURE_OPTS) ... - build using arm-linux-uclibc-gcc
yes, the latter is correct. Steven, please repair or elaborate.
Also, not using the user's CFLAGS sound a little bit odd to me, given
that after your change a package will *not* use the proper flags
anymore.
Think about a package that has
CFLAGS = -O2 -fother-bloat
in it's makefile. Now you changed it to be compiled as
myarch-linux-uclibc-gcc -Os $USERFLAGS -O2 -fother-bloat
which will end using -O2 rather than the correct -Os
Previously we were overriding the package imposed default CFLAGS, which
is the proper thing to do, IMO.
What was the rational behind your change? TIA for elaborating..
next prev parent reply other threads:[~2007-07-07 13:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-06 12:35 [Buildroot] What is the proper procedure to commit a patch? Ulf Samuelsson
2007-07-06 15:26 ` Bernhard Fischer
2007-07-06 15:36 ` Ulf Samuelsson
2007-07-07 10:12 ` Bernhard Fischer
2007-07-07 11:16 ` Ulf Samuelsson
2007-07-07 12:35 ` Bernhard Fischer
2007-07-07 13:46 ` Ulf Samuelsson
2007-07-06 15:55 ` Steven J. Hill
2007-07-06 21:10 ` Ulf Samuelsson
2007-07-07 10:06 ` [Buildroot] $(TARGET_CONFIGURE_OPTS) $(MAKE) vs $(MAKE) $(TARGET_CONFIGURE_OPTS) Ulf Samuelsson
2007-07-07 13:01 ` Bernhard Fischer [this message]
2007-07-07 16:06 ` Ulf Samuelsson
2007-07-07 17:29 ` Bernhard Fischer
2007-07-07 19:37 ` Ulf Samuelsson
2007-07-07 21:16 ` Bernhard Fischer
2007-07-07 22:49 ` Ulf Samuelsson
2007-07-09 8:25 ` Bernhard Fischer
2007-07-09 9:21 ` Bernhard Fischer
2007-07-09 12:20 ` Steven J. Hill
2007-07-09 13:41 ` Julien Letessier
2007-07-09 13:08 ` Ulf Samuelsson
2007-07-09 16:33 ` Bernhard Fischer
2007-07-10 11:51 ` Julien Letessier
2007-07-10 18:24 ` Bernhard Fischer
2007-07-07 10:21 ` [Buildroot] What is the proper procedure to commit a patch? Bernhard Fischer
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=20070707130132.GU4096@aon.at \
--to=rep.dot.nop@gmail.com \
--cc=buildroot@busybox.net \
/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