-
-
Notifications
You must be signed in to change notification settings - Fork 14k
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
cross compilation: xxx-config binaries #51176
Comments
A hack would be to take |
Another hack: just replace xxx-config with our own script that just calls pkg-config, and include pkg-config files in the packages? |
That might work for some core libraries but is hard to generalize/maintain and needs to be checked for every upgrade. |
How about that: We add a wrapper that replaces the stdout output on the fly? |
Most packages that have 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:
|
You cannot use the cross-build version at buildtime. That's the point. And you cannot just replace |
At least in pcre's case you can:
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
This will mean that we rebuild buildPackages.pcre for every possible target and anything that depends on it. This could get expensive.
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: |
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 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. |
So we should put binaries of the build architecture into to host packages.dev outputs? |
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. |
What if the host platform needs a dev output? |
What does that mean? :) |
You might want to build something natively in the host using cross-compiled dev output? |
Oh! Thanks. Yeah that is a big problem with trying to mix builds from different platforms to the same platform. |
This could be also an hack that works at least on linux: NixOS/nix#2561 (comment) |
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:
|
I don't think this issue has been addressed generally. |
It's a bummer that the bot doesn't notice that I just mentioned this issue from other threads in the last week. |
I marked this as stale due to inactivity. → More info |
Still open I think? |
This one's gonna be open for like a decade 😂. |
I decided to kick of a very idealistic social solution #107647 :). |
When we have build == host != target, we don't want to patch in a prefixed pkg-config used for cross compiling. Using `pkgsHostHost` expressses the intent. Then again, per NixOS#51176 leaving `buildPackages.pkg-config` is arguably also correct, if we do further cross compilation and want to run `freetype-config`. Really, there is no good solution.
I marked this as stale due to inactivity. → More info |
in #222227 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 |
Packages that use the
xxx-config
pattern likepcre
orfreetype
don't work correctly with the current cross-compilation infrastructure: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).
The text was updated successfully, but these errors were encountered: