Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-09-03 Thread Peter Bergin 



I was able to confirm that fixed a simple test case for nativesdk-gcc
on i686 so I'll queue it up to reset the rust changes.

Cheers,

Richard


Thank you Richard! Great that you could fix this and we could get the 
rust tests in.


/Peter



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170266): 
https://lists.openembedded.org/g/openembedded-core/message/170266
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-09-02 Thread Richard Purdie 
On Fri, 2022-09-02 at 14:33 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Mon, 2022-08-29 at 13:09 +0200, Peter Bergin wrote:
> > Hi Richard,
> > 
> > (also adding Khem Raj to CC as maintainer for gcc in oe-core)
> > 
> > On 2022-08-25 17:25, Richard Purdie wrote:
> > > On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote:
> > > > Hi Richard,
> > > > 
> > > > On 2022-08-25 10:21, Richard Purdie wrote:
> > > > > 
> > > > > > I've tried locally to reproduce something. I've built and tested
> > > > > > genericx86 and qemuarm64 now on core-image-sato sdk that I saw was 
> > > > > > the
> > > > > > target for the autobuilder. Both tests passes. The failure I see in 
> > > > > > the
> > > > > > autobuilder logs is that the build script can not be executed. On my
> > > > > > machine I have that file and it can clearly be executed:
> > > > > > 
> > > > > > $ find
> > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
> > > > > > -name build-script-build
> > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > > 
> > > > > > $
> > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > > 
> > > > > > $ file
> > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > > 
> > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
> > > > > > ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
> > > > > > linked, interpreter
> > > > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
> > > > > > BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for 
> > > > > > GNU/Linux
> > > > > > 3.2.0, with debug_info, not stripped
> > > > > > 
> > > > > > Found one interesting link here
> > > > > > https://github.com/rust-lang/cargo/issues/3553. Unfortunately 
> > > > > > without
> > > > > > answer. But also checked the interpreter in my build which looks 
> > > > > > correct?
> > > > > > 
> > > > > > $ readelf -a
> > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > > > grep interpreter
> > > > > >  [Requesting program interpreter:
> > > > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
> > > > > > 
> > > > > > 
> > > > > > So there are some differences between my machine and the autobuilder
> > > > > > setup that I can't get. I would need help here as I'm not that 
> > > > > > familiar
> > > > > > with the autobuilder setup. Can it still be some host dependency? 
> > > > > > I'm
> > > > > > running on Ubuntu 22.04. Is it possible to check in a autobuilder 
> > > > > > setup
> > > > > > if the file 'build-script-build' is present and possible to execute?
> > > > > After staring at this for an hour, I think the pattern is that is it
> > > > > failing on builds with:
> > > > > 
> > > > > SDKMACHINE = "i686"
> > > > > 
> > > > > which probably means the linker isn't linking against the libc and
> > > > > loader in the SDK properly.
> > > > > 
> > > > > (i686 SDK binaries should run on x86_64 hosts since we provide our own
> > > > > loader and libc)
> > > > Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I
> > > > was able to reproduce. I want to share some weird stuff and see if
> > > > someone can get a clue for a solution.
> > > > 
> > > > Did same analyze on the build-script-build file as I did on a working 
> > > > one:
> > > As I suspected, the dynamic loader on binaries built using the
> > > toolchain in the SDK isn't working correctly.
> > > 
> > > "/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-
> > > linux/lib/ld-linux.so.2"
> > > 
> > > is the value used at build time. This is supposed to be relocated into
> > > the SDK's install location at runtime.
> > > 
> > > The question is therefore where is rust getting this value from? You
> > > can specify it to the linker at compile time along the lines of:
> > > 
> > > -Wl,--dynamic-linker=/path/to/ld-linux.so.2
> > > 
> > > or it can be the default that comes from toolchain. It is important it
> > > points at the one in the SDK, not on the host system.
> > > 
> > > The bit I don't understand is whether:
> > > 
> > > a) the compiler in the SDK is generating the wrong loader (in which
> > > case buildtools-extended-tarball would break which it doesn't)
> > > b) rust is hardcoding some dynamic-linker option somewhere it shouldn't
> > > c)

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-09-02 Thread Richard Purdie 
On Mon, 2022-08-29 at 13:09 +0200, Peter Bergin wrote:
> Hi Richard,
> 
> (also adding Khem Raj to CC as maintainer for gcc in oe-core)
> 
> On 2022-08-25 17:25, Richard Purdie wrote:
> > On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote:
> > > Hi Richard,
> > > 
> > > On 2022-08-25 10:21, Richard Purdie wrote:
> > > > 
> > > > > I've tried locally to reproduce something. I've built and tested
> > > > > genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the
> > > > > target for the autobuilder. Both tests passes. The failure I see in 
> > > > > the
> > > > > autobuilder logs is that the build script can not be executed. On my
> > > > > machine I have that file and it can clearly be executed:
> > > > > 
> > > > > $ find
> > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
> > > > > -name build-script-build
> > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > 
> > > > > $
> > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > 
> > > > > $ file
> > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > 
> > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
> > > > > ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
> > > > > linked, interpreter
> > > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
> > > > > BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux
> > > > > 3.2.0, with debug_info, not stripped
> > > > > 
> > > > > Found one interesting link here
> > > > > https://github.com/rust-lang/cargo/issues/3553. Unfortunately without
> > > > > answer. But also checked the interpreter in my build which looks 
> > > > > correct?
> > > > > 
> > > > > $ readelf -a
> > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > > > grep interpreter
> > > > >  [Requesting program interpreter:
> > > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
> > > > > 
> > > > > 
> > > > > So there are some differences between my machine and the autobuilder
> > > > > setup that I can't get. I would need help here as I'm not that 
> > > > > familiar
> > > > > with the autobuilder setup. Can it still be some host dependency? I'm
> > > > > running on Ubuntu 22.04. Is it possible to check in a autobuilder 
> > > > > setup
> > > > > if the file 'build-script-build' is present and possible to execute?
> > > > After staring at this for an hour, I think the pattern is that is it
> > > > failing on builds with:
> > > > 
> > > > SDKMACHINE = "i686"
> > > > 
> > > > which probably means the linker isn't linking against the libc and
> > > > loader in the SDK properly.
> > > > 
> > > > (i686 SDK binaries should run on x86_64 hosts since we provide our own
> > > > loader and libc)
> > > Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I
> > > was able to reproduce. I want to share some weird stuff and see if
> > > someone can get a clue for a solution.
> > > 
> > > Did same analyze on the build-script-build file as I did on a working one:
> > As I suspected, the dynamic loader on binaries built using the
> > toolchain in the SDK isn't working correctly.
> > 
> > "/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-
> > linux/lib/ld-linux.so.2"
> > 
> > is the value used at build time. This is supposed to be relocated into
> > the SDK's install location at runtime.
> > 
> > The question is therefore where is rust getting this value from? You
> > can specify it to the linker at compile time along the lines of:
> > 
> > -Wl,--dynamic-linker=/path/to/ld-linux.so.2
> > 
> > or it can be the default that comes from toolchain. It is important it
> > points at the one in the SDK, not on the host system.
> > 
> > The bit I don't understand is whether:
> > 
> > a) the compiler in the SDK is generating the wrong loader (in which
> > case buildtools-extended-tarball would break which it doesn't)
> > b) rust is hardcoding some dynamic-linker option somewhere it shouldn't
> > c) whether the toolchain is relocating paths correctly or some path
> > isn't relocating and is being used here.
> > 
> > I'd suggest first checking that a binary generated by nativesdk-gcc in
> > the SDK has the right loader. If that is the case, see what compiler
> > options are being used to create the build tool and go from

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-29 Thread Peter Bergin 

Hi Richard,

(also adding Khem Raj to CC as maintainer for gcc in oe-core)

On 2022-08-25 17:25, Richard Purdie wrote:

On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote:

Hi Richard,

On 2022-08-25 10:21, Richard Purdie wrote:



I've tried locally to reproduce something. I've built and tested
genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the
target for the autobuilder. Both tests passes. The failure I see in the
autobuilder logs is that the build script can not be executed. On my
machine I have that file and it can clearly be executed:

$ find
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
-name build-script-build
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

$
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

$ file
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux
3.2.0, with debug_info, not stripped

Found one interesting link here
https://github.com/rust-lang/cargo/issues/3553. Unfortunately without
answer. But also checked the interpreter in my build which looks correct?

$ readelf -a
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

grep interpreter

     [Requesting program interpreter:
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]


So there are some differences between my machine and the autobuilder
setup that I can't get. I would need help here as I'm not that familiar
with the autobuilder setup. Can it still be some host dependency? I'm
running on Ubuntu 22.04. Is it possible to check in a autobuilder setup
if the file 'build-script-build' is present and possible to execute?

After staring at this for an hour, I think the pattern is that is it
failing on builds with:

SDKMACHINE = "i686"

which probably means the linker isn't linking against the libc and
loader in the SDK properly.

