Hi Austin, It seems to me that the patch for Cabal in ticket 8266 is still missing: https://ghc.haskell.org/trac/ghc/ticket/8266 diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs index c7ea633..78cdcbb 100644 --- a/Cabal/Distribution/Simple/GHC.hs +++ b/Cabal/Distribution/Simple/GHC.hs @@ -867,11 +867,6 @@ buildOrReplLib forRepl verbosity pkg_descr lbi lib clbi = do ghcOptDynLinkMode = toFlag GhcDynamicOnly, ghcOptInputFiles = dynamicObjectFiles, ghcOptOutputFile = toFlag sharedLibFilePath, - -- For dynamic libs, Mac OS/X needs to know the install location - -- at build time. - ghcOptDylibName = if buildOS == OSX - then toFlag sharedLibInstallPath - else mempty, ghcOptPackageName = toFlag pkgid, ghcOptNoAutoLinkPackages = toFlag True, ghcOptPackageDBs = withPackageDB lbi, If Duncan is busy at this moment, can you take over the merge job? --Kazu
Hello all,
I've just created the 7.8 branch after tying off some of the final loose ends.
In its current state, I expect the branch as it is now to become RC1 within the day. I plan on starting builds for the following soon:
- OS X 10.7 and OS X 10.9 - Linux i386/amd64 (likely based on Debian Wheezey) - Windows i386/amd64 (many thanks to Kyrill Briantsev for the heroic last-minute linker fixes!)
I'll send a (GPG-signed) email containing SHA1 hashes when they're done.
Two systems I won't make builds for RC1 by default (but could be persuaded to if nobody else does, and people want it):
- Older glibc-2.5 based systems (e.g. CentOS, - a few users have talked about this wrt binary releases, where I don't think GHC works.) - FreeBSD - Pali, if you'd like to do this, feel free, and let me know.
This means I'll (mostly) be waiting around today, so feel free to shoot questions.
As of now, this means HEAD is now version 7.9, and you're free to push wacky experiments or changes now, if you've been holding off. You'll probably want to clean your whole tree, since this means the interface file versions etc will change.
Finally, we picked up a good amount of new committers this year, so let's remind people of the merging policy: what happens if you need to merge something you did to the 7.8 branch? There are two main avenues for this to happen:
* Someone reports a bug against the 7.8 RC on Trac. You decide to fix it and do so. Now what?
1) Please commit the bug to master, and confirm it's a fix. 2) Go to the bug, and instead of closing it, change the ticket status to 'merge'. 3) I will cherry-pick it over to the 7.8 branch for you - nothing else needed.
* There's not a recorded bug, but you do push a change, and you think it should be merged (maybe a typo or something.) In this case, I'd ask you please CC me on the email sent to ghc-commits@haskell.org which is related to your commit, and just say "Please merge" or somesuch. I'll come over the commits with such a response.
This goes for all changes - submodule updates, typos, real fixes, etc. It's likely me and Herbert will restrict the Gitolite permissions to only allow the two of us to touch the ghc-7.8 branch. So it's really important you put us in the loop, ASAP.
If you don't do one of these two things, it's highly likely I will miss it, and not merge it. If you have questions, please ask me or Herbert. If there's a merge conflict, we can discuss it.
Thanks
-- Regards,
Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs