Re: AAAARGH! openembedded..... pcmciautils. SOLVED!

Re: AAAARGH! openembedded..... pcmciautils. SOLVED!

[Michael 'Mickey' Lauer]

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

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

Dr. Michael 'Mickey' Lauer.

Re: 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@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

Re: AAAARGH! openembedded..... pcmciautils. SOLVED!

[Steve Sakoman]

TOP is another one to add to the list.   It will break openssl.

Steve

On Dec 15, 2007 7:55 AM, Paul Sokolovsky <pmiscml@gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: AAAARGH! openembedded..... pcmciautils. SOLVED!

[Richard Purdie]

On Sat, 2007-12-15 at 17:55 +0200, Paul Sokolovsky wrote:
> 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?

Bitbake reads all variables from the environment into its variable space
when run. Any variable loaded from the original environment are marked
as an export so it gets passed to executed tasks. More recently we added
an "unexport" flag so you could actually stop it from doing this in
cases known to cause problems (e.g. MACHINE). This is a long established
behaviour of bitbake and changing it would probably break the way people
use bitbake and break backwards compatibility.

Loading variables from the environment is a really useful feature which
I personally, Poky and I suspect others make heavy use of. It implies
you should have a relatively clean environment and perhaps that needs to
be more predominately documented.

Exporting those variables makes things more visible. Even if not
exported, we would still have potentially weird build failures for users
with dirty environments since it does affect the variable space quite
significantly.

So yes, bitbake could stop exporting all variables but it would just
hide more subtle problems rather than solving them.

In some cases we need to unexport. In the MACHINE case, setting from the
environment is useful but we need to stop it getting passed to the task
environment as it breaks things like binutils. In general I'd prefer the
bitbake environment init scripts sanity check or clean the environment
or something like sanity.bbclass could check for known bad exports and
error asking the user to fix their environment rather than just blindly
adding to the list of unexports...

Cheers,

Richard