fix pkg-config handling to make cross-compiling work #4430
Conversation
When cross-compiling, it is common to set the PKG_CONFIG env var to a custom pkg-config that knows about the target. Make sure we respect that just like the standard pkg-config tools suggest (pkg.m4). If it isn't set, we use the same default as today -- "pkg-config".
The current code always sets PKG_CONFIG_PATH to build paths in / which breaks cross-compiling -- things like /usr/lib are for the build system (e.g. x86) and not for the target (e.g. arm). Since we're adding paths that are already the default for pkg-config, there's no point in trying to be smart here. Just punt the code. This basically reverts commit 101beb9.
|
This breaks every travis build because it can not find freetype (although it works in a conda env on arch both with and without their freetype package). I think travis is a pretty 'standard' ubuntu set up so if it does not compile there it probably won't compile on most user systems. @cgohlke @jbmohler How badly does this break windows? @jenshnielsen @efiring Does this work on mac? This PR may require (significant?) documentation on how to 'properly' set up compilers on more-or-less every system. |
|
It looks like this removes the fallbacks for when pkg-config isn't found. We definitely need that, because we can't depend on pkg-config being there -- we only want to use it (and give it preference) if it's there and working. |
…able If we have pkg-config, then there's no need to hardcode the system -I/-L paths as the pkg-config files will give us all the info we need.
|
i didn't touch the pkg-config fallbacks. the 3rd patch dropped the -I/-L system paths which were always applied. i guess the travis system is broken, but whatever -- i've reworked the 3rd patch so it adds those hardcodes only when pkg-config is not available. |
|
I actually don't know if pkg-config is installed on travis or not, that is probably something we should check and make sure it is not installed as that is the profile that is going to provide a bigger pain point for us. |
|
Closing as unlikely to be still relevant. Feel free to re-open if I'm mistaken... |
|
commit 64d8ac6 was merged later which was basically the same as my first commit (although mine used fewer loc). shrug the other two patches are still relevant. i've rebased them now. |
|
looks like i don't have the ability to re-open. maybe only project members can do that. |
|
Strange, I can't either. Go ahead and open a new PR, then. |
|
I can't re-open either. I suspect it won't let you re-open if it conflicts? But a new PR against master would be easiest. Sorry to create an inconvenience; I am just trying to weed through old PRs... |
|
np. i've moved this to #11218 now. |
|
If you have force-pushed to a branch you can not re-open. |
This series cleans up the pkg-config logic so that cross-compile works properly. There's still some weirdness with the use of freetype-config/libpng-config, but I've ignored that as it only impacts the display and not the actual config/code generation.