cross compilation: xxx-config binaries

[bennofs]

Packages that use the xxx-config pattern like pcre or freetype don't work correctly with the current cross-compilation infrastructure:

$ nix build -f. pkgsCross.aarch64-multiplatform.buildPackages.pcre.dev
$ result-dev/bin/pcre-config  --prefix
/nix/store/f9qd7k92z355vjxzyry6dhgq2s7gin3x-pcre-8.42

The output refers to the pcre prefix from buildPackages, but this is not what packages that want to cross compile expect (it would need to refer to the cross-compiled pcre).

[Mic92]

A hack would be to take buildPackages version and replace the strings in it. This would work at least for scripts. For binaries this will not work since the store paths for cross-compiled packages are longer. There we might be able to use a leave a long-enough place holder in the source code that we could replace later.

[bennofs]

Another hack: just replace xxx-config with our own script that just calls pkg-config, and include pkg-config files in the packages?

[Mic92]

That might work for some core libraries but is hard to generalize/maintain and needs to be checked for every upgrade.

[Mic92]

How about that: We add a wrapper that replaces the stdout output on the fly?
The wrapper would take as an input the buildPackage and the native library, it then
forwards all arguments to the build package and performs string substitution on the output.

[matthewbauer]

Most packages that have -config binaries aren't really thinking about how it works with cross compilation. The best way to do this is avoid the binary altogether and use pkgconfig. Many projects have moved to this but some still rely on -config binaries.

But, there's not really a lot Nixpkgs can do here. This is the one case where you want to run the cross-built version. So you should just use:

${pkgsCross.aarch64-multiplatform.pcre.dev}/bin/pcre-config

[Mic92]

You cannot use the cross-build version at buildtime. That's the point. And you cannot just replace -config binaries with pkg-config since they also contain application-specific data that we cannot replace. That's why I proposed a wrapper that takes buildPackages.<package> and replaces its own $out with the $out of the host library on stderr/stdout.

[matthewbauer]

At least in pcre's case you can:

$ nix build -f channel:nixpkgs-unstable pkgsCross.aarch64-multiplatform.pcre.dev
$ ./result-dev/bin/pcre-config --prefix

Usually this is just a bash script. Sometimes it is a binary which makes things more complicated, but not impossible. Those packages will just need depsBuildBuild = [ stdenv.cc ]; & will basically propagate build packages. This is why fc99c33 doesn't work (yet - per-output disallowedReferences might make it possible).

That's why I proposed a wrapper that takes buildPackages

This will mean that we rebuild buildPackages.pcre for every possible target and anything that depends on it. This could get expensive.

And you cannot just replace -config binaries with pkg-config since they also contain application-specific data that we cannot replace.

I think in pcre's case at least, it is safe to use pkg-config. They support both here and lots of packages already do that. Otherwise, they aren't too hard to patch:

https://github.com/LORD-MicroStrain/meta-lord/blob/master/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch

[Ericson2314]

I think we can post-build patch as @Mic92 or patch the original on a case-by-case basis. The pcre-case where they correctly build using CC_FOR_BUILD or whatever is a good model we can point to upstream, but we should probably let them know they should just go straight to using package config too.

In any case, I think upstreaming and upstream dev awareness is a big part of this, as downstream solutions are much worse in this case. I've been trying to push against upstream with the related case of compilers and standard libraries being built together; progress slow but I believe feasible.

[Mic92]

So we should put binaries of the build architecture into to host packages.dev outputs?
This sounds wrong to me. How would you execute the binaries at runtime theme on the cross-compiled system?

[matthewbauer]

Well, dev output is always going to be for the build platform. Header files are for the build platform. It gets messy here of course though.

[Mic92]

What if the host platform needs a dev output?

[Ericson2314]

What does that mean? :)

[bennofs]

You might want to build something natively in the host using cross-compiled dev output?

[Ericson2314]

Oh! Thanks. Yeah that is a big problem with trying to mix builds from different platforms to the same platform.

[Mic92]

This could be also an hack that works at least on linux: NixOS/nix#2561 (comment)
i.e. just emulate the execution of the binary.

[stale]

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:

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

[bennofs]

I don't think this issue has been addressed generally.
.

[Ericson2314]

It's a bummer that the bot doesn't notice that I just mentioned this issue from other threads in the last week.

[stale]

I marked this as stale due to inactivity. → More info

[bennofs]

Still open I think?

[Ericson2314]

This one's gonna be open for like a decade 😂.

[Ericson2314]

I decided to kick of a very idealistic social solution #107647 :).

[stale]

I marked this as stale due to inactivity. → More info

[Artturin]

in #222227
i did

  postPatch = ''
    substituteInPlace Makefile \
      --replace 'PCRE_CONFIG = $(shell which pcre-config)' 'PCRE_CONFIG = $(PKG_CONFIG) libpcre'
  '';

and it works well, just gotta make sure that the options PCRE_CONFIG is called with are available in pkg-config