[Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and
haskell binary policy are really horrible.
magicloud.magiclouds at gmail.com
Tue Oct 14 21:25:32 EDT 2008
Thank you for your reply.
So the main information I got is that cabal is not safe. And my problems
are all related to cabal, I think, dependency, ABI version....
I hope everything could be better soon. At least, tools should not block
the way of producing.
Thomas Schilling wrote:
> 2008/10/14 Magicloud <magicloud.magiclouds at gmail.com>:
>> Sorry, let me say it this way:
>> 1. Ghc cannot be bootstrap-installed. And the ghc-6.8.3 binary from official
>> website also cannot run in my box, some kind of overflow error. So I have to
>> look for help, a few hours later, I found 6.4.2 (I am not sure) which runs
>> well in my box, and install ghc-6.8.3 indirectly.
> Hm, the only issue with binary installers I had were old versions of
> some libraries which could be resolved by adding a few symlinks. What
> system are you on?
>> 2. After `cabal update && cabal upgrade`, ghc-6.8.3 cannot be built.
> Which version of cabal-install ( cabal --version ) are you using?
> Note that 'cabal upgrade' is not guaranteed to work since libraries on
> hackage don't always specify their dependencies correctly and older
> versions of cabal-install might have some issues. There's an ongoing
> initiative to have a set of more controlled packages, the Haskell
> Platform. It should soon has its first release.
> That said, you shouldn't need to upgrade anything if you want to build
> ghc 6.8.3 with 6.4.2. Also, what version of ghc does you distribution
>> Network.URI cannot be compiled because:
>> Failed to load interface for `Network.URI':
>> Perhaps you haven't installed the profiling libraries for package
>> Use -v to see a list of the files searched for.
>> I remove this SUBDIRS from the Makefile, luckly, it works. A few more hours
>> lost in my life.
>> 3. When I `ghc -v`, there are lots of "hiding package xxx to avoid conflict
>> with later version yyy", do I have a way to remove these hiding packages?
>> And "package xx will be ignored due to missing or recursive dependencies:
>> yy", what does this mean? If it is ignored, my program using it compiled and
>> run well. If the dependencies are not right, how can I fix it? I installed
>> this by cabal. It reports nothing wrong and cannot check if all packages
>> dependencies are OK.
>> 4. When `cabal upgrade`, I do not think it knows what it is doing. There
>> were many times that I cannot upgrade because I should manually reinstall
>> some packages to make it work (Some guy say that this is because ghc cannot
>> know the difference between two lib files with the same name). And, cabal
>> does not upgrade all packages, I do not know why.
> The issue is binary compatibility. At the moment, GHC cannot make
> sure that a library compiled with an older GHC can work with a newer
> GHC. GHC does many cross-module optimisations, and its runtime system
> changes occasionally, so it is very pessimistic in that regard. This
> becomes an issue for packages that GHC has been build with itself
> (like base, process, array), since these cannot be upgraded without
> recompiling GHC (hence requiring recompiling every other package).
> Older versions of cabal-install could not deal with this correctly.
> So in short, "cabal upgrade" (without arguments) is probably not very
> safe, atm.
> There are ongoing efforts to provide more ABI compatibility
> guarantees, but that requires solving of some difficult issues, so
> we're not there yet.
> There are certainly some things that could be improved. For example
> GHC 6.10 won't let you unregister a package that other packages depend
> on and it keeps checksums of the ABI which may be used by future
> versions of Cabal/cabal-install.
>> 5. Sometimes when I upgrade some libraries, ghc failed to compile, because
>> ld failed to find the new libraries. (Which proves that ghc cannot deal with
>> binary files right). I need to recompile this, and recompile that, MAYBE it
>> would be resolved.
> Without further details I can just guess, but I think this is related
> to the problems with binary compatibility above.
>> Everyday, I spend a few hours on compiling. Does it really need to be so
>> terrible? With erlang or ruby, I never spend more time debugging as
>> haskell's feature says but less time on how to run my code.
> Many projects can just be loaded via ghci which is a lot faster. Just
> cd to the toplevel source directory, type :l ModuleName. Then edit
> the source code, and type :r to reload the current module.
> With many of these smaller issues you can often find quick help on
> Haskell's IRC channel #haskell or #ghc if you have problems specific
> to GHC (although asking at #haskell will often give you an answer more
> quickly, so ask there first anyway)
>> Thomas Schilling wrote:
>>> It would be helpful if you could describe exactly what you did so we
>>> can work on improving the issue in the long term (and help you fix it
>>> in the short term).
>>> 2008/10/14 Magicloud <magicloud.magiclouds at gmail.com>:
>>>> 1. I cannot install ghc-6.8.3 in my box until I found the old runable
>>>> 2. After I installed cabal, and upgraded, ghc-6.8.3 cannot rebuild
>>>> Because its libraries are conflict with the ones upgraded by cabal.
>>>> 3. Sometimes, ghc just ignore some libs, because it does not meet its
>>>> dependencies. Well, ghc does not even tell me. It knows what I want?
>>>> 4. I use cabal, thinking it would make dependencies installation easier
>>>> me. Well it does not, once an error happened, nothing would work since. I
>>>> cannot even remove the broken lib.
>>>> 5. No more needed. The above ones, which are important enough to drive me
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe