Re: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64

2014-04-14 Thread Ramin Honary
I am using Debian, not Mac. It is possible the problem may be with the
binary release for Debian x86_64, or it could just be my Cabal config file.

When I install the binary distribution onto Debian, I simply run make
install in the ghc-7.8.2 directory. I don't know how this install process
the creates the GHC package registry, but after a fresh install, the output
of the ghc-pkg list command shows that terminfo-0.4.0.0 is NOT
installed even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0
directory clearly exists and is populated with the correct library files.
But since it is not registered Cabal tries to re-build it and overwrites
the existing terminfo-0.4.0.0 package.

After a fresh install on Mac or Fedora, I wonder if terminfo-0.4.0.0
shows up in the GHC package registry? It could be the package registry for
the Debian binary distribution missed that detail.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64

2014-04-14 Thread Austin Seipp
Hi Ramin,

Can I ask if you're installing packages into the global user database?
If so, that's definitely the way for this to happen - otherwise, Cabal
should never overwrite *anything* in the 'global' package directory
(in your case, under /usr/local/lib/ghc-7.8.2...) This is the only way
I can see this happening. In particular, installing 'terminfo' into my
local package database ('cabal install terminfo') works fine...

Carefully review your cabal configuration if you don't mind. You can
also always force the installation using '--user' when running cabal.

