[oe] AAAARGH! openembedded..... pcmciautils. SOLVED!

[Paul Sokolovsky]

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 at 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 at gmail.com