On Thu, 2023-03-02 at 13:18 +0000, Richard Purdie via
lists.openembedded.org wrote:
> On Thu, 2023-03-02 at 12:41 +0100, Alexandre Belloni wrote:
> > On 01/03/2023 10:25:58+0100, Alexandre Belloni via lists.openembedded.org 
> > wrote:
> > > On 28/02/2023 23:45:05+0100, Alexandre Belloni wrote:
> > > > On 28/02/2023 17:50:05+0000, Richard Purdie wrote:
> > > > > On Tue, 2023-02-28 at 08:43 -0800, Khem Raj wrote:
> > > > > > On Tue, Feb 28, 2023 at 8:18 AM Alexandre Belloni
> > > > > > <alexandre.bell...@bootlin.com> wrote:
> > > > > > > 
> > > > > > > Hello Khem,
> > > > > > > 
> > > > > > > As discussed I gave it a go again and got this:
> > > > > > > 
> > > > > > > > /home/pokybuild/yocto-worker/qemuarm/build/build/tmp/hosttools/ld:
> > > > > > > >  linux-tdep.o: in function `linux_corefile_thread(thread_info*, 
> > > > > > > > linux_corefile_thread_data*)':
> > > > > > > > linux-tdep.c:(.text+0x13ac): undefined reference to 
> > > > > > > > `gcore_elf_build_thread_register_notes(gdbarch*, thread_info*, 
> > > > > > > > gdb_signal, bfd*, std::unique_ptr<char, 
> > > > > > > > gdb::xfree_deleter<char> >*, int*)'
> > > > > > > > /home/pokybuild/yocto-worker/qemuarm/build/build/tmp/hosttools/ld:
> > > > > > > >  linux-tdep.o: in function `linux_make_corefile_notes(gdbarch*, 
> > > > > > > > bfd*, int*)':
> > > > > > > > linux-tdep.c:(.text+0x49d7): undefined reference to 
> > > > > > > > `gcore_elf_make_tdesc_note(bfd*, std::unique_ptr<char, 
> > > > > > > > gdb::xfree_deleter<char> >*, int*)'
> > > > > > > > collect2: error: ld returned 1 exit status
> > > > > > > > make[2]: *** [Makefile:2149: gdb] Error 1
> > > > > > > > make[2]: Leaving directory 
> > > > > > > > '/home/pokybuild/yocto-worker/qemuarm/build/build/tmp/work/x86_64-linux/gdb-cross-arm/13.1-r0/build-arm-poky-linux-gnueabi/gdb'
> > > > > > > > make[1]: *** [Makefile:11122: all-gdb] Error 2
> > > > > > > > make[1]: Leaving directory 
> > > > > > > > '/home/pokybuild/yocto-worker/qemuarm/build/build/tmp/work/x86_64-linux/gdb-cross-arm/13.1-r0/build-arm-poky-linux-gnueabi'
> > > > > > > > make: *** [Makefile:1005: all] Error 2
> > > > > > > > ERROR: oe_runmake failed
> > > > > > 
> > > > > > Is this host running updated buildtools tarball after the binutils 
> > > > > > ld
> > > > > > search path fix ?
> > > > > 
> > > > > Yes, it should be.
> > > > 
> > > > Khem, you are probably right that this is host related, this failed
> > > > again on ubuntu2004:
> > > > 
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/6689/steps/14/logs/stdio
> > > > 
> > > > I'm wondering whether this reproduces on master and we have simply been
> > > > lucky.
> > > 
> > > This doesn't reproduce on master on ubuntu2004 so I guess it is really
> > > cause by the binutils upgrade.
> > 
> > I was wrong, it just reproduced on master, debian11-ty-3:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/6730/steps/15/logs/stdio
> > 
> 
> I went digging and the gdb/config.log file shows:
> 
> configure:28568: checking for ELF support in BFD
> configure:28588: ./libtool --quiet --mode=link gcc  -o conftest 
> -I../../gdb-13.1/gdb/../include -I../bfd -I../../gdb-13.1/gdb/../bfd 
> -isystem/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/gdb-cross-aarch64/13.1-r0/recipe-sysroot-native/usr/include
>  -O2 -pipe     
> -isystem/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/gdb-cross-aarch64/13.1-r0/recipe-sysroot-native/usr/include
>  
> -I/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/gdb-cross-aarch64/13.1-r0/recipe-sysroot-native/usr/include
>  -L../bfd -L../libiberty conftest.c -lbfd -liberty  -lncursesw -lm -ldl  >&5
> /home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/hosttools/ld: 
> /home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/gdb-cross-aarch64/13.1-r0/recipe-sysroot-native/usr/lib/libzstd.so:
>  undefined reference to `pthread_join@GLIBC_2.34'
> /home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/hosttools/ld: 
> /home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/gdb-cross-aarch64/13.1-r0/recipe-sysroot-native/usr/lib/libzstd.so:
>  undefined reference to `pthread_create@GLIBC_2.34'
> collect2: error: ld returned 1 exit status
> 
> which is the same issue as we saw previously. 
> 
> The really big difference here is that debian11 doesn't have buildtools
> so this is with the host's ld and libpthread.
> 
> I'm guessing this is a libzstd linked on a more recent system which
> then doesn't work against this older host libc. The one in uninative
> could help and would likely resolve things, but isn't involved at this
> point in a build. Not sure what the right fix is here.

This bug is horrible.

I reran a forced compile on that build and it all worked. Thankfully I
saved off the build directory, before and after and was able to diff
them.

The difference is this in python3.pc in the recipe-sysroot-native:

Libs.private: -ldl 

vs:

Libs.private: -lpthread -ldl  -lutil

which sticks a -lpthread onto the linker command in the configure tests
within gdb so that it can link correctly to libbfd, which then
convinces its that it has elf symbols.

The underlying issue is that particular gdb test appears to strip our
build time LDFLAGS off for the purposes of the test. I'm guessing
something like:


Index: gdb-13.1/gdb/acinclude.m4
===================================================================
--- gdb-13.1.orig/gdb/acinclude.m4
+++ gdb-13.1/gdb/acinclude.m4
@@ -234,7 +234,7 @@ AC_DEFUN([GDB_AC_CHECK_BFD], [
   # points somewhere with bfd, with -I/foo/lib and -L/foo/lib.  We
   # always want our bfd.
   CFLAGS="-I${srcdir}/../include -I../bfd -I${srcdir}/../bfd $CFLAGS"
-  LDFLAGS="-L../bfd -L../libiberty"
+  LDFLAGS="-L../bfd -L../libiberty $LDFLAGS"
   intl=`echo $LIBINTL | sed 's,${top_builddir}/,,g'`
   LIBS="-lbfd -liberty $intl $LIBS"
   CC="./libtool --quiet --mode=link $CC"

would help. There is some irony when you read the comment there. It
looks like it is trying and failing to link to libbfd in the gdb build
anyway rather than one from the host.

I'll have to step away for food and so on shortly so I wanted to brain
dump on what I found so far.

[python3.pc will vary in the native case depending on the host libc so
some libs will be added even if not later needed by uninative]

Cheers,

Richard


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

Reply via email to