However, thank you very much for bringing this to my attention. What
you have discovered is a real brainfart I don't think we had
considered! The problem is that now that GHC is dynamically linked, we
*cannot* get away with lying about whether those packages are
installed - because they must install shared objects for GHC itself to
work. That means overwriting them by accident (because we don't think
they're installed) is a real possibility.

Relatedly, the NixOS Haskell users are suffering from the same problem
with 7.8.2 - http://lists.science.uu.nl/pipermail/nix-dev/2014-April/012992.html
- same problem, slightly different symptoms.

See https://ghc.haskell.org/trac/ghc/ticket/8919 for the ticket.

So this is definitely a real problem. I think scheduling the change
for 7.8.3 is correct.

My intuition tells me the fix might actually be quite simple - don't
lie about xhtml and terminfo being installed, and just be honest. Is
there any particular downside to doing this? I don't think so, *other*
than the fact it does mean terminfo has to come along when it's not
part of the Haskell Platform!



On Mon, Apr 14, 2014 at 7:08 AM, Ramin Honary ramin.hon...@gmail.com wrote:
 I am using Debian, not Mac. It is possible the problem may be with the
 binary release for Debian x86_64, or it could just be my Cabal config file.

 When I install the binary distribution onto Debian, I simply run make
 install in the ghc-7.8.2 directory. I don't know how this install process
 the creates the GHC package registry, but after a fresh install, the output
 of the ghc-pkg list command shows that terminfo-0.4.0.0 is NOT installed
 even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0 directory
 clearly exists and is populated with the correct library files. But since it
 is not registered Cabal tries to re-build it and overwrites the existing
 terminfo-0.4.0.0 package.

 After a fresh install on Mac or Fedora, I wonder if terminfo-0.4.0.0 shows
 up in the GHC package registry? It could be the package registry for the
 Debian binary distribution missed that detail.


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Fwd: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64

2014-04-14 Thread Ramin Honary
Hi, thanks for your reply.

Yes, I know for a fact I was installing to the global registry. All of my
Haskell projects depend on a few important packages, and I always install
these globally. For stuff I just want to play around with, I just install
into the user registry. Actually terminfo-0.4.0.0 is not something any of
my projects depend on, but I had installed it globally anyway and then this
problem occurred.

Also, the behavior Cabal installing Crypto-4.2.5.1 was odd. As I explained
in my first e-mail, some of the shared modules were being built with file
extensions of .hi instead of .dyn_hi, but the copy phase of the Cabal
installation was searching for files with .dyn_hi extensions and was
failing. And not all modules were being built incorrectly, some modules had
the correct .dyn_hi, others had just .hi. This may be a problem with
the Crypto.cabal file, however.

But anyway, the transition to using shared libraries by default has (in my
experience) caused just these two hiccups. I'm glad I was able to expose
this problem.

-- Ramin Honary



On Mon, Apr 14, 2014 at 10:07 PM, Austin Seipp aus...@well-typed.comwrote:

 Hi Ramin,

 Can I ask if you're installing packages into the global user database?
 If so, that's definitely the way for this to happen - otherwise, Cabal
 should never overwrite *anything* in the 'global' package directory
 (in your case, under /usr/local/lib/ghc-7.8.2...) This is the only way
 I can see this happening. In particular, installing 'terminfo' into my
 local package database ('cabal install terminfo') works fine...

 Carefully review your cabal configuration if you don't mind. You can
 also always force the installation using '--user' when running cabal.

 However, thank you very much for bringing this to my attention. What
 you have discovered is a real brainfart I don't think we had
 considered! The problem is that now that GHC is dynamically linked, we
 *cannot* get away with lying about whether those packages are
 installed - because they must install shared objects for GHC itself to
 work. That means overwriting them by accident (because we don't think
 they're installed) is a real possibility.

 Relatedly, the NixOS Haskell users are suffering from the same problem
 with 7.8.2 -
 http://lists.science.uu.nl/pipermail/nix-dev/2014-April/012992.html
 - same problem, slightly different symptoms.

 See https://ghc.haskell.org/trac/ghc/ticket/8919 for the ticket.

 So this is definitely a real problem. I think scheduling the change
 for 7.8.3 is correct.

 My intuition tells me the fix might actually be quite simple - don't
 lie about xhtml and terminfo being installed, and just be honest. Is
 there any particular downside to doing this? I don't think so, *other*
 than the fact it does mean terminfo has to come along when it's not
 part of the Haskell Platform!



 On Mon, Apr 14, 2014 at 7:08 AM, Ramin Honary ramin.hon...@gmail.com
 wrote:
  I am using Debian, not Mac. It is possible the problem may be with the
  binary release for Debian x86_64, or it could just be my Cabal config
 file.
 
  When I install the binary distribution onto Debian, I simply run make
  install in the ghc-7.8.2 directory. I don't know how this install
 process
  the creates the GHC package registry, but after a fresh install, the
 output
  of the ghc-pkg list command shows that terminfo-0.4.0.0 is NOT
 installed
  even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0 directory
  clearly exists and is populated with the correct library files. But
 since it
  is not registered Cabal tries to re-build it and overwrites the existing
  terminfo-0.4.0.0 package.
 
  After a fresh install on Mac or Fedora, I wonder if terminfo-0.4.0.0
 shows
  up in the GHC package registry? It could be the package registry for the
  Debian binary distribution missed that detail.
 
 
  ___
  Glasgow-haskell-users mailing list
  Glasgow-haskell-users@haskell.org
  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 



 --
 Regards,

 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64

2014-04-13 Thread Ramin Honary
I am posting this to the mailing list, but it is a copy of a post I
originally made on Haskell Reddit.

http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782_on_debian_ubuntu_x86/


My GHC is working fine now. But there seem to be some changes in either GHC
7.8.2 or Cabal-1.18.1.3 that have broken some of the older packages in
Hackage.

*TL;DR* I discovered the Crypto-4.2.5.1 package is broken, and trying to
install terminfo-0.4.0.0 breaks GHC by over-writing the terminfo library
that came with the GHC tarball because isn't in the GHC package registry.

I downloaded the binary distribution from here:

https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-linux-deb7.tar.bz2

and then immediately began re-building all of the packages in my
.cabal/packages/hackage.haskell.org/ direcotry.

I admit, all of my problems may be due to my Cabal config, but I haven't
had any problems with it before this, as far as I know it is the default
setup the option to build profiling libraries set to True.

The first problem I had was that Crypto-2.5.4.1 was not building files
correctly. *Some* of shared object files *.dyn_o were being built
*without* their accompanying *.dyn_hi files, although some of the
*.dyn_hi files did exist). When cabal tried to copy these *.dyn_hi
files to the global package registry during installation it would fail with
something about (for example) could not find RSA.dyn_hi. To solve this, I
rebuilt every *.dyn_o file that did not have an accompanying *.dyn_hi
by hand using the command

ghc -dynamic --make Codec.Binary.RSA

The resulting Codec/Binary/RSA.hi file was actually a dynamic interface
file but it's file extension was just .hi for some reason, (I double
checked by using ghc --show-iface) so I just copied it it the
dist/build/Codec/Binary/ directory. I did this for every *.hi file that
was supposed to be named *.dyn_hi. This included about 10 files. Again,
some *.dyn_o did build correctly with an accompanying *.dyn_hi, about
10 of the modules were built incorrectly, all the rest were OK.

The second problem I had was with installing Yi which relies on the
terminfo-0.4.0.0 package. The terminfo library that came with the GHC
7.8.2 binary distribution does not show up in the output of ghc-pkg list,
so Cabal tries to build it thinking it doesn't exist, and it overwrites the
existing terminfo-0.4.0.0 package with a library that contains missing
symbols. This causes GHC to completely stop working. The ghc program
immediately fails with an error:

