When running the configure check "checking for ELF support in BFD", LDFLAGS
were not being passed in to libtool. In OE/YP, we need these flags when using
uninative due to the games we play with the dynamic loader.

If a version of libzstd was built against a newer glibc, it would need
newer pthread symbols which it wouldn't find with the system linker. At
runtime this isn't an issue as it would be switched to use uninative but we
pass flags in LDFLAGS to allow this.

The bug is rare to reproduce as it depends on the host libzstd was built
against.

Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
---
 meta/recipes-devtools/gdb/gdb.inc             |  1 +
 .../gdb/gdb/add-misssing-ldflags.patch        | 47 +++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 meta/recipes-devtools/gdb/gdb/add-misssing-ldflags.patch

diff --git a/meta/recipes-devtools/gdb/gdb.inc 
b/meta/recipes-devtools/gdb/gdb.inc
index 18603cc7d43..9457c27f8b7 100644
--- a/meta/recipes-devtools/gdb/gdb.inc
+++ b/meta/recipes-devtools/gdb/gdb.inc
@@ -14,6 +14,7 @@ SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \
            file://0007-Fix-invalid-sigprocmask-call.patch \
            
file://0008-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
            
file://0009-gdbserver-linux-low.cc-Fix-a-typo-in-ternary-operato.patch \
+           file://add-missing-ldflags.patch \
            "
 SRC_URI[sha256sum] = 
"115ad5c18d69a6be2ab15882d365dda2a2211c14f480b3502c6eba576e2e95a0"
 
diff --git a/meta/recipes-devtools/gdb/gdb/add-misssing-ldflags.patch 
b/meta/recipes-devtools/gdb/gdb/add-misssing-ldflags.patch
new file mode 100644
index 00000000000..9385aa99c66
--- /dev/null
+++ b/meta/recipes-devtools/gdb/gdb/add-misssing-ldflags.patch
@@ -0,0 +1,47 @@
+When running the configure check "checking for ELF support in BFD", LDFLAGS
+were not being passed in to libtool. In OE/YP, we need these flags when using
+uninative due to the games we play with the dynamic loader.
+
+If a version of libzstd was built against a newer glibc, it would need
+newer pthread symbols which it wouldn't find with the system linker. At
+runtime this isn't an issue as it would be switched to use uninative but we
+pass flags in LDFLAGS to allow this.
+
+The comments say LDFLAGS are used but it was dropped in this commit:
+
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5218fa9e8937b007d554f1e01c2e4ecdb9b7e271
+
+and probably needs to be put back upstream.
+
+The bug is rare to reproduce as it depends on the host libzstd was built
+against.
+
+Upstream-Status: Pending
+Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
+
+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"
+Index: gdb-13.1/gdb/configure
+===================================================================
+--- gdb-13.1.orig/gdb/configure
++++ gdb-13.1/gdb/configure
+@@ -28561,7 +28561,7 @@ WIN32LIBS="$WIN32LIBS $WIN32APILIBS"
+   # 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"
-- 
2.38.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178064): 
https://lists.openembedded.org/g/openembedded-core/message/178064
Mute This Topic: https://lists.openembedded.org/mt/97421656/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