different hosts, different OE images

different hosts, different OE images

[Filippo Basso]

Hi,

    here is another developer jumped into the world of OE... Wow! really
amazing tool...!


Anyway, today I got into a strange behaviours that depends on the
machine on which I'm bitbakin' (a debian testing/lenny and a debian
stable/etch on vmware).
I understood that the results should be highly independent from host
system, so I begun debugging a bit.

So, I luckily (!) got also into a difference that lead me to a
compile/non-compile, much easier to debug. On a angstrom-2007.1 and i586
architecture, I added "minimo" web-browser and I got that with the same
identical OE installation it compiles on my machine and fails compiling
in my vmware.



2 new points are now in my debug log:

1st point - (one of these "I want to understand why...")
in general, quite all the files "run.do_configure.xxx" or similar are
not sorted in the same way; definitions of environment variables are in
different order, depending on the system... is it normal?

2nd point - (one that let me thing "is this a bug...?")
in mozilla minimo webbrowser (minimo-1_0.02+cvs20070626-r0) the
log.do_compile is strange:

***debian etch***
    ....
    ccache gcc -o host_xpidl
-isystem/home/nbt/OSSTBOX/trunk/oe/build-nbt-crownbeach/tmp/staging/i586-angstrom-linux/include
-fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os
-DXP_UNIX -O3 
-I/home/nbt/OSSTBOX/trunk/oe/build-nbt-crownbeach/tmp/staging/i586-angstrom-linux/include/libIDL-2.0
-I/home/nbt/OSSTBOX/trunk/oe/build-nbt-crownbeach/tmp/staging/i586-angstrom-linux/include/glib-2.0
-I/home/nbt/OSSTBOX/trunk/oe/build-nbt-crownbeach/tmp/staging/i586-angstrom-linux/lib/glib-2.0/include
-DMDCPUCFG=\"md/_linux.cfg\"  host_xpidl.o host_xpidl_idl.o
host_xpidl_util.o host_xpidl_header.o host_xpidl_typelib.o
host_xpidl_doc.o host_xpidl_java.o ../../../dist/host/lib/libhostxpt.a
-L/home/nbt/OSSTBOX/trunk/oe/build-nbt-crownbeach/tmp/staging/i586-angstrom-linux/lib
-lIDL-2 -lglib-2.0
   