(i686 SDK binaries should run on x86_64 hosts since we provide our own
loader and libc)

Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I
was able to reproduce. I want to share some weird stuff and see if
someone can get a clue for a solution.

Did same analyze on the build-script-build file as I did on a working one:

As I suspected, the dynamic loader on binaries built using the
toolchain in the SDK isn't working correctly.

"/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-
linux/lib/ld-linux.so.2"

is the value used at build time. This is supposed to be relocated into
the SDK's install location at runtime.

The question is therefore where is rust getting this value from? You
can specify it to the linker at compile time along the lines of:

-Wl,--dynamic-linker=/path/to/ld-linux.so.2

or it can be the default that comes from toolchain. It is important it
points at the one in the SDK, not on the host system.

The bit I don't understand is whether:

a) the compiler in the SDK is generating the wrong loader (in which
case buildtools-extended-tarball would break which it doesn't)
b) rust is hardcoding some dynamic-linker option somewhere it shouldn't
c) whether the toolchain is relocating paths correctly or some path
isn't relocating and is being used here.

I'd suggest first checking that a binary generated by nativesdk-gcc in
the SDK has the right loader. If that is the case, see what compiler
options are being used to create the build tool and go from there.

FWIW you can see/change the interpreter with patchelf.

Cheers,

Richard


I've tried to narrow this down further and I can say now that this error 
when building the native rust build script is not directly related to 
cargo/rust but to the native gcc compiler shipped in the SDK. I will 
next try to dig down in the gcc build process but before spending time 
there I would like to share my finding and see if someone have ideas.


I have two SDKs one with SDKMACHINE="x86_64" and one with 
SDKMACHINE="i686". I have the hosts gcc compiler installed in them and 
use them to compile a minimal c code example with hello world. The one 
for "x86_64" works well and is using the program interpreter from the 
SDK. The executable compiled and linked

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-25 Thread Richard Purdie 
On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote:
> Hi Richard,
> 
> On 2022-08-25 10:21, Richard Purdie wrote:
> > 
> > > I've tried locally to reproduce something. I've built and tested
> > > genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the
> > > target for the autobuilder. Both tests passes. The failure I see in the
> > > autobuilder logs is that the build script can not be executed. On my
> > > machine I have that file and it can clearly be executed:
> > > 
> > > $ find
> > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
> > > -name build-script-build
> > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > 
> > > $
> > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > 
> > > $ file
> > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > 
> > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
> > > ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
> > > linked, interpreter
> > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
> > > BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux
> > > 3.2.0, with debug_info, not stripped
> > > 
> > > Found one interesting link here
> > > https://github.com/rust-lang/cargo/issues/3553. Unfortunately without
> > > answer. But also checked the interpreter in my build which looks correct?
> > > 
> > > $ readelf -a
> > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
> > > > grep interpreter
> > >     [Requesting program interpreter:
> > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
> > > 
> > > 
> > > So there are some differences between my machine and the autobuilder
> > > setup that I can't get. I would need help here as I'm not that familiar
> > > with the autobuilder setup. Can it still be some host dependency? I'm
> > > running on Ubuntu 22.04. Is it possible to check in a autobuilder setup
> > > if the file 'build-script-build' is present and possible to execute?
> > After staring at this for an hour, I think the pattern is that is it
> > failing on builds with:
> > 
> > SDKMACHINE = "i686"
> > 
> > which probably means the linker isn't linking against the libc and
> > loader in the SDK properly.
> > 
> > (i686 SDK binaries should run on x86_64 hosts since we provide our own
> > loader and libc)
> 
> Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I 
> was able to reproduce. I want to share some weird stuff and see if 
> someone can get a clue for a solution.
> 
> Did same analyze on the build-script-build file as I did on a working one:

As I suspected, the dynamic loader on binaries built using the
toolchain in the SDK isn't working correctly. 

"/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-
linux/lib/ld-linux.so.2"

is the value used at build time. This is supposed to be relocated into
the SDK's install location at runtime.

The question is therefore where is rust getting this value from? You
can specify it to the linker at compile time along the lines of:

-Wl,--dynamic-linker=/path/to/ld-linux.so.2

or it can be the default that comes from toolchain. It is important it
points at the one in the SDK, not on the host system.

The bit I don't understand is whether:

a) the compiler in the SDK is generating the wrong loader (in which
case buildtools-extended-tarball would break which it doesn't)
b) rust is hardcoding some dynamic-linker option somewhere it shouldn't
c) whether the toolchain is relocating paths correctly or some path
isn't relocating and is being used here.

