From: Paul Sokolovsky <pmiscml@gmail.com>
To: Carsten Haitzler <raster@openmoko.org> (The Rasterman)
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: AAAARGH! openembedded..... pcmciautils. SOLVED!
Date: Sat, 15 Dec 2007 17:55:05 +0200 [thread overview]
Message-ID: <316414004.20071215175505@gmail.com> (raw)
In-Reply-To: <1910714040.20071215125524@vanille-media.de>
Hello Michael,
Saturday, December 15, 2007, 1:55:24 PM, you wrote:
> [Sorry, TOFU alarm. NOTE: Cross-posted: please watch your replies]
> Well spotted! Congrats :)
> Fwiw, I've forwarded your mail to
> openembedded-devel@lists.openembedded.org, since I think you got a
> valid point here.
>> note - it's running yes - then the compile line - yes just spews out its cmd
>> line args ad-infinitum to OE's log files - filling my disk
Bwa-ha-ha! This is really worth recording in OE's hall of curiosities!
Btw, recently I caught export issue for TARGET_ARCH too, and looking
at the unexport list we have already:
# Make sure MACHINE isn't exported
# (breaks binutils at least)
bb.data.delVarFlag('MACHINE', 'export', d)
bb.data.setVarFlag('MACHINE', 'unexport', 1, d)
# Make sure TARGET_ARCH isn't exported
# (breaks Makefiles using implicit rules, e.g. quilt, as GNU make has this
# in them, undocumented)
bb.data.delVarFlag('TARGET_ARCH', 'export', d)
bb.data.setVarFlag('TARGET_ARCH', 'unexport', 1, d)
# Make sure DISTRO isn't exported
# (breaks sysvinit at least)
bb.data.delVarFlag('DISTRO', 'export', d)
bb.data.setVarFlag('DISTRO', 'unexport', 1, d)
Thought about this too:
>> any good reason OE doesn't entirely clear ALL
>> environment variables from the user EXCEPT ones known to be desirable on build
>> so you have a clean and fresh environment that is known and fixed?
>> ok.
>> i need to vent.
>> pmccia utils - have never built for me. it has ONLY succeeded in doing 1 thing.
>> filling up my disk with multi-GB log files.
>> i found out why now.
>> from the pcmciautils Makefile:
>> .c.o:
>> $(QUIET) $(CC) $(CFLAGS) -c -o $@ $<
>> from the build log:
>> make[1]: Entering directory
>> `/home/raster/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/pcmciautils-014-r1/pcmciautils-014'
>> Building ccdv yes ccache arm-angstrom-linux-gnueabi-gcc -march=armv4t
>> -mtune=arm920t
>> -I/home/raster/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/pcmciautils-014-r1/pcmciautils-014/src
>> -isystem/home/raster/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/include
>> -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -c -o
>> src/pccardctl.o src/pccardctl.c ccache arm-angstrom-linux-gnueabi-gcc
>> -march=armv4t -mtune=arm920t
>> -I/home/raster/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/pcmciautils-014-r1/pcmciautils-014/src
>> -isystem/home/raster/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/include
>> -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -c -o
>> src/pccardctl.o src/pccardctl.c ccache arm-angstrom-linux-gnueabi-gcc
>> -march=armv4t -mtune=arm920t
>> -I/home/raster/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/pcmciautils-014-r1/pcmciautils-014/src
>> -isystem/home/raster/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/include
>> -fexpensive-opti
>> note - it's running yes - then the compile line - yes just spews out its cmd
>> line args ad-infinitum to OE's log files - filling my disk
>> why this?
>> well my environment had QUIET=yes set:
>> [ 3:15PM
>> ~/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/pcmciautils-014-r1/temp
>> env | grep QUIET QUIET=yes
>> why? well /etc/init.d/rc's environment is inherited by users when they log in
>> as it spawns dameons/processes that handle logins:
>> # Should we also output to the console?
>> # /proc won't be mounted if we don't have an initramfs, but then we're
>> # dealing with custom systems so it's their own fault that they'll get
>> # output from rcS
>> if grep -w -q quiet /proc/cmdline 2>/dev/null; then
>> QUIET=yes
>> else
>> QUIET=no
>> fi
>> export QUIET
>> (from /etc/init.d/rc).
>> a harmless environment variable of "QUIET=yes" broke the build. it's taken me a
>> while to track this down. any good reason OE doesn't entirely clear ALL
>> environment variables from the user EXCEPT ones known to be desirable on build
>> so you have a clean and fresh environment that is known and fixed?
>> anyway. pcmciautils built now. i can finally build myself an os image. woot.
--
Best regards,
Paul mailto:pmiscml@gmail.com
next prev parent reply other threads:[~2007-12-15 15:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071215151907.d0e45e41.raster@openmoko.org>
2007-12-15 11:55 ` AAAARGH! openembedded..... pcmciautils. SOLVED! Michael 'Mickey' Lauer
2007-12-15 15:55 ` Paul Sokolovsky [this message]
2007-12-15 18:11 ` Steve Sakoman
2007-12-16 10:23 ` Richard Purdie
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=316414004.20071215175505@gmail.com \
--to=pmiscml@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=raster@openmoko.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.