From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/binutils: build host binutils w/o debuginfod
Date: Mon, 19 Oct 2020 22:14:52 +0200 [thread overview]
Message-ID: <20201019201452.GI3466@scaer> (raw)
In-Reply-To: <20201019170533.3297066-1-egorenar@linux.ibm.com>
Alexander, All,
On 2020-10-19 19:05 +0200, Alexander Egorenkov spake thusly:
> Since version 2.34 binutils enables debuginfod support
> by default if the debuginfod library is present on the host.
> This leads to a problem with host-openssl's libcrypto and hosts's
> libk5crypto which are both linked by the host's libdebuginfod and
> are incompatible.
>
> This behavior has been observed on Fedora 32 which ships libdebuginfod.
>
> $ nm -D /lib64/libk5crypto.so.3 | grep 'U EVP_KDF_ctrl'
> U EVP_KDF_ctrl
>
> $ ldd $BUILD_DIR/host/bin/s390x-buildroot-linux-gnu-objdump
> linux-vdso.so.1 (0x00007ffd7ed9b000)
> libz.so.1 => $BUILD_DIR/host/lib/libz.so.1 (0x00007f7ad0dcd000)
> libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007f7ad0da1000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f7ad0d9a000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f7ad0bd0000)
> libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f7ad0b3c000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f7ad0de9000)
> libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f7ad0b10000)
> libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f7ad0aec000)
> libssh.so.4 => /lib64/libssh.so.4 (0x00007f7ad0a7a000)
> libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f7ad0a67000)
> libssl.so.1.1 => $BUILD_DIR/host/lib/libssl.so.1.1 (0x00007f7ad09d8000)
> libcrypto.so.1.1 => $BUILD_DIR/host/lib/libcrypto.so.1.1 (0x00007f7ad0718000)
> libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f7ad06c1000)
> libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f7ad05d4000)
> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f7ad05bb000)
> libcom_err.so.2 => $BUILD_DIR/host/lib/libcom_err.so.2 (0x00007f7ad05b5000)
> libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f7ad0563000)
> liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f7ad0551000)
> libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f7ad0543000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7ad051f000)
> libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f7ad039a000)
> libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f7ad0388000)
> libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f7ad0381000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f7ad0367000)
> libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f7ad0345000)
> libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f7ad0322000)
> libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f7ad02f5000)
> libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f7ad02ba000)
> libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f7ad0221000)
>
> $ $BUILD_DIR/host/bin/s390x-buildroot-linux-gnu-objdump
> qemu-s390x/host/bin/s390x-buildroot-linux-gnu-objdump: symbol lookup error: /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b
>
> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
I've reworked the commit log to include more details about the
dependency chain and how the issue arises, and with an easy reproducer.
Thanks for the investigations, and for your help on IRC! :-)
Regards,
Yann E. MORIN.
> ---
> package/binutils/binutils.mk | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
> index 461bc2b838..6ae4605d86 100644
> --- a/package/binutils/binutils.mk
> +++ b/package/binutils/binutils.mk
> @@ -93,6 +93,7 @@ HOST_BINUTILS_CONF_OPTS = \
> --enable-static \
> --with-sysroot=$(STAGING_DIR) \
> --enable-poison-system-directories \
> + --without-debuginfod \
> $(BINUTILS_DISABLE_GDB_CONF_OPTS) \
> $(BINUTILS_EXTRA_CONFIG_OPTIONS)
>
> --
> 2.26.2
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2020-10-19 20:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 17:05 [Buildroot] [PATCH 1/1] package/binutils: build host binutils w/o debuginfod Alexander Egorenkov
2020-10-19 20:14 ` Yann E. MORIN [this message]
2020-10-29 16:04 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201019201452.GI3466@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox