[Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Tue Oct 14 22:06:04 EDT 2008

Could you, perhaps, outline a little more of what you're trying to do? I'm
having a hard time seeing what exactly you're doing, and why you can't use
the package provided by your distribution.
We'd love to help you, but you're not being very clear with what your
problem is.

/jve

On Tue, Oct 14, 2008 at 9:25 PM, Magicloud
<magicloud.magiclouds at gmail.com>wrote:

> 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
>> provide?
>>
>>
>>
>>> Lib
>>> Network.URI cannot be compiled because:
>>> Network/CGI/Protocol.hs:41:0:
>>>  Failed to load interface for `Network.URI':
>>>   Perhaps you haven't installed the profiling libraries for package
>>> network-2.2.0.0?
>>>   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)
>>
>> HTH,
>>
>>  Thomas
>>
>>
>>
>>
>>> 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
>>>>> binary.
>>>>> 2. After I installed cabal, and upgraded, ghc-6.8.3 cannot rebuild
>>>>> itself.
>>>>> 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
>>>>> for
>>>>> 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
>>>>> crazy.
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> Haskell-Cafe at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081014/b18dddc0/attachment.htm