-
Notifications
You must be signed in to change notification settings - Fork 710
--extra-include-dirs and --extra-lib-dirs not respected when building Setup itself #1378
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
Comments
I see that the setup wrapper, as it's called, exists only under cabal-install and not as part of the Cabal library. That means some unfortunate abstraction violation to make this work, which is probably why it hasn't happened yet. That's kinda too bad. Since I have no expectation that this patch will be accepted, I'm just going to violate that abstraction. If you want code submissions to comply to your standards, you need to review them before they bitrot, not make people wait for literally years without even looking at it. |
The errors look like this, for example:
|
By the way, the dance to get things to build if you happen to be unfortunate enough to be testing this on Mac OS X 10.9 is:
The usual mechanisms that make everything in this repo use itself as the build manager, rather than any installed Cabal, don't appear to work for this particular scenario, and I don't really feel like investigating why not. |
At this point, I've got the patch written, but I'm having trouble verifying it, because of an unrelated problem keeping GHC from building executables at all (though it has no problem with libraries) on 10.9 beta 2. This looks fairly superficial - something to do with a wrong list of runtime and system libraries that need to be statically vs. dynamically linked, or something - but I'm not sure how to bootstrap my way out of it. So I'm not submitting the pull request yet, because I can't yet verify that the code actually does what I intend it to. |
Any way I can help with this and some of the other apple / mac compat future proofing, i would like to do so |
Over a year later, I'm still getting bitten by this (or something closely related). I have a cabal package that depends on two C libraries installed in a local prefix.
and |
This issue still exists, and turns up if you try to build Haskell code on a system with a |
As you may be aware, the first thing that Cabal does upon configure is, if there is a Setup.hs script, attempt to compile it. This compilation does not appear to respect the usual options that apply to every other compilation, including the two named above: --extra-include-dirs and --extra-lib-dirs.
This is a problem, because some systems do not have global /usr and /lib directories, but rather put these things elsewhere. In particular, it has always been the case on the Mac really that one is supposed to be using paths within the SDK directory rather than global paths, to allow for compilation to target other versions of OS X than the one currently running. Now in this year's 10.NDA release, the global paths are removed entirely.
This problem appears to apply regardless of whether the paths are specified in ~/.cabal/config, or on the command line.
Things have gotten to this point without totally breaking because not every package uses a custom Setup.hs, so this build step doesn't always need to be done.
Tested on:
cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library
I'll have a pull request shortly for everyone to ignore. You're welcome.
The text was updated successfully, but these errors were encountered: