Libtoo sysrootl issue when testing machine specific sysroot

Libtoo sysrootl issue when testing machine specific sysroot

[Xu, Dongxiao]

Hi Richard,

When testing the machine specific sysroot patchset for atom-pc and emenlow machines, it exposed a libtool issue that, after the built of "Machine A", and then try to build "Machine B" of the same architecture, those "-L" paths generated by libtool still points to the "Machine A" sysroot, which is definitely not correct and may have issues.

One example is like the following, after built of emenlow, and then try to build atom-pc, the sysroot is points to atom-pc paths, however some "-L" paths point to emenlow directories.

/distro/dongxiao/build-core2/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux/i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/distro/dongxiao/build-core2/tmp/sysroots/atom-pc -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/include/pixman-1 -I/distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/include/freetype2 -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -DXF86PM -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb -feliminate-unused-debug-types -Wl,-O1 -Wl,--as-needed -o .libs/Xorg xorg.o -Wl,--export-dynamic  ../../dix/.libs/libmain.a ./.libs/libxorg.a -L/distro/dongxiao/build-core2/tmp/sysroots/emenlow/usr/lib /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libudev.so /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libgcrypt.so /distro/dongxiao/build-core2/tmp/sysroots/emenlow/usr/lib/libgpg-error.so -ldl /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libpciaccess.so -lpthread /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libpixman-1.so /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libXfont.so /distro/dongxiao/build-core2/tmp/sysroots/emenlow/usr/lib/libfreetype.so /distro/dongxiao/build-core2/tmp/sysroots/emenlow/usr/lib/libfontenc.so /distro/dongxiao/build-core2/tmp/sysroots/emenlow/usr/lib/libz.so /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libXau.so /distro/dongxiao/build-core2/tmp/sysroots/atom-pc/usr/lib/libXdmcp.so -lm


This problem happens when building atom-pc and emenlow since some libraries they are using are not the same.

This issue should also exist for qemuppc and mpc8315e-rdb build but it isn't exposed during my pervious testings, maybe because these files between the two machines are the same. 

We saw we have plan to add libtool sysroot support and remove its workaround, http://bugzilla.pokylinux.org/show_bug.cgi?id=353, I think this should help to solve the issue.

CC Scott.G who owns this libtool enhancement.

Thanks,
Dongxiao 

Re: Libtoo sysrootl issue when testing machine specific sysroot

[Scott Garman]

On 01/10/2011 07:15 PM, Xu, Dongxiao wrote:
> Hi Richard,
>
> When testing the machine specific sysroot patchset for atom-pc and
> emenlow machines, it exposed a libtool issue that, after the built of
> "Machine A", and then try to build "Machine B" of the same
> architecture, those "-L" paths generated by libtool still points to
> the "Machine A" sysroot, which is definitely not correct and may have
> issues.

Thanks Donxiao for the info. I will make sure to test this scenario 
before submitting my libtool 2.4 sysroot support to ensure it is resolved.

Scott

-- 
Scott Garman
Embedded Linux Distro Engineer - Yocto Project

Re: Libtoo sysrootl issue when testing machine specific sysroot

[Xu, Dongxiao]

Garman, Scott A wrote:
> On 01/10/2011 07:15 PM, Xu, Dongxiao wrote:
>> Hi Richard,
>> 
>> When testing the machine specific sysroot patchset for atom-pc and
>> emenlow machines, it exposed a libtool issue that, after the built of
>> "Machine A", and then try to build "Machine B" of the same
>> architecture, those "-L" paths generated by libtool still points to
>> the "Machine A" sysroot, which is definitely not correct and may have
>> issues.
> 
> Thanks Donxiao for the info. I will make sure to test this scenario
> before submitting my libtool 2.4 sysroot support to ensure it is
> resolved.  

Hi Scott,

This issue may only happen with the implementation of machine specific sysroot. 

Currently different machines of one architecture share the same path of sysroot and the issue would not be triggered. 

If you want to do the above test, you can based on my branch http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dxu4/mach_sysroot_v3. 

Or you can share me your branch if you think it is mostly stable, and then I can test my patchset on it. :-)

Thanks,
Dongxiao

> 
> Scott

Re: Libtoo sysrootl issue when testing machine specific sysroot

[Richard Purdie]

On Tue, 2011-01-11 at 10:57 -0800, Garman, Scott A wrote:
> On 01/10/2011 07:15 PM, Xu, Dongxiao wrote:
> > Hi Richard,
> >
> > When testing the machine specific sysroot patchset for atom-pc and
> > emenlow machines, it exposed a libtool issue that, after the built of
> > "Machine A", and then try to build "Machine B" of the same
> > architecture, those "-L" paths generated by libtool still points to
> > the "Machine A" sysroot, which is definitely not correct and may have
> > issues.
> 
> Thanks Donxiao for the info. I will make sure to test this scenario 
> before submitting my libtool 2.4 sysroot support to ensure it is resolved.

I talked a little with Dongxiao about this and it looks like he needs to
improve the functionality in sstate to cope with sysroot per machine.

This isn't to say that the libtool 2.4 sysroot support won't reduce the
amount of relocation work those functions need to do which is all good
but both changes are needed independently of each other.

Cheers,

Richard