symbol lookup error:
/usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so:
\
undefined symbol:
terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info

I was able to solve this problem by simply copying the contents of:

ghc-7.8.2/libraries/terminfo/dist-install/build/*

from the source distribution tarball to the GHC installation directory:

/usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/

and that solved the problem. But any program depending on terminfo simply
will not install properly. The terminfo-0.4.0.0 package does not show up in
the output of ghc-pkg list, even though it comes with the GHC 7.8.2 tarball
and GHC relies on it. Attempting to install Terminfo will build a .so
file that GHC cannot use. *So don't install terminfo-0.4.0.0 from Hackage.*

Fortunately, Yi is not something that is absolutely necessary. I was able
to install every other package I needed (lens, diagrams, yesod, xmonad,
gtk) without incident.

But whatever changes have been made in ghc-7.8.2 and the accompanying
Cabal-1.18.1.3 seem to have broken some of the older Hackage packages.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64

2014-04-13 Thread George Colpitts
I was able to do cabal install of  terminfo, crypto and Yi on my mac with
ghc 7.8.2 and cabal 1.18.1.3
yi seems to work although I did very little with it


On Sun, Apr 13, 2014 at 12:08 PM, Ramin Honary ramin.hon...@gmail.comwrote:

 I am posting this to the mailing list, but it is a copy of a post I
 originally made on Haskell Reddit.


 http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782_on_debian_ubuntu_x86/


 My GHC is working fine now. But there seem to be some changes in either
 GHC 7.8.2 or Cabal-1.18.1.3 that have broken some of the older packages in
 Hackage.

 *TL;DR* I discovered the Crypto-4.2.5.1 package is broken, and trying to
 install terminfo-0.4.0.0 breaks GHC by over-writing the terminfo library
 that came with the GHC tarball because isn't in the GHC package registry.

 I downloaded the binary distribution from here:


 https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-linux-deb7.tar.bz2

 and then immediately began re-building all of the packages in my
 .cabal/packages/hackage.haskell.org/ direcotry.

 I admit, all of my problems may be due to my Cabal config, but I haven't
 had any problems with it before this, as far as I know it is the default
 setup the option to build profiling libraries set to True.

 The first problem I had was that Crypto-2.5.4.1 was not building files
 correctly. *Some* of shared object files *.dyn_o were being built
 *without* their accompanying *.dyn_hi files, although some of the
 *.dyn_hi files did exist). When cabal tried to copy these *.dyn_hi
 files to the global package registry during installation it would fail with
 something about (for example) could not find RSA.dyn_hi. To solve this, I
 rebuilt every *.dyn_o file that did not have an accompanying *.dyn_hi
 by hand using the command

 ghc -dynamic --make Codec.Binary.RSA

 The resulting Codec/Binary/RSA.hi file was actually a dynamic interface
 file but it's file extension was just .hi for some reason, (I double
 checked by using ghc --show-iface) so I just copied it it the
 dist/build/Codec/Binary/ directory. I did this for every *.hi file that
 was supposed to be named *.dyn_hi. This included about 10 files. Again,
 some *.dyn_o did build correctly with an accompanying *.dyn_hi, about
 10 of the modules were built incorrectly, all the rest were OK.

 The second problem I had was with installing Yi which relies on the
 terminfo-0.4.0.0 package. The terminfo library that came with the GHC
 7.8.2 binary distribution does not show up in the output of ghc-pkg list,
 so Cabal tries to build it thinking it doesn't exist, and it overwrites the
 existing terminfo-0.4.0.0 package with a library that contains missing
 symbols. This causes GHC to completely stop working. The ghc program
 immediately fails with an error:

 symbol lookup error: 
 /usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so:
  \
 undefined symbol: 
 terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info

 I was able to solve this problem by simply copying the contents of:

 ghc-7.8.2/libraries/terminfo/dist-install/build/*

 from the source distribution tarball to the GHC installation directory:

 /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/

 and that solved the problem. But any program depending on terminfo
 simply will not install properly. The terminfo-0.4.0.0 package does not
 show up in the output of ghc-pkg list, even though it comes with the GHC
 7.8.2 tarball and GHC relies on it. Attempting to install Terminfo will
 build a .so file that GHC cannot use. *So don't install
 terminfo-0.4.0.0 from Hackage.*

 Fortunately, Yi is not something that is absolutely necessary. I was able
 to install every other package I needed (lens, diagrams, yesod, xmonad,
 gtk) without incident.

 But whatever changes have been made in ghc-7.8.2 and the accompanying
 Cabal-1.18.1.3 seem to have broken some of the older Hackage packages.

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users