psuedo-native strangeness on 64 bit build machine

psuedo-native strangeness on 64 bit build machine

[Steve Sakoman]

I did a clean build on an Ubuntu 64 bit build machine a couple of days
ago with no issues.

After a pull of today I did an image build for an OMAP3 machine and
encountered an issue with psuedo-native.

First I got this familiar message:

Pseudo is not present but is required, building this first before the main build

which seemed a bit strange since pseudo was built in the previous
clean build.  The build proceeded until task 75 and then failed with
the following error:

NOTE: Running task 75 of 77 (ID: 6,
virtual:native:/home/steve/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.2.bb,
do_compile)
NOTE: package pseudo-native-1.2-r5: task do_compile: Started
ERROR: Function failed: do_compile (see
/media/data/yocto/tmp/work/x86_64-linux/pseudo-native-1.2-r5/temp/log.do_compile.32657
for further information)
ERROR: Logfile of failure stored in:
/media/data/yocto/tmp/work/x86_64-linux/pseudo-native-1.2-r5/temp/log.do_compile.32657
Log data follows:
| ERROR: Function failed: do_compile (see
/media/data/yocto/tmp/work/x86_64-linux/pseudo-native-1.2-r5/temp/log.do_compile.32657
for further information)
| SQLite header for version 3007010 found.
| NOTE: make -j 4 -e MAKEFLAGS= libpseudo
| ccache gcc -isystem/media/data/yocto/tmp/sysroots/x86_64-linux/usr/include
-O2 -pipe -pipe -std=gnu99 -Wall -W -Wextra -fPIC
-D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32
-DPSEUDO_PREFIX='"/media/data/yocto/tmp/sysroots/x86_64-linux/usr"'
-DPSEUDO_SUFFIX='""' -DPSEUDO_BINDIR='"bin"'
-DPSEUDO_LIBDIR='"lib/pseudo/lib"'
-DPSEUDO_LOCALSTATEDIR='"var/pseudo"' -DPSEUDO_VERSION='"1.2"' -O2 -g
-L/media/data/yocto/tmp/sysroots/x86_64-linux/usr/lib
-I/media/data/yocto/tmp/sysroots/x86_64-linux/usr/include
-Wl,-R/media/data/yocto/tmp/sysroots/x86_64-linux/usr/lib -shared -o
lib/pseudo/lib/libpseudo.so \
| 		pseudo_client.o pseudo_ipc.o \
| 		pseudo_wrappers.o pseudo_tables.o pseudo_util.o -ldl -lpthread
| /usr/bin/ld: i386:x86-64 architecture of input file
`pseudo_client.o' is incompatible with i386 output
| /usr/bin/ld: i386:x86-64 architecture of input file `pseudo_ipc.o'
is incompatible with i386 output
| /usr/bin/ld: i386:x86-64 architecture of input file
`pseudo_wrappers.o' is incompatible with i386 output
| /usr/bin/ld: i386:x86-64 architecture of input file
`pseudo_tables.o' is incompatible with i386 output
| /usr/bin/ld: i386:x86-64 architecture of input file `pseudo_util.o'
is incompatible with i386 output
| /usr/bin/ld: final link failed: Invalid operation
| collect2: ld returned 1 exit status
| make: *** [lib/pseudo/lib/libpseudo.so] Error 1
| ERROR: oe_runmake failed
NOTE: package pseudo-native-1.2-r5: task do_compile: Failed
ERROR: Task 6 (virtual:native:/home/steve/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.2.bb,
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 75 tasks of which 74 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
  virtual:native:/home/steve/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.2.bb,
do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Has anyone else been successful building on 64 bit machines?

I see no issues on my 32 bit build machines.

Forcing a clean build of pseudo (by hand, since -c cleansstate
obviously won't work with pseudo-native!) resulted in a good build,
both of psuedo-native and the image.

Any ideas?

Steve

Re: psuedo-native strangeness on 64 bit build machine

[Mark Hatle]

On 2/28/12 10:35 PM, Steve Sakoman wrote:
> I did a clean build on an Ubuntu 64 bit build machine a couple of days
> ago with no issues.
>
> After a pull of today I did an image build for an OMAP3 machine and
> encountered an issue with psuedo-native.
>
> First I got this familiar message:
>
> Pseudo is not present but is required, building this first before the main build
>
> which seemed a bit strange since pseudo was built in the previous
> clean build.  The build proceeded until task 75 and then failed with
> the following error:
>
> NOTE: Running task 75 of 77 (ID: 6,
> virtual:native:/home/steve/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.2.bb,
> do_compile)
> NOTE: package pseudo-native-1.2-r5: task do_compile: Started
> ERROR: Function failed: do_compile (see
> /media/data/yocto/tmp/work/x86_64-linux/pseudo-native-1.2-r5/temp/log.do_compile.32657
> for further information)
> ERROR: Logfile of failure stored in:
> /media/data/yocto/tmp/work/x86_64-linux/pseudo-native-1.2-r5/temp/log.do_compile.32657
> Log data follows:
> | ERROR: Function failed: do_compile (see
> /media/data/yocto/tmp/work/x86_64-linux/pseudo-native-1.2-r5/temp/log.do_compile.32657
> for further information)
> | SQLite header for version 3007010 found.
> | NOTE: make -j 4 -e MAKEFLAGS= libpseudo
> | ccache gcc -isystem/media/data/yocto/tmp/sysroots/x86_64-linux/usr/include
> -O2 -pipe -pipe -std=gnu99 -Wall -W -Wextra -fPIC
> -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32
> -DPSEUDO_PREFIX='"/media/data/yocto/tmp/sysroots/x86_64-linux/usr"'
> -DPSEUDO_SUFFIX='""' -DPSEUDO_BINDIR='"bin"'
> -DPSEUDO_LIBDIR='"lib/pseudo/lib"'
> -DPSEUDO_LOCALSTATEDIR='"var/pseudo"' -DPSEUDO_VERSION='"1.2"' -O2 -g
> -L/media/data/yocto/tmp/sysroots/x86_64-linux/usr/lib
> -I/media/data/yocto/tmp/sysroots/x86_64-linux/usr/include
> -Wl,-R/media/data/yocto/tmp/sysroots/x86_64-linux/usr/lib -shared -o
> lib/pseudo/lib/libpseudo.so \
> | 		pseudo_client.o pseudo_ipc.o \
> | 		pseudo_wrappers.o pseudo_tables.o pseudo_util.o -ldl -lpthread
> | /usr/bin/ld: i386:x86-64 architecture of input file
> `pseudo_client.o' is incompatible with i386 output
> | /usr/bin/ld: i386:x86-64 architecture of input file `pseudo_ipc.o'
> is incompatible with i386 output
> | /usr/bin/ld: i386:x86-64 architecture of input file
> `pseudo_wrappers.o' is incompatible with i386 output
> | /usr/bin/ld: i386:x86-64 architecture of input file
> `pseudo_tables.o' is incompatible with i386 output
> | /usr/bin/ld: i386:x86-64 architecture of input file `pseudo_util.o'
> is incompatible with i386 output
> | /usr/bin/ld: final link failed: Invalid operation
> | collect2: ld returned 1 exit status
> | make: *** [lib/pseudo/lib/libpseudo.so] Error 1
> | ERROR: oe_runmake failed
> NOTE: package pseudo-native-1.2-r5: task do_compile: Failed
> ERROR: Task 6 (virtual:native:/home/steve/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.2.bb,
> do_compile) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 75 tasks of which 74 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>    virtual:native:/home/steve/source/yocto/poky/meta/recipes-devtools/pseudo/pseudo_1.2.bb,
> do_compile
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> Has anyone else been successful building on 64 bit machines?

