Bug 12596

Summary:	host-e2fsprogs: tune2fs incompatibility on older glibc version
Product:	buildroot	Reporter:	Ryan Barnett <ryan.barnett>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	buildroot
Priority:	P5
Version:	2019.02.9
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:

Description Ryan Barnett 2020-03-02 21:00:01 UTC

When host-e2fsprogs is selected and build as part of a buildroot configuration on a host system which has a glibc version >= 2.25, the tune2fs command will require a glibc version >= 2.25. This is an issue if an SDK is created and then later run onto a system which has a glibc version < 2.25 as there will be error such as:

tune2fs: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.25 not found (required by /opt/br-sdk/lib/libblkid.so.1)

This can be reproduced using the following a Ubuntu 18.04 host to build an SDK from the following configuration:

BR2_x86_i686=y
# BR2_COMPILER_PARANOID_UNSAFE_PATH is not set
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="https://toolchains.bootlin.com/downloads/releases/toolchains/x86-i686/tarballs/x86-i686--glibc--stable-2018.11-1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_1=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
# BR2_TARGET_ENABLE_ROOT_LOGIN is not set
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_TARGET_GENERIC_GETTY is not set
# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
# BR2_ENABLE_LOCALE_PURGE is not set
# BR2_PACKAGE_BUSYBOX is not set
# BR2_PACKAGE_IFUPDOWN_SCRIPTS is not set
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_TARGET_GENERIC_GETTY is not set
# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
# BR2_ENABLE_LOCALE_PURGE is not set
# BR2_PACKAGE_BUSYBOX is not set
# BR2_PACKAGE_IFUPDOWN_SCRIPTS is not set
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_E2FSPROGS=y

Then run:

make sdk

After the SDK is created, utilize an Ubuntu 16.04 machine to extract the SDK tar.gz file and run:

cd <br-sdk>
./relocate-sdk.sh
./sbin/tune2fs --help

However, if the SDK was created on a Ubuntu 16.04 and relocated to Ubuntu 18.04, then tune2fs will work fine. 

What are the options for forcing e2fsprogs to compile/work with the older version of glibc?

Comment 1 romain.naour 2020-03-02 21:35:31 UTC

Hi Ryan,

I'm not sure we can do anything. Glibc guaranties only old binaries compatible with newer version of Glibc. If you build an application with newer glibc symbols than the version available in your host, it's not going to work.

For example, linaro toolchains needs glibc >= 2.14 because of API changes to glibc’s memcpy API [1]

I guess it's a similar problem here for Glibc 2.25...

[1] https://releases.linaro.org/components/toolchain/binaries/latest-7/

Best regards,
Romain

Comment 2 Ryan Barnett 2020-03-02 21:54:47 UTC

Hi Romain,

Thank you for the prompt reply.

Based on what you said, in order to solve the problem buildroot would need to support specify a custom "host" toolchain which would be used to compile all of the host binaries?

I'd imagine that would be outside of the scope of what buildroot is designed to do. 

Thanks,
-Ryan

Comment 3 romain.naour 2020-03-03 21:38:25 UTC

(In reply to Ryan Barnett from comment #2)
Hi Ryan,

I would recommend to build your SDK from ubuntu 16.04 and deploy it to ubuntu 18.04 or later. It's far easier than building a host native toolchain ;)

Best regards,
Romain

Comment 4 Thomas Petazzoni 2020-05-18 06:45:31 UTC

Unfortunately, this is not something that we can really solve. You have to build your SDK in a host that is equal or older to the host machines where the SDK will be used.

https://stackoverflow.com/a/2858996/643208 has a possible solution, but it requires making ugly changing to the source code of packages.

https://stackoverflow.com/a/52550158/643208 proposes to build your own glibc.

Hm, https://github.com/wheybags/glibc_version_header seems interesting though, but it says that it doesn't work for C++, "If you want C++, you'll need to build libstdc++ with this enabled. That can be a little involved, but I'm working on a solution, to be available "soon"".

pthread also might be causing problems, you must use -pthread and not -lpthread.

So, this seems like a potential source of great pain :-/