Re: coreutils 8.30 "bootstap"

[Gabor Z. Papp]

* Bernhard Voelker <address@hidden>:

| 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" <address@hidden>:
| >
| > | 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