/home/nbt/OSSTBOX/trunk/oe/build-nbt-crownbeach/tmp/staging/i586-angstrom-linux/lib/libc.so.6:
undefined reference to `_dl_tls_get_addr_soft@GLIBC_PRIVATE'
collect2: ld returned 1 exit status
    make[7]: *** [host_xpidl] Error 1
    ...
    FATAL: oe_runmake failed
   
***debian lenny***
    the above "ccache gcc -o host_xpidl..." works well, even if there
are some warnings in compiling "ccache gcc -o host_xpidl_java.o ..."
that are not present in etch.

is this a bug? shouldn't the recipe invoke "ccache
i586-angstrom-linux-gcc" instead of "ccache gcc" (as is doing in other
parts of the recipe)???
Am I right saying that there it's using my gcc and not the cross-gcc? is
there an elegant way to check which other packages are using somewhere
my gcc and not the right one? (there was also another difference in
behaviours, before minimo, between the 2 images created)


thank you for all,
    hope to contribute more actively soon, now just need some newbie
confirmations!
phy

Re: different hosts, different OE images

[Filippo Basso]

> I understood that the results should be highly independent from host
> system, so I begun debugging a bit.
>   
Hi everybody,
    my investigation is going ahead...
The main point is: an image should be highly independent from the host
system, but seems that I've some problem in this regards... maybe my
mistake, but should be understood.

Another machine (Ubuntu) gave even another different runtime result... :-(

Now I've debugged differences in the log.do_compile files, and have
these "strange" results:
* the order of gcc arguments is not always fixed, depends on the machine
(es: ipkg, perl)
* in many packages the make[n] is make[n+1], sometimes there is a
duplicated chdir, or there is a duplicated message like "OE: Not
hardcoding..."
* in many packages on lenny is present in the options for "ccache
i586-angstrom-linux-gcc" a -L/usr/lib (isn't that potentially dangerous???)


Not OE-related, more .bb recipy-related:
* minimo is using gcc (and not i586-angstrom-linux-gcc), so is failing
on etch and working on lenny (I've to investigate more if this can work,
imagine if I want to use an ARM, hehehe!)
* and a strange behaviour in coreutils-native (this I've to investigate
more, about openat.c and getcwd.c, maybe not a OE issue)


To be sure that the versions are the same, the OE tree is the same (mtn
status: 1c938b19625a9b636c77145c8a420c71768f0595), bitbake is the same,
I've double checked everything.

Now it's  late night, I'll investigate ubuntu problems (X11 restarting
continuously) with same image compiling on lenny, not compiling on etch...

some suggestions?
thank you 10000!
    phy

Re: different hosts, different OE images

[Filippo Basso]

Hi,
    can someone tell me if this is an important point, or if I'm just
missing something ?!?
I've seen that 3 host machines (with different linux distros) gave me 3
different OE results (for i586), one is okay, one is not compiling, one
the image has a big problem at login...

I want to investigate a bit, some hints ? Just a starting point.....
I think that one of the most important points of OE is that is largely
independent of host machine, right?!?
    thank you, phy





>> I understood that the results should be highly independent from host
>> system, so I begun debugging a bit.
>>   
>>     
> Hi everybody,
>     my investigation is going ahead...
> The main point is: an image should be highly independent from the host
> system, but seems that I've some problem in this regards... maybe my
> mistake, but should be understood.
>
> Another machine (Ubuntu) gave even another different runtime result... :-(

Re: different hosts, different OE images

[Stelios Koroneos]

Well to answer your question in a quick way
it should not be happening

We have seen from time to time differences between 32bit hosts and 64bit
hosts but not anything like the thing you mention.

Could you prvide some additional info (what distro, machine, host tools
versions etc)

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces@openembedded.org
> [mailto:openembedded-devel-bounces@openembedded.org]On Behalf Of
> Filippo Basso
> Sent: Wednesday, October 24, 2007 10:08 PM
> To: openembedded-devel@openembedded.org
> Subject: Re: [oe] different hosts, different OE images
>
>
> Hi,
>     can someone tell me if this is an important point, or if I'm just
> missing something ?!?
> I've seen that 3 host machines (with different linux distros) gave me 3
> different OE results (for i586), one is okay, one is not compiling, one
> the image has a big problem at login...
>
> I want to investigate a bit, some hints ? Just a starting point.....
> I think that one of the most important points of OE is that is largely
> independent of host machine, right?!?
>     thank you, phy
>
>
>
>
>
> >> I understood that the results should be highly independent from host
> >> system, so I begun debugging a bit.
> >>
> >>
> > Hi everybody,
> >     my investigation is going ahead...
> > The main point is: an image should be highly independent from the host
> > system, but seems that I've some problem in this regards... maybe my
> > mistake, but should be understood.
> >
> > Another machine (Ubuntu) gave even another different runtime
> result... :-(
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: different hosts, different OE images

[Filippo Basso]

Stelios Koroneos ha scritto:
> Well to answer your question in a quick way
> it should not be happening
>
> We have seen from time to time differences between 32bit hosts and 64bit
> hosts but not anything like the thing you mention.
>
> Could you prvide some additional info (what distro, machine, host tools
> versions etc)
>   
Thank you Stelios for the answer!!!
    I was trying to better understand OE, writing a small doc called "OE
Journey" and try to go a little deeper in my personal understanding of
this very interesting tool...

So, after some time I was  playing successfully with it, I tried to
analyze better a simple:
    DISTRO = "angstrom-2007.1"
    MACHINE = "qemux86"

with 3 hosts:
    1) my debian-testing (lenny)
    * gcc version 4.2.3

    2) vmware debian-stable (etch)
    * gcc version 4.1.1

    3) vmware ubuntu
    * gcc version 4.1.2

    Same for the 3 distros:
    * GNU Make 3.81
    * BitBake Build Tool Core version 1.8.9, bitbake version 1.8.9
    * monotone 0.36  (with OE at the same fixed revision 1c938b19)
    * GNU Awk 3.1.5
    * patch 2.5.9
    * ccache version 2.4
    * perl, v5.8.8 built for i486-linux-gnu-thread-multi
    * Python 2.4.4

I've noticed differences in the 3 distro, that I tried to setup
identically, so I begun to investigate. At the moment I've not yet found
a nice way to see differences, I just make md5 on logfiles and from that
I analyze manually 20-30 non-matching logfiles. (log.do_compile). Any
better idea?

Say that host1 create a nice image, while host3 has strange behaviour at
login (after login immediately exits and show again the login form).
host2 seems like host1, but if I try to add the "minimo" package, it
compiles on host1 and not on host2..... :-(

Seems something strange... 3 hosts, 3 behaviours...
So I was reading the log.do_compile files manually (after choosing
different md5) and at the moment I found:
* the order of gcc arguments is not always fixed, depends on the machine
(es: ipkg, perl)
* in many packages the make[n] is make[n+1] (one more "Make"), sometimes
there is a duplicated chdir, or there is a duplicated message like "OE:
Not hardcoding..."
* in many packages on lenny is present in the options for "ccache
i586-angstrom-linux-gcc" a -L/usr/lib (isn't that potentially dangerous???)

..................................

so, now I really want to understand it well, and help to fix the
problem. If somebody has some nice idea on how I should proceed, I'll
devote my laptop to this work next nights.

thank you!
    phy