Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cc-wrappers should unconditionally provide target prefixed tools ${target}-gcc to shadow unwrapped bianries. #178802

Open
trofi opened this issue Jun 23, 2022 · 3 comments
Labels
0.kind: bug Something is broken

Comments

@trofi
Copy link
Contributor

trofi commented Jun 23, 2022

Noticed the unwrapped binary leak in when built enchant1 with config.configurePlatformsByDefault = true; (pass --host= for native builds). There linkage fails because CC=x86_64-unknown-linux-gnu-gcc points to unwrapped binary:

$ ls /nix/store/5k57n0irf29smr12ib721dzh2ffqwlp6-gcc-wrapper-13.0.0/bin
as  c++  cc  cpp  g++  gcc  ld  ld.bfd  ld.gold  strip
$ ls /nix/store/fzwli194jbp7dv9s874sd6pn318q6h3c-gcc-13.0.0/bin
c++  g++  gcc-ar  gcc-ranlib  gcov-dump  lto-dump                      x86_64-unknown-linux-gnu-g++  x86_64-unknown-linux-gnu-gcc-13.0.0  x86_64-unknown-linux-gnu-gcc-nm
cpp  gcc  gcc-nm  gcov        gcov-tool  x86_64-unknown-linux-gnu-c++  x86_64-unknown-linux-gnu-gcc  x86_64-unknown-linux-gnu-gcc-ar      x86_64-unknown-linux-gnu-gcc-ranlib

--host=${target} effectively flips CC from gcc-wrapper to gcc. I'm surprised there is that little breakage. I'd say gcc-wrapper should always provide both gcc (& co) and ${target}-gcc (& co).

Proposal: install ${target}-gcc for native wrappers along with gcc.

Optionally we can disable unprefixed tools as suggested by the TODO:

# TODO(@Ericson2314) Make unconditional, or optional but always true by
# default.
targetPrefix = lib.optionalString (targetPlatform != hostPlatform)
(targetPlatform.config + "-");
. But that will surely be a big breaking change. Better guard it under a flag initially.

@trofi trofi added the 0.kind: bug Something is broken label Jun 23, 2022
@trofi
Copy link
Contributor Author

trofi commented Jun 23, 2022

/cc @Ericson2314

@trofi
Copy link
Contributor Author

trofi commented Jul 16, 2022

I'll ignore binutils-wrappers for now.

here our current sets of files typically present in various packages and their wrappers (picking a simple example):

$ nix-shell --pure -A lv

# unwraped binutils tools:
$$ ls /nix/store/f0rrfmf8kh5bsiql5bbq7m4h3xgihpnx-binutils-2.38/bin/
addr2line  ar  as  c++filt  dwp  elfedit  gprof  ld  ld.bfd  ld.gold  nm  objcopy  objdump  ranlib  readelf  size  strings  strip

# wrapped binutils tools (not normally used directly)
$$ ls /nix/store/5fly14l1fc49v395rn2jcp8aq6ndcb5v-binutils-wrapper-2.38/bin
as  ld  ld.bfd  ld.gold  strip

# unwrapped gcc tools:
$$ /nix/store/zs6hnk47hcrrcrd885d66xmhlvp05jxm-gcc-11.3.0/bin
c++  g++  gcc-ar  gcc-ranlib  gcov-dump  lto-dump                      x86_64-unknown-linux-gnu-g++  x86_64-unknown-linux-gnu-gcc-11.3.0  x86_64-unknown-linux-gnu-gcc-nm
cpp  gcc  gcc-nm  gcov        gcov-tool  x86_64-unknown-linux-gnu-c++  x86_64-unknown-linux-gnu-gcc  x86_64-unknown-linux-gnu-gcc-ar      x86_64-unknown-linux-gnu-gcc-ranlib

# wrapped gcc tools:
$$ ls /nix/store/d7d0ccp06rblhwk9sqnqn4lynijbjgv6-gcc-wrapper-11.3.0/bin
as  c++  cc  cpp  g++  gcc  ld  ld.bfd  ld.gold  strip

For simplest cases we can wrap not just ${tool}, but also check if ${target}-${tool} is present and wrap that.

@trofi
Copy link
Contributor Author

trofi commented Jul 16, 2022

Proposed fix as #181724. Fixes at least radare2.

trofi added a commit to trofi/nixpkgs that referenced this issue Jul 16, 2022
In NixOS#87909 ("stdenv: always
pass --build, --host to configure") we noticed that stdenv.cc
exposes `c++` as a wrapped bianry and `x86_64-unknown-linux-gnu-c++`
as unsrapped binary.

As a result `x86_64-unknown-linux-gnu-c++` was not able to create
basic bianries. This makes seepingly no-op `--host=x86_64-unknown-linux-gnu`
option for `./configure` a breaking change.

This change adds wrappers to prefixed binaries for cross and
native cases where such an inconsistency exists. New validation
change will catch new possible inconsistencies. It already caught
existing inconsistencies in: `gcc`, `gfortran`, `gcj`, `gccgo`, `gdc`,
`clang`.

At least `radare2` build is fixed by consistent wrappers. It used to fail
before as:

    radare2> ERROR: x86_64-unknown-linux-gnu-gcc cannot create executables

Issue: NixOS#178802
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: bug Something is broken
Projects
None yet
Development

No branches or pull requests

1 participant