libtool: fix /usr/bin/file impurity affecting cross-compilation

[ghost]

Problem

libtool's libtool.m4 script assumes that file is available, and can be found at /usr/bin/file (this path is hardwired). This fails for sandboxed builds. Furthermore, the script with this assumption is vendored into the ./configure scripts of an enormous number of packages.

Solutions

Oftentimes the fact that /usr/bin/file does not exist will not prevent a package from building. When it does prevent a successful build, there are a few options:

1. set NIX_REDIRECT=/usr/bin/file=${file}/bin/file

2. fix libtool.m4 in the libtool package

   a. ... and use autoreconfHook manually in packages which need it (and do not break when autoreconf'ed with the latest autotools).

3. Add substituteInPlace ./configure --replace /usr/bin/file ${file}/bin/file in one of these ways:

   a. in setup.sh's fixLibtool(), which exists for the same reason: impurities in pervasively-vendored libtool.m4

   b. manually to packages which need it

There are already 36 packages in nixpkgs which use 3(b).

Implementation

This commit makes two changes:

• It implements 2 with a substituteInPlace in the libtool expression, to allow 2(a) where possible.

• It implements 3(b) by adding a top-level expression fixPathToUsrBinFileInConfigureScript which implements the third approach, patterned after autoreconfHook.

If there is some way to cleverly get stdenv to inject fixPathToUsrBinFileInConfigureScript as an extra nativeBuildInput only when cross-compiling to certain hostPlatforms, I would like to include that in this PR. However I had a very hard time finding an appropriate place to add that. Suggestions are welcome. I tried adding it to pkgs/stdenv/cross/default.nix in extraNativeBuildInputs, where there is a similar workaround for cross-compiling to windows, but this didn't seem to work.

(Immediate) Motivation

When cross-compiling a libtool.m4-derived package to {x86_64, powerpc, s390, sparc, mips64*}-linux, x86_64-kfreebsd, *-solaris, *-irix, and *-hpux, the configure script will fail to generate shared libraries if file is not callable via /usr/bin/file. It seems that cross-compilations to darwin, riscv, and arm64 hosts are among the few exceptions to this issue, which is why nixpkgs hasn't encountered it until now.

This is currently preventing the generation of Hydra-built bootstrap-files for mips64el-linux-gnuabi64, and will affect almost any other new platform we try to bootstrap on.

The build of the pcre package (and a few others) emits these lines when its configure script is run:

  ./configure: line 9843: /usr/bin/file: No such file or directory
  ./configure: line 9851: /usr/bin/file: No such file or directory
  ./configure: line 9859: /usr/bin/file: No such file or directory
  ...
  checking whether to build shared libraries... no

The build does not fail until much later, when make-bootstrap-files.nix tries to make a copy libpcre.so, which was never built.

This commit allows the mips64el-linux-gnuabi64 bootstrap-files to be built in a sandbox (as required by Hydra) by implementing the two changes above, adding autoreconfHook to gmp and pcre, and fixPathToUsrBinFileInConfigureScript to mpfr (since mpfr breaks if autoreconf'ed with the latest autotools); this was verified with:

  nix-build \
    --option sandbox true \
    --option fallback false \
    pkgs/top-level/release-cross.nix \
    -A bootstrapTools.mips64el-linux-gnuabi64.build

Things done

• Built on platform(s)
  • x86_64-linux
  • mips64el-linux-gnuabi64 cross from x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

[ghost]

I would appreciate a review of this line in particular. I think of libtool as being a "compiler-like" package that has a targetPlatform but I'm not sure if nixpkgs thinks of it this way. Please let me know if I should change this from build==target to build==host.

[ghost]

@ofborg build hey-ofborg-you-build-them-bootstrapballs-now

[ghost]

@ofborg build hey-ofborg-you-build-them-bootstrapballs-now

Woo hoo!

[ghost]

I tried adding it to pkgs/stdenv/cross/default.nix ... but this didn't seem to work.

Okay, I figured out how to make this work. See #166879.

I prefer #166879 one over this PR, but I need to finish testing it first, and even if it works it probably needs to wait until the 22.05 branch-off (did that happen already?) and then go into staging since it messes around with the internals of stdenv. I don't want to be the guy who broke the builds a month before a release.

[ghost]

2. fix libtool.m4 in the libtool package

This has been fixed upstream in libtool 2.4.7.

However this still does not solve the problem of the fact that the old libtool.m4 is already vendored into an immense number of packages, some of which will not autoreconf properly with the latest version.

[ghost]

Marking this as draft in favor of #166879, which is going to be way more maintainable in the long run. If that PR is totally unacceptable we can revisit this one instead.