Summary: | sys-libs/zlib: build to work with automatic LFS checker | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Allen Webb <allenwebb> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | allenwebb |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 471102 |
Description
Allen Webb
2023-02-08 23:26:20 UTC
This resolves this issue for me. diff --git a/sys-libs/zlib/zlib-1.2.13-r1.ebuild b/sys-libs/zlib/zlib-1.2.13-r1.ebuild index 73dc294e3..3c0a07df1 100644 --- a/sys-libs/zlib/zlib-1.2.13-r1.ebuild +++ b/sys-libs/zlib/zlib-1.2.13-r1.ebuild @@ -88,6 +88,11 @@ src_prepare() { echoit() { echo "$@"; "$@"; } multilib_src_configure() { + append-lfs-flags + # zlib is using only CFLAGS so append CPPFLAGS (configured by lfs) to it + append-cflags "${CPPFLAGS}" + # We pass manually instead of relying on the configure script/makefile # because it would pass it even for older binutils. use sparc && append-flags $(test-flags-CCLD -Wl,--no-warn-rwx-segments) Please verify this doesn't break ABI. IIRC zlib has its own LFS types so we may be fine, but need to check. unfortunately, append-lfs-flags does break the ABI. more precisely, building zlib source with -D_FILE_OFFSET_BITS=64 breaks it. zlib is quite intelligent when it comes to the standard LFS flags (assuming you don't think the LFS system is a complete dumpster fire and everyone should only use 64-bit interfaces everywhere). z_off_t is the only exported interface that uses off_t. in gzlib.c, a few APIs (e.g. gzseek) are defined in terms of z_off_t. so with a 32-bit ABI that splits values (e.g. arm 32-bit), it means the stack usage & return value are ABI incompatible. annoyingly, the only thing tripping up the checker is the call to open() in gzlib.c, and zlib actually DTRT by using O_LARGEFILE when available. but it's impossible from a symbol analysis pov to determine that, and we'd really need something that decompiles & analysis the opcodes to detect that this particular usage is correct. probably would be easier to patch gzlib.c with: --- a/gzlib.c +++ b/gzlib.c @@ -7,11 +7,14 @@ #if defined(_WIN32) && !defined(__BORLANDC__) && !defined(__MINGW32__) # define LSEEK _lseeki64 +# define OPEN open #else #if defined(_LARGEFILE64_SOURCE) && _LFS64_LARGEFILE-0 # define LSEEK lseek64 +# define OPEN open64 #else # define LSEEK lseek +# define OPEN open #endif #endif @@ -242,7 +245,7 @@ #ifdef WIDECHAR fd == -2 ? _wopen(path, oflag, 0666) : #endif - open((const char *)path, oflag, 0666)); + OPEN((const char *)path, oflag, 0666)); if (state->fd == -1) { free(state->path); free(state); |