I'd suggest first checking that a binary generated by nativesdk-gcc in
the SDK has the right loader. If that is the case, see what compiler
options are being used to create the build tool and go from there.

FWIW you can see/change the interpreter with patchelf.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169878): 
https://lists.openembedded.org/g/openembedded-core/message/169878
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-25 Thread Peter Bergin 

Hi Richard,

On 2022-08-25 10:21, Richard Purdie wrote:



I've tried locally to reproduce something. I've built and tested
genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the
target for the autobuilder. Both tests passes. The failure I see in the
autobuilder logs is that the build script can not be executed. On my
machine I have that file and it can clearly be executed:

$ find
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
-name build-script-build
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

$
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

$ file
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux
3.2.0, with debug_info, not stripped

Found one interesting link here
https://github.com/rust-lang/cargo/issues/3553. Unfortunately without
answer. But also checked the interpreter in my build which looks correct?

$ readelf -a
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build

grep interpreter

    [Requesting program interpreter:
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]


So there are some differences between my machine and the autobuilder
setup that I can't get. I would need help here as I'm not that familiar
with the autobuilder setup. Can it still be some host dependency? I'm
running on Ubuntu 22.04. Is it possible to check in a autobuilder setup
if the file 'build-script-build' is present and possible to execute?

After staring at this for an hour, I think the pattern is that is it
failing on builds with:

SDKMACHINE = "i686"

which probably means the linker isn't linking against the libc and
loader in the SDK properly.

(i686 SDK binaries should run on x86_64 hosts since we provide our own
loader and libc)


Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I 
was able to reproduce. I want to share some weird stuff and see if 
someone can get a clue for a solution.


Did same analyze on the build-script-build file as I did on a working one:

$ 
/storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build 

-bash: 
/storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build: 
No such file or directory
$ file 
/storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build 

/storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build: 
ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter 
/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-linux/lib/ld-linux.so.2, 
BuildID[sha1]=4c32d67e8597f30ce774e2bb32ea5170b9878957, for GNU/Linux 
3.2.0, with debug_info, not stripped
$ ldd 
/storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build 


    linux-gate.so.1 (0xf7f62000)
    libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf7ecd000)
    libc.so.6 => /lib32/libc.so.6 (0xf7c9c000)
 
/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-linux/lib/ld-linux.so.2
 => /lib/ld-linux.so.2 (0xf7f64000)
$ readelf -a 
/storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build 
| grep interpreter
  [Requesting program interpreter: 
/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-linux/lib/ld-linux.so.2] 



The interpreter is wrong and pointing to a non existing file. It has 
'/usr/local/oe-sdk-hardcoded-buildpath' in its path which seems really 
bad and is equal to SDKPATH variable.


Best regards,
/Peter



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-25 Thread Richard Purdie 
Hi Peter,

