Hi Gabor, On 12/22/18 8:29 PM, Gabor Z. Papp wrote: > * Bernhard Voelker <[email protected]>: > > | In general, I'd like to reproduce it myself - AFAIR you cross-compiled on > x86_64 > | for i586, right? What's your ./configure line? > > First of all, I'm working with the released 8.30 tarball, not yet from git. > > Well, no, not exactly. Its a special case, where I "cross compile" on > x86_64 for the same x86_64 arch, but for different (newer) glibc > version. The target glibc version (2.28) is newer than the host/build > version (2.24). > > In this case, when the build job tries to generate the man pages - > executing "utility --help" for the output, the binary will fail at > some utilities, where newer GLIBC_VERSION required than the running > host have. > > Here are some examples: > > 8.30/usr/bin/cp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not > found (required by 8.30/usr/bin/cp) > 8.30/usr/bin/install: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' > not found (required by 8.30/usr/bin/install) > 8.30/usr/bin/ln: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not > found (required by 8.30/usr/bin/ln) > 8.30/usr/bin/mktemp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' > not found (required by 8.30/usr/bin/mktemp) > 8.30/usr/bin/mv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not > found (required by 8.30/usr/bin/mv) > 8.30/usr/bin/shred: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not > found (required by 8.30/usr/bin/shred) > 8.30/usr/bin/shuf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not > found (required by 8.30/usr/bin/shuf) > 8.30/usr/bin/sort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not > found (required by 8.30/usr/bin/sort) > > /lib/x86_64-linux-gnu/libc.so.6 is from the host glibc 2.24, and > 8.30/usr/bin/* are the target binaries, where the $ARCH is same > (x86_64 = x86_64), but glibc version differs (2.24 != 2.28).
This sounds more like bootstrapping a system (a la Linux-from-scratch) than cross-compiling. TBH, I don't know too much about this, but I could imagine that one usually needs to point LD_LIBRARY_PATH to the newer glibc at some point, right? Back to the patch - does the attached work for you? Have a nice day, Berny
>From e22bc6279b9659e39d2e0d8589bc735ea8a2893d Mon Sep 17 00:00:00 2001 From: Bernhard Voelker <[email protected]> Date: Fri, 4 Jan 2019 21:46:14 +0100 Subject: [PATCH] build: use distributed man pages when running with --help fails When building against an incompatible GLIBC version compared to that on the build host, then running the just-built binary might fail although it is the same platform - thus CROSS_COMPILING is false. As a result, generating the man pages fails. * man/local.mk (.x.1): Add a check to verify that running the utility with --help succeeds, otherwise falling back to using 'dummy-man'. --- man/local.mk | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/man/local.mk b/man/local.mk index eee38396c..ee74d1f9b 100644 --- a/man/local.mk +++ b/man/local.mk @@ -191,9 +191,16 @@ endif && $(MKDIR_P) $$t \ && (cd $$t && $(LN_S) '$(abs_top_builddir)/src/'$$prog$(EXEEXT) \ $$argv$(EXEEXT)) \ - && : $${SOURCE_DATE_EPOCH=`cat $(srcdir)/.timestamp 2>/dev/null || :`} \ + || exit 1; \ +## Double-check whether the built binary succeeds with --help as the above +## CROSS_COMPILING condition might have been wrong in some cases, e.g. when +## building against an incompatible glibc version on the same platform. + $$t/$$argv$(EXEEXT) --help </dev/null >/dev/null \ + && run_help2man="$(run_help2man)" \ + || run_help2man="$(srcdir)/man/dummy-man"; \ + : $${SOURCE_DATE_EPOCH=`cat $(srcdir)/.timestamp 2>/dev/null || :`} \ && : $${TZ=UTC0} && export TZ \ - && export SOURCE_DATE_EPOCH && $(run_help2man) \ + && export SOURCE_DATE_EPOCH && $${run_help2man} \ --source='$(PACKAGE_STRING)' \ --include=$(srcdir)/man/$$name.x \ --output=$$t/$$name.1 \ -- 2.20.1
