libtool,libtool_1_5: don't fix libtool

[alyssais]

Description of changes

For the same reason we disable shebang patching in these derivations, we want to disable the patching of libtool scripts stdenv does.

Otherwise, libtool will install scripts into other packages that are already "fixed", but for the environment libtool was built in. These scripts won't be fixed properly by stdenv anymore, because it will think they were already fixed.

This fixes the build of pkgsStatic.libwebp, which was failing because its libtool script wasn't being patched properly.

Another problem "fixing" the scripts in the libtool package would cause is that package tarballs generated on NixOS would contain libtool scripts that didn't make sense on other distros.

I've tested this change by building pkgsStatic.libwebp, which now works, as well as by testing the build of the bootstrap files and Nix for mips64el to make sure that didn't regress from 97c4382 ("fixLibtool(): patch ./configure, add file to common-path.nix").

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• 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/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

cc @amjoseph-nixpkgs

[ghost]

as well as by testing the build of the bootstrap files and Nix for mips64el to make sure that didn't regress from 97c4382 ("fixLibtool(): patch ./configure, add file to common-path.nix").

Thanks for checking this.

97c4382 is only needed for dealing with packages that vendor pieces of libtool older than 1.4.7 (which is still a lot of software). So it is definitely safe to disable it for libtool 1.5.

I'm re-running the mips64el bootstrap with this commit. It will take a day or two to finish but I don't expect any problems.

[alyssais]

I'm re-running the mips64el bootstrap with this commit. It will take a day or two to finish but I don't expect any problems.

@amjoseph-nixpkgs, we good to go? :)

[ghost]

@amjoseph-nixpkgs, we good to go? :)

I think so. My build has not finished, but I don't want to hold things up here. All of my mipsen are busy doing builds based on #180223 right now. That PR will commit a bootstrap-files hash for mips64el which does not include this PR. So if this PR causes problems (very unlikely) dealing with it won't require a new bootstrap-files.

I think this PR should merge.

[Mindavi]

Interesting, the description and changes make sense. Indeed it seems like a good idea to not 'fix' the scripts at the wrong point in time 😄.

(I should try out 'cross-compiling' from x86_64 to x86_64 sometime, I remember it was failing before and rereading the commit that caused this fixup reminds me that it should be fixed)

[ghost]

I have a bit more time now and was able to look at this more closely than "won't break anything"...

Otherwise, libtool will install scripts into other packages that are already "fixed", but for the environment libtool was built in.

Just to be clear, the problematic "fixing" you refer to is NIX_LDFLAGS and sys_lib_search_path introduced in f1166e0, not the s_/usr/bin/file_file_g introduced in 97c4382, right?

97c4382 has no effect on libtool>=2.4.7; it's a no-op. When it does have an effect, that effect is independent of the build environment. If fixLibtool() needs to be disabled in other places due to "build environment contamination" we should probably make it possible to disable it separately from the s_/usr/bin/file_file_g fix, since the latter does not cause contamination.

I overlooked the case of libtool_1_5, but I don't think it's worth addressing. libtool_1_5 isn't used by anything in nixpkgs other than a single maintainerless package of Canon i686 binary printer drivers. Perhaps the time to retire libtool_1_5 draws near? If not, its fetchurl banner should be removed.

[ghost]

I overlooked the case of libtool_1_5, but I don't think it's worth addressing.

Happily, libtool 1.5 is actually too old to have the /usr/bin/file impurity -- at least on mips. That was introduced in 5f7f7d9615bf650cf99d581a33b3e18357f79951, around libtool 2.4.2-ish in 2013.

Older versions of libtool like libtool-1.5 don't try to be clever and detect the linker flags; they just let the linker decide. This is exactly what we want. Since nixpkgs builds a separate linker binary for each target instead of trying to share a linker for multiple targets, our linkers always have enough information to make the correct choice.

So, retroactively,

we good to go?

We good. :)

[alyssais]

Just to be clear, the problematic "fixing" you refer to is NIX_LDFLAGS and sys_lib_search_path introduced in f1166e0, not the s_/usr/bin/file_file_g introduced in 97c4382, right?

Correct.