On Thu, 2022-08-25 at 09:17 +0200, Peter Bergin wrote:
> On 2022-08-24 10:52, Richard Purdie wrote:
> > On Tue, 2022-08-23 at 10:56 +0200, Peter Bergin wrote:
> > > The test for rust in the SDK is extended with the simplest
> > > possible build script. This will make use of the host toolchain
> > > for building build.rs before building the rust package for target.
> > > 
> > > Signed-off-by: Peter Bergin 
> > > ---
> > >   meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++
> > >   1 file changed, 3 insertions(+)
> > >   create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > > 
> > > diff --git a/meta/lib/oeqa/sdk/files/rust/hello/build.rs 
> > > b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > > new file mode 100644
> > > index 000..b1a533d5dfa
> > > --- /dev/null
> > > +++ b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > > @@ -0,0 +1,3 @@
> > > +/* This is the simplest build script just to invoke host compiler
> > > +   in the build process. */
> > > +fn main() {}
> > This seemed to break everywhere :(
> Not good. :-|
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5773/steps/13/logs/stdio
> > 
> > and many others.
> 
> I've tried locally to reproduce something. I've built and tested 
> genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the 
> target for the autobuilder. Both tests passes. The failure I see in the 
> autobuilder logs is that the build script can not be executed. On my 
> machine I have that file and it can clearly be executed:
> 
> $ find 
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
>  
> -name build-script-build
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>  
> 
> $ 
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>  
> 
> $ file 
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>  
> 
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
>  
> ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically 
> linked, interpreter 
> /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
>  
> BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux 
> 3.2.0, with debug_info, not stripped
> 
> Found one interesting link here 
> https://github.com/rust-lang/cargo/issues/3553. Unfortunately without 
> answer. But also checked the interpreter in my build which looks correct?
> 
> $ readelf -a 
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>  
> > grep interpreter
>    [Requesting program interpreter: 
> /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
>  
> 
> 
> So there are some differences between my machine and the autobuilder 
> setup that I can't get. I would need help here as I'm not that familiar 
> with the autobuilder setup. Can it still be some host dependency? I'm 
> running on Ubuntu 22.04. Is it possible to check in a autobuilder setup 
> if the file 'build-script-build' is present and possible to execute?

After staring at this for an hour, I think the pattern is that is it
failing on builds with:

SDKMACHINE = "i686"

which probably means the linker isn't linking against the libc and
loader in the SDK properly.

(i686 SDK binaries should run on x86_64 hosts since we provide our own
loader and libc)

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169838): 
https://lists.openembedded.org/g/openembedded-core/message/169838
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-25 Thread Peter Bergin 

Hi Richard,

On 2022-08-24 10:52, Richard Purdie wrote:

On Tue, 2022-08-23 at 10:56 +0200, Peter Bergin wrote:

The test for rust in the SDK is extended with the simplest
possible build script. This will make use of the host toolchain
for building build.rs before building the rust package for target.

Signed-off-by: Peter Bergin 
---
  meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++
  1 file changed, 3 insertions(+)
  create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/build.rs

diff --git a/meta/lib/oeqa/sdk/files/rust/hello/build.rs 
b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
new file mode 100644
index 000..b1a533d5dfa
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
@@ -0,0 +1,3 @@
+/* This is the simplest build script just to invoke host compiler
+   in the build process. */
+fn main() {}

This seemed to break everywhere :(

Not good. :-|


https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5773/steps/13/logs/stdio

and many others.


I've tried locally to reproduce something. I've built and tested 
genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the 
target for the autobuilder. Both tests passes. The failure I see in the 
autobuilder logs is that the build script can not be executed. On my 
machine I have that file and it can clearly be executed:


$ find 
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/ 
-name build-script-build
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build 

$ 
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build 

$ file 
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build 

tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build: 
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically 
linked, interpreter 
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2, 
BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux 
3.2.0, with debug_info, not stripped


Found one interesting link here 
https://github.com/rust-lang/cargo/issues/3553. Unfortunately without 
answer. But also checked the interpreter in my build which looks correct?


$ readelf -a 
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build 
| grep interpreter
  [Requesting program interpreter: 
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2] 



So there are some differences between my machine and the autobuilder 
setup that I can't get. I would need help here as I'm not that familiar 
with the autobuilder setup. Can it still be some host dependency? I'm 
running on Ubuntu 22.04. Is it possible to check in a autobuilder setup 
if the file 'build-script-build' is present and possible to execute?


Best regards,
/Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169831): 
https://lists.openembedded.org/g/openembedded-core/message/169831
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-24 Thread Richard Purdie 
On Tue, 2022-08-23 at 10:56 +0200, Peter Bergin wrote:
> The test for rust in the SDK is extended with the simplest
> possible build script. This will make use of the host toolchain
> for building build.rs before building the rust package for target.
> 
> Signed-off-by: Peter Bergin 
> ---
>  meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++
>  1 file changed, 3 insertions(+)
>  create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/build.rs
> 
> diff --git a/meta/lib/oeqa/sdk/files/rust/hello/build.rs 
> b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> new file mode 100644
> index 000..b1a533d5dfa
> --- /dev/null
> +++ b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> @@ -0,0 +1,3 @@
> +/* This is the simplest build script just to invoke host compiler
> +   in the build process. */
> +fn main() {}

This seemed to break everywhere :(

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5773/steps/13/logs/stdio

and many others.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169795): 
https://lists.openembedded.org/g/openembedded-core/message/169795
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] oeqa/sdk: extend rust test to also use a build script

2022-08-23 Thread Peter Bergin 
The test for rust in the SDK is extended with the simplest
possible build script. This will make use of the host toolchain
for building build.rs before building the rust package for target.

Signed-off-by: Peter Bergin 
---
 meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/build.rs

diff --git a/meta/lib/oeqa/sdk/files/rust/hello/build.rs 
b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
new file mode 100644
index 000..b1a533d5dfa
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
@@ -0,0 +1,3 @@
+/* This is the simplest build script just to invoke host compiler
+   in the build process. */
+fn main() {}
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169698): 
https://lists.openembedded.org/g/openembedded-core/message/169698
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-