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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Magicloud Magiclouds
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Thomas Schilling-2
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 <[hidden email]>:

> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Simon Marlow-7
In reply to this post by Magicloud Magiclouds
Magicloud wrote:

> 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.

Hi there - thanks for the feedback, although there's not much we can do
unless you provide complete details about what went wrong, so that we can
figure out whether you're reporting new bugs or known issues.

It would be more useful if you could take even just one of those issues and
report it properly via the GHC or Cabal bug trackers.  Give enough
information that we can reproduce the problem and improve the tools.

Instructions for reporting bugs in GHC are here:

http://hackage.haskell.org/trac/ghc/wiki/ReportABug

Cabal Trac is here:

http://hackage.haskell.org/trac/hackage/

Cheers,
        Simon

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Magicloud Magiclouds
In reply to this post by Thomas Schilling-2
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.
2. After `cabal update && cabal upgrade`, ghc-6.8.3 cannot be built. 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.
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.

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.

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 <[hidden email]>:
>  
>> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>    
>
>  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Thomas Schilling-2
2008/10/14 Magicloud <[hidden email]>:
> 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 <[hidden email]>:
>>
>>>
>>> 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
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
>
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Magicloud Magiclouds
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 <[hidden email]>:
>  
>> 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 <[hidden email]>:
>>>
>>>      
>>>> 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
>>>> [hidden email]
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>>        
>>>      
>>    
>
>  

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

John Van Enk
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 <[hidden email]> 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 <[hidden email]>:
 
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 <[hidden email]>:

     
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


       
     
   

 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Magicloud Magiclouds
My linux distribution does not have a ghc. It is customed by my company.
So I have to install it from souce.
And the reason that some situation I did not descript clearly is that
they are long time ago, I cannot remember the details....

John Van Enk wrote:

> 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
> <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>         <mailto:[hidden email]>>:
>          
>
>             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. <http://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 <[hidden email]
>                 <mailto:[hidden email]>>:
>
>                      
>
>                     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
>                     [hidden email]
>                     <mailto:[hidden email]>
>                     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>                            
>
>                      
>
>                
>
>
>          
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Duncan Coutts
In reply to this post by Magicloud Magiclouds
On Wed, 2008-10-15 at 09:25 +0800, Magicloud 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....

You're quite right that Cabal does not track ABI versions. So it is
quite possible to break dependencies of installed packages by doing
things like unregistering or rebuilding a dependent package such that it
gets a different ABI.

There is ongoing work to make it harder to shoot yourself in the foot,
by tracking the ABIs of installed packages.

In the mean time all these problems can be solved by rebuilding things
cleanly.

It does look like there is a bug in the ghc build system where if the
bootstrapping compiler has the same or higher versions of packages that
the ghc build system installs then things can go wrong. We've just
noticed this with ghc-6.10 but it seems likely the same bug is present
in the ghc-6.8.x build system.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

Jules Bean
In reply to this post by John Van Enk
John Van Enk wrote:
> 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.

As far as I can see, his problem was

cabal update && cabal upgrade

which seems like a sensible command to run, but actually isn't.

Jules

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe