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

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

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

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