I'm building pseudo on 64-bit machines right now, no problem.

The error you are seeing is pseudo attempting to build both a 64-bit and a 
32-bit wrapper.  The 32-bit wrapper is built when the recipe detects support for 
both 32-bit and 64-bit userspace.  It does this by looking first that your host 
is 64-bit, and then for /usr/include/gnu/stubs-32.h.  Assuming it finds those, 
it assumes your system has 32-bit binaries on it.

To avoid a 32-bit build of pseudo, on a 64-bit machine.  You need to set 
NO32LIBS = "1".  This instructs pseudo to avoid the 32-bit binary build.  (If 
your machine has 32-bit binaries on it, you need to fix your compiler to allow 
for 32-bit userspace builds, otherwise pseudo will be incapable of wrapping any 
32-bit binaries, resulting in a potential mismatch of user, groups and modes set 
by any 32-bit applications.

--Mark

> I see no issues on my 32 bit build machines.
>
> Forcing a clean build of pseudo (by hand, since -c cleansstate
> obviously won't work with pseudo-native!) resulted in a good build,
> both of psuedo-native and the image.
>
> Any ideas?
>
> Steve
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: psuedo-native strangeness on 64 bit build machine

[Steve Sakoman]

On Tue, Feb 28, 2012 at 9:13 PM, Mark Hatle <mark.hatle@windriver.com> wrote:

> I'm building pseudo on 64-bit machines right now, no problem.
>
> The error you are seeing is pseudo attempting to build both a 64-bit and a
> 32-bit wrapper.  The 32-bit wrapper is built when the recipe detects support
> for both 32-bit and 64-bit userspace.  It does this by looking first that
> your host is 64-bit, and then for /usr/include/gnu/stubs-32.h.  Assuming it
> finds those, it assumes your system has 32-bit binaries on it.

Thanks for the quick reply.

My 64 bit build machine has the ia32-libs package installed and
/usr/include/gnu/stubs-32.h exists.  Any idea why the initial clean
build succeeds, but the rebuild triggered by the pull fails?

> To avoid a 32-bit build of pseudo, on a 64-bit machine.  You need to set
> NO32LIBS = "1".  This instructs pseudo to avoid the 32-bit binary build.
>  (If your machine has 32-bit binaries on it, you need to fix your compiler
> to allow for 32-bit userspace builds, otherwise pseudo will be incapable of
> wrapping any 32-bit binaries, resulting in a potential mismatch of user,
> groups and modes set by any 32-bit applications.

Could you give me a pointer on how to "fix" my compiler to allow for
32-bit userspace builds?

Thanks!

Steve

Re: psuedo-native strangeness on 64 bit build machine

[Mark Hatle]

On 2/28/12 11:29 PM, Steve Sakoman wrote:
> On Tue, Feb 28, 2012 at 9:13 PM, Mark Hatle<mark.hatle@windriver.com>  wrote:
>
>> I'm building pseudo on 64-bit machines right now, no problem.
>>
>> The error you are seeing is pseudo attempting to build both a 64-bit and a
>> 32-bit wrapper.  The 32-bit wrapper is built when the recipe detects support
>> for both 32-bit and 64-bit userspace.  It does this by looking first that
>> your host is 64-bit, and then for /usr/include/gnu/stubs-32.h.  Assuming it
>> finds those, it assumes your system has 32-bit binaries on it.
>
> Thanks for the quick reply.
>
> My 64 bit build machine has the ia32-libs package installed and
> /usr/include/gnu/stubs-32.h exists.  Any idea why the initial clean
> build succeeds, but the rebuild triggered by the pull fails?
>
>> To avoid a 32-bit build of pseudo, on a 64-bit machine.  You need to set
>> NO32LIBS = "1".  This instructs pseudo to avoid the 32-bit binary build.
>>   (If your machine has 32-bit binaries on it, you need to fix your compiler
>> to allow for 32-bit userspace builds, otherwise pseudo will be incapable of
>> wrapping any 32-bit binaries, resulting in a potential mismatch of user,
>> groups and modes set by any 32-bit applications.
>
> Could you give me a pointer on how to "fix" my compiler to allow for
> 32-bit userspace builds?

I don't use Ubuntu much, and when I do, it's only with 64-bit binaries.  (Fedora 
and RHEL I often use with mixed size systems...)

Most distributions have a 32-bit devel package, or set of packages.  I assume 
ubuntu does as well.  (I've recently been doing a lot of builds on 64-bit Mint 12.)

A quick google found me some references to:

glibc-devel-32bit, gcc-32bit

You might want to try apt-get those and see if that will work.  Under the hood, 
you'll need the 32-bit glibc development files, and libgcc.  Once you have that, 
I believe pseudo will build both 32-bit and 64-bit properly.

--Mark

> Thanks!
>
> Steve

Re: psuedo-native strangeness on 64 bit build machine

[Petr Štetiar]

Mark Hatle <mark.hatle@windriver.com> [2012-02-28 23:13:47]:

> On 2/28/12 10:35 PM, Steve Sakoman wrote:
>> I did a clean build on an Ubuntu 64 bit build machine a couple of days
>> ago with no issues.

I can confirm same situation here.

>> After a pull of today I did an image build for an OMAP3 machine and
>> encountered an issue with psuedo-native.

Just pseudo? What's your setup, I mean layers etc. Are you using Angstrom's
setup-scripts?

>> Has anyone else been successful building on 64 bit machines?

What version of Ubuntu is that? I'm on 12.04.

> I'm building pseudo on 64-bit machines right now, no problem.

I think, that it's some problem with parallel make. If I clean the stamps and
tmp dir of pseudo-native manually (-c cleanall doesn't work actually, because
pseudo-native is missing, chicken-egg problem? :)) and set PARALLEL_MAKE=1
NUM_THREADS=-j1, then it builds just fine.

There must have been something introduced in the bitbake or the layers
recently, since I was able to build Angstrom/systemd-image/beagleboard from
scratch 3 weeks ago with the same settings (PARALLEL_MAKE=4 NUM_THREADS=-j4").
Now it's impossible to finish the build, the most noticeable failure is gcc,
which fails for me in patching task due to the parallel build settings.
Changing the parallel settings back to 1 helps here also.

-- ynezz

Re: psuedo-native strangeness on 64 bit build machine

[Steve Sakoman]

On Wed, Feb 29, 2012 at 12:45 AM, Petr Štetiar <ynezz@true.cz> wrote:
>> On 2/28/12 10:35 PM, Steve Sakoman wrote:
>>> I did a clean build on an Ubuntu 64 bit build machine a couple of days
>>> ago with no issues.
>
> I can confirm same situation here.
>
>>> After a pull of today I did an image build for an OMAP3 machine and
>>> encountered an issue with psuedo-native.
>
> Just pseudo? What's your setup, I mean layers etc. Are you using Angstrom's
> setup-scripts?

For a simple image, just pseudo-native.  As to layers, meta,
meta-yocto, meta-oe and meta-gnome from meta-openembedded, and my own
bsp layer.

I am not using Angstrom or the Angstrom setup scripts.

>>> Has anyone else been successful building on 64 bit machines?
>
> What version of Ubuntu is that? I'm on 12.04.

I am on 10.04 64 bit server edition with ia32-libs package installed.
The build machine is quad core.

>> I'm building pseudo on 64-bit machines right now, no problem.
>
> I think, that it's some problem with parallel make. If I clean the stamps and
> tmp dir of pseudo-native manually (-c cleanall doesn't work actually, because
> pseudo-native is missing, chicken-egg problem? :)) and set PARALLEL_MAKE=1
> NUM_THREADS=-j1, then it builds just fine.

If so, it is only a parallel make issue on 64 bit -- my build on an 8
core desktop 10.04 setup works flawlessly.

> There must have been something introduced in the bitbake or the layers
> recently, since I was able to build Angstrom/systemd-image/beagleboard from
> scratch 3 weeks ago with the same settings (PARALLEL_MAKE=4 NUM_THREADS=-j4").
> Now it's impossible to finish the build, the most noticeable failure is gcc,
> which fails for me in patching task due to the parallel build settings.
> Changing the parallel settings back to 1 helps here also.

I just tried building gcc and can confirm that it fails for me on the
64 bit build machine.

Steve

Re: psuedo-native strangeness on 64 bit build machine

[Steve Sakoman]

On Wed, Feb 29, 2012 at 6:22 AM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Wed, Feb 29, 2012 at 12:45 AM, Petr Štetiar <ynezz@true.cz> wrote:

>> Now it's impossible to finish the build, the most noticeable failure is gcc,
>> which fails for me in patching task due to the parallel build settings.
>> Changing the parallel settings back to 1 helps here also.
>
> I just tried building gcc and can confirm that it fails for me on the
> 64 bit build machine.

For me, a -c cleansstate gcc and then a rebuild resulted in a
successful gcc build.  I did not need to turn off parallel builds.

Steve

Re: psuedo-native strangeness on 64 bit build machine

[Khem Raj]

On 02/29/2012 07:12 AM, Steve Sakoman wrote:
> On Wed, Feb 29, 2012 at 6:22 AM, Steve Sakoman <sakoman@gmail.com> wrote:
>> On Wed, Feb 29, 2012 at 12:45 AM, Petr Štetiar <ynezz@true.cz> wrote:
> 
>>> Now it's impossible to finish the build, the most noticeable failure is gcc,
>>> which fails for me in patching task due to the parallel build settings.
>>> Changing the parallel settings back to 1 helps here also.
>>
>> I just tried building gcc and can confirm that it fails for me on the
>> 64 bit build machine.
> 
> For me, a -c cleansstate gcc and then a rebuild resulted in a
> successful gcc build.  I did not need to turn off parallel builds.
> 

just add NO32LIBS = "1" to your local.conf

> Steve
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: psuedo-native strangeness on 64 bit build machine

[Steve Sakoman]

On Thu, Mar 1, 2012 at 2:33 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On 02/29/2012 07:12 AM, Steve Sakoman wrote:
>> On Wed, Feb 29, 2012 at 6:22 AM, Steve Sakoman <sakoman@gmail.com> wrote:
>>> On Wed, Feb 29, 2012 at 12:45 AM, Petr Štetiar <ynezz@true.cz> wrote:
>>
>>>> Now it's impossible to finish the build, the most noticeable failure is gcc,
>>>> which fails for me in patching task due to the parallel build settings.
>>>> Changing the parallel settings back to 1 helps here also.
>>>
>>> I just tried building gcc and can confirm that it fails for me on the
>>> 64 bit build machine.
>>
>> For me, a -c cleansstate gcc and then a rebuild resulted in a
>> successful gcc build.  I did not need to turn off parallel builds.
>>
>
> just add NO32LIBS = "1" to your local.conf

I can do that, but I'm still a bit confused why a clean build
succeeds, but a rebuild triggered by sstate hash fails with the 32 bit
lib issue.

Is this another case of a flawed recipe (like wpa-supplicant) that
can't be rerun because it modifies $S?

Steve