-
Notifications
You must be signed in to change notification settings - Fork 843
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
MacOS: stack fails to build "ghc-paths" when Macports is present #4504
Comments
Hi, have you seen http://blog.omega-prime.co.uk/2011/01/28/solving-ghc-iconv-problems-on-os-x-10-6/? Also NixOS/nixpkgs#46814 (comment) seems relevant. What happens if you also pass |
Alas, the same thing. I tried also
with the same result. It does not go into Although I don't understand why - since Yes I checked that blog. Unfortunately, it doesn't help:
UpdateThe "nixOS" comment might be relevant -though I'm not sure how to enforce passing/appending of |
Here's an example that appears to work with other packages. First, what showed to not work:
This appears to work, somehow:
But, as I said in my previous post, for reasons I can't figure out, it does not work with
And here's the verbose log, in case it helps: |
Have you tried setting |
This would be the right variable for Linux. On MacOS it's UpdateInterestingly enough (for me, at least), other packages that appear to depend on |
I've forwarded the issue. Meanwhile, you might want to try |
Setting "system-ghc: false" changes nothing, because any GHC, either installed directly by me, or downloaded by "stack" itself, hits the same problem: "libiconv" library conflict. Those flags I'm trying to pass, are supposed to remedy that conflict - but they're ignored. |
OK, that's a shame. As I say, I've asked for people with MacOS experience to help. |
I think I have plenty of MacOS experience. It is my conclusion that the problem is stack-related, rather than MacOS-related. It is manifested in MacOS because Macports installs/requires it's own version of "libiconv", which mangles function names. |
Also, the original issue was about "ghc-paths", but I observe the same with "happy". stack did not pass all the necessary flags specified in the command line or in the main config file. So, the majority of packages (local, or from Hackage) seem to take the arguments from command line and link correctly. Some packages (e.g., "ghc-paths" and "happy") for some reason fail to do so, and thus fail to install, with a linker error. |
That's helpful to know. I meant, I'll find a stack maintainer with MacOS experience. It might be interesting that it's packages normally bundled with ghc. What else is affected? |
What's affected is everything that requires linking against libHSbase.a (but not against libHSbase.dylib or libHSbase.so). However, for a large portion of the affected packages, the flags I'm trying to use are resolving the problem. But for some, they are ignored. I talked to GHC people about abolishing libHSbase.a in favor of using only libHSbase.dylib in a new release, but got a solid justified No. Also, it's only stack that's affected thusly. All of the above packages build nicely in my environment with Cabal. And I'd just stay with Cabal - except that the IDE plugin that I use, is stack-only. So I'm forced to get a fully-working stack - which so far I cannot. |
General summary/comments (optional)
It seems that
stack
fails to use eitherghc-options:
orextra-lib-dirs:
when buildingghc-paths
.Problem with passing parameters to the linker (
stack
->ghc
->gcc
->ld
).I'm looking for the ability to pass arguments to linker, specifically to tell it to search a given set of directories for libraries in the provided order, and starting with them rather than with something else. The ability to tell the linker "search
/this/dir
first before going to, e.g.,/opt/local/lib
", would be outstanding.Steps to reproduce
/opt/local/lib/liconv
and copy/usr/lib/libiconv.dylib
to there.cabal
(~/.cabal/config
) andstack
(~/.stack/config.yaml
) to use/opt/local/lib/liconv
first, then add other lib directories (seeconfig.yaml
attached).stack unpack ghc-paths
andcd
to where it got unpacked.stack build
and observe the failure.Expected
Build succeeds.
Actual
Here's
stack.yaml
fromghc-paths-0.1.0.9
:Here's my
~/.stack/config.yaml
:Here's the output of
stack build
: GistStack version
Method of installation
The text was updated successfully, but these errors were encountered: