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-comm...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs