perlPackages.Po4a affects g++

JohnAZoidberg commented 5 years ago

Issue description

Adding perlPackages.Po4a changes which g++ is used. I encountered it when trying to write a derivation which requires the po4a-translate command. But when I add perlPackages.Po4a to the nativeBuildInputs the C++ compiler is different and the project won't build anymore. Can be reproduced in the nix-shell as well.

Steps to reproduce

$ readlink -f $(which g++)
/nix/store/w2px3blinprrzx6wva8x7m0l9l27jzj9-gcc-wrapper-7.4.0/bin/g++
$ nix-shell -p perlPackages.Po4a
$ readlink -f $(which g++)
/nix/store/y60j0zq2j50iaaqjn39i18hkhp277zfy-gcc-wrapper-7.4.0/bin/g++

Technical details

system: "x86_64-linux"
host os: Linux 5.0.7, NixOS, 19.09pre177249.dfd8f84aef1 (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.2.2
nixpkgs: /nix/store/vw34y7p1zml11w2cdsj4a6afgkj2w4pw-source

My version of NixOS is equivalent to this tree of nixpkgs-unstable.

LnL7 commented 5 years ago

I don't think that's the problem, user-env-packages only affects nix-env/systemPackages. Without that nix-shell and builds are still affected by the propagated compiler (or other build tools).

JohnAZoidberg commented 5 years ago

How could I work around this? (In the context of using it as nativeBuildInputs)

JohnAZoidberg commented 5 years ago

The closure is (notice how there's no gcc):

$ nix-closure $(nix-build '<nixpkgs>' -A perlPackages.Po4a)
/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27
/nix/store/7yjxqw8187sj0py0vixnnfwjprgq9m32-attr-2.4.48
/nix/store/dlqjzmrdlp3vipfwyfz2n39cpf1ad2j6-acl-2.2.53
/nix/store/baylddnb83lh45v3fz15ddhbpxbdb7m7-coreutils-8.31
/nix/store/7750im9ysip9hmc1j8xkcaqy6j14bhsr-perl-5.28.1
/nix/store/44marm0sy7lfisarzgfnxsjzvd12q1j2-perl5.28.1-SGMLSpm-1.1
/nix/store/5lyvydxv0w4f2s1ba84pjlbpvqkgn1ni-linux-headers-4.19.16
/nix/store/s3f5sqsm4mfigpkz6cmi99i24yng5msr-perl5.28.1-MIME-Charset-1.012.2
/nix/store/7g3li1crggcg36rn684zbxiva1i184sm-perl5.28.1-Unicode-LineBreak-2019.001
/nix/store/886w5d5zwg0p6ggbz5vwyk4aiqgsdzgw-perl5.28.1-TermReadKey-2.38
/nix/store/j4fz5m9si39qvns44zcwdya5zpdlhz58-perl5.28.1-Module-Build-0.4224
/nix/store/f5wl80zkrd3fc1jxsljmnpn7y02lz6v1-glibc-2.27-bin
/nix/store/qaybsxbkg4n19lfh2p59a3q6sgzi7ndn-perl5.28.1-Text-CharWidth-0.04
/nix/store/sr4253np2gz2bpha4gn8gqlmiw604155-glibc-2.27-dev
/nix/store/kpzpklf8d4dl16r2n5xzl6qapdf9636q-perl5.28.1-Text-WrapI18N-0.06
/nix/store/pjg2pmk1zh5l1cc3kb67xc68s4n9b0w4-perl5.28.1-gettext-1.07
/nix/store/yjkch3aia9ny4dq42dbcjrdwqb1y8c33-bash-4.4-p23
/nix/store/9pihd9jvw7xnvq3vsdz0h48f34q60vzi-perl5.28.1-po4a-0.47

When I force configure to ignore the wrong gcc it fails during the compilation with the same error as in #28748 (missing <stdlib.h>). I can't remove glibc in the inputs of my project since it's not there. But that must mean the glibc in the closure of perlPackages.Po4a is the problem.

I can build my derivation if I add just the binaries to the path:

  preConfigure = ''
    export PATH="${perlPackages.Po4a}/bin:$PATH"
  '';

stale[bot] commented 4 years ago

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

Search for maintainers and people that previously touched the related code and @ mention them in a comment.
Ask on the NixOS Discourse.
Ask on the #nixos channel on irc.freenode.net.

NixOS / nixpkgs