* Bernhard Voelker <m...@bernhard-voelker.de>: | 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). Thats, why I have to find another way to generate the man pages, instead of processing "utility --help" output with help2man, right after compiling the new binaries. (Or executing an utility that not requires newer GLIBC_VERSION than the build host have). Citating from the patch: ## Double-check whether the built binaries are executable on the build host ## as the above CROSS_COMPILING condition might have been wrong in some cases. As you see, the built binaries not always are executable on the build host, even the $ARCH match on both host and target. Merry Xmas! Leaving the rest of the mail untouched - top quoting rules ;-) | Another nits below: | > Greetings, Gabor | > | > * "Gabor Z. Papp" <g...@papp.hu>: | > | > | Attaching the new version of patches. Please submit. | > | diff -urN archive/8.30/configure.ac src/8.30/configure.ac | > | --- archive/8.30/configure.ac 2018-05-14 06:20:24.000000000 +0200 | > | +++ src/8.30/configure.ac 2018-08-17 12:38:31.289457659 +0200 | > | @@ -617,7 +617,15 @@ | > | | > | AC_SUBST([built_programs], [$optional_bin_progs]) | > | | > | -AM_CONDITIONAL([CROSS_COMPILING], [test "$cross_compiling" = yes]) | > | +AC_MSG_CHECKING([whether built binary fails to run on this host (cross-compiling?)]) | > | +AC_RUN_IFELSE([AC_LANG_SOURCE([[int main() { return 0; }]])], | > | +[cu_cross_compiling=no], | > | +[# Assume we are cross-compiling if this trivial program fails. | > | +cu_cross_compiling=yes], | > | +[cu_cross_compiling=yes]) | > | +AM_CONDITIONAL([CROSS_COMPILING], | > | + [test "$cross_compiling" = yes || test "$cu_cross_compiling" = yes]) | > | +AC_MSG_RESULT([$cu_cross_compiling]) | > | | > | ############################################################################ | > | | > | diff -urN archive/8.30/man/local.mk src/8.30/man/local.mk | > | --- archive/8.30/man/local.mk 2018-05-14 06:20:24.000000000 +0200 | > | +++ src/8.30/man/local.mk 2018-08-20 12:04:32.008426334 +0200 | > | @@ -181,6 +181,11 @@ | > | test) prog='['; argv='[';; \ | > | *) prog=$$name; argv=$$prog;; \ | > | esac; \ | > | +## Double-check whether the built binaries are executable on the build host | > | +## as the above CROSS_COMPILING condition might have been wrong in some cases. | > | + run_help2man="$(run_help2man)"; \ | > | + $(abs_top_builddir)/src/df$(EXEEXT) 2>/dev/null \ | > | + || run_help2man="$(srcdir)/man/dummy-man"; \ | > | ## Note the use of $$t/$*, rather than just '$*' as in other packages. | > | ## That is necessary to avoid failures for programs that are also shell | > | ## built-in functions like echo, false, printf, pwd. | df is maybe not a good choice as it might fail with some remote file system | not being available (e.g. NFS hang). Therefore, I'd prefer to use something | more innocent ... maybe like printf? While at it, the standard output of | that command should be redirected to /dev/null as well. And the indentation | of '|| run_help2man="..."' is odd. | Finally, the patch will need a nice commit message, and - as the change is | visible to the (build) user - warrants a NEWS entry. | I would all do this for you, but as mentioned above I really need to reproduce | the old and new behavior here. | Have a nice day, | Berny