Using a multilib gcc within an FHS environment

Hello all,

I’m trying to create an FHS User env for a program that seems to require both 64-bit and 32-bit gcc versions. The general advice to make this run on other linux distros seems to be to install gcc-multilib, but this isn’t a Nix package and hence I’ve been looking at other approaches. There’s some information here about this:

https://nixos.wiki/wiki/Packaging/32bit_Applications

But that seems geared towards creating derivations rather than FHS environments. There also seems to be an --enable-multilib parameter for gcc. This sounds promising, but I’ve tried it in what I think should be a MWE:

{ pkgs ? import <nixpkgs> {}}:

let
  my-pkgs = import <nixpkgs> {
    overlays = [
      (self: super: with self; {
        my-gcc = lowPrio (wrapCC (super.gcc.cc.overrideAttrs(old: {
          configureFlags = old.configureFlags ++ [
            "--enable-multilib"
          ];
        })));
      })
    ];
  };

  fhs = pkgs.buildFHSUserEnv {
    name = "gcc-test";
    targetPkgs = pkgs: with my-pkgs; [
      my-gcc
    ];
    multiPkgs = null;
    profile = "";
    runScript = "echo HELLO";
  };
in fhs.env

And it doesn’t work; it tells me
configure: error: in `/build/build/x86_64-unknown-linux-gnu/32/libgcc': configure: error: C preprocessor "/lib/cpp" fails sanity check

Can anyone guide me towards the correct approach here?

Thanks in advance

Chris

Have you tried using gccMultiStdenv?

1 Like

Thanks - I hadn’t tried it, but I now have and it gets me further along. However, I then get a new error message:
GNU binutils package not found, please install GNU binutils for your Linux distribution
However, if I simply add binutils to the list of packages in the FHS environment, then this seems to take me a step back - the program then starts asking for ctr1.o, which was the original problem that was solved with gccMultiStdenv. Do I also need a 32-bit version of the binutils package?

do you absolutely need a FHS build root?

Possibly not. I’ve been trying the least-effort approach by following some existing guidance:

The software in question (xilinx vivado) is known to be a little clunky and may not necessarily be (eg) respecting environment variables where it should be.

Would you suggest trying to build a derivation instead?

Looking at the documentation, isn’t this what that multiPkgs argument is for? Might not even need that gcc override.

If you’re on x86_64, gcc_multi is used by default in an FHS env.

I’m not familiar with how to use it, but it’s there. See plex: allow use on non-x86 platforms by jonringer · Pull Request #132963 · NixOS/nixpkgs · GitHub