Hello, I have been developing new code for the "unix" package. I have run into what I think are ghc 6.8.2 anomalies but couldn't see a pattern. Possibly now I do. I have been using the 32-bit x86 ghc binary that I downloaded from http://www.haskell.org and running on Ubuntu Linux. I am pretty I can repeat now. Everything is ok until I do "sudo runhaskell Setup.hs install" which installs a new "unix" package that I just built. Of course the "intall" installs into /usr/local/lib/unix-2.3.0.0/ghc-6.8.2. The "install" seems to destroy some ghc compiler state under /usr/local ... This is of course just a theory. However, once I re-install ghc et. al. from the binary download then things are ok again. I have tried the ghc re-install at least 4 times. Hope I am not misleading anybody .. just trying to help! Kind regards, Vasili
On Mon, 2008-06-02 at 00:07 -0500, Galchin, Vasili wrote:
Hello,
I have been developing new code for the "unix" package. I have run into what I think are ghc 6.8.2 anomalies but couldn't see a pattern. Possibly now I do. I have been using the 32-bit x86 ghc binary that I downloaded from http://www.haskell.org and running on Ubuntu Linux. I am pretty I can repeat now. Everything is ok until I do "sudo runhaskell Setup.hs install" which installs a new "unix" package that I just built. Of course the "intall" installs into /usr/local/lib/unix-2.3.0.0/ghc-6.8.2. The "install" seems to destroy some ghc compiler state under /usr/local ...
That sounds right. You're replacing the unix-2.3.0.0 library that comes with ghc-6.8.2 with your own version. It is highly unlikely to be ABI compatible with the one you are replacing and so all the other packages that already depends on the existing unix-2.3.0.0 library end up broken. You'd expect this kind of breakage to be exposed as link errors and segfaults. I suggest you do not replace any of the libraries that come with ghc. To be more precise, it is perfectly ok to *add new versions* but it is not ok to *replace existing versions* without rebuilding all the other libs that depend on it. Make sense? So if you really want to make changes to the unix lib, make sure you change the version number too. I also suggest not installing the packages as root, just install them locally. That way you can guarantee you never mess up your ghc install. You would be able to revert to a clean ghc install just by removing your ~/.ghc/$arch/ghc-6.8.2/package.conf file which will unregister *all* locally registered packages. To unregister individual packages use ghc-pkg --user unregister $pkgname Duncan
Hi Duncan,
Not sure I agree the behavior is ok. E.g. here is a build of mmap:
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs
clean
cleaning...
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs
configure
Configuring bytestring-mmap-0.2.0...
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs
build
Preprocessing library bytestring-mmap-0.2.0...
Building bytestring-mmap-0.2.0...
[1 of 3] Compiling System.IO.Posix.MMap.Internal (
System/IO/Posix/MMap/Internal.hs, dist/build/System/IO/Posix/MMap/Internal.o
)
[2 of 3] Compiling System.IO.Posix.MMap.Lazy ( System/IO/Posix/MMap/Lazy.hs,
dist/build/System/IO/Posix/MMap/Lazy.o )
[3 of 3] Compiling System.IO.Posix.MMap ( System/IO/Posix/MMap.hs,
dist/build/System/IO/Posix/MMap.o )
/usr/bin/ar: creating dist/build/libHSbytestring-mmap-0.2.0.a
at this point rebuild and install the "unix" package ...
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs
clean
cleaning...
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs
configure
Configuring bytestring-mmap-0.2.0...
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs
build
Setup.lhs: error reading dist/setup-config; run "setup configure" command?
"dist/setup-config" is not being populated at the end. In your response
below, are you saying that teh segfaults occur because ghc itself relies on
the "unix" package?
Thanks, Vasili
On Mon, Jun 2, 2008 at 5:38 AM, Duncan Coutts
On Mon, 2008-06-02 at 00:07 -0500, Galchin, Vasili wrote:
Hello,
I have been developing new code for the "unix" package. I have run into what I think are ghc 6.8.2 anomalies but couldn't see a pattern. Possibly now I do. I have been using the 32-bit x86 ghc binary that I downloaded from http://www.haskell.org and running on Ubuntu Linux. I am pretty I can repeat now. Everything is ok until I do "sudo runhaskell Setup.hs install" which installs a new "unix" package that I just built. Of course the "intall" installs into /usr/local/lib/unix-2.3.0.0/ghc-6.8.2. The "install" seems to destroy some ghc compiler state under /usr/local ...
That sounds right. You're replacing the unix-2.3.0.0 library that comes with ghc-6.8.2 with your own version. It is highly unlikely to be ABI compatible with the one you are replacing and so all the other packages that already depends on the existing unix-2.3.0.0 library end up broken. You'd expect this kind of breakage to be exposed as link errors and segfaults.
I suggest you do not replace any of the libraries that come with ghc. To be more precise, it is perfectly ok to *add new versions* but it is not ok to *replace existing versions* without rebuilding all the other libs that depend on it.
Make sense?
So if you really want to make changes to the unix lib, make sure you change the version number too. I also suggest not installing the packages as root, just install them locally. That way you can guarantee you never mess up your ghc install. You would be able to revert to a clean ghc install just by removing your ~/.ghc/$arch/ghc-6.8.2/package.conf file which will unregister *all* locally registered packages. To unregister individual packages use ghc-pkg --user unregister $pkgname
Duncan
On Mon, 2008-06-02 at 23:11 -0500, Galchin, Vasili wrote:
at this point rebuild and install the "unix" package ...
vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs clean cleaning... vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs configure Configuring bytestring-mmap-0.2.0... vigalchin@ubuntu:~/FTP/Haskell/bytestring-mmap-0.2.0$ runhaskell Setup.lhs build Setup.lhs: error reading dist/setup-config; run "setup configure" command?
"dist/setup-config" is not being populated at the end. In your response below, are you saying that teh segfaults occur because ghc itself relies on the "unix" package?
Something like that yes. You're running runhaskell Setup.lhs and that loads and runs code from the Cabal library. The Cabal library depends on the process library which depends on the unix library. So by replacing the same version of the unix package you're breaking everything else which depends on it, including Cabal and thus runhaskell Setup.lhs. So the solution is to not do that. Don't re-install the exact same version of any of the core libs that come with ghc. Adding new versions is fine, replacing existing versions is not fine because it breaks all the other packages that were already built against that package. Duncan
Something like that yes.
You're running runhaskell Setup.lhs and that loads and runs code from the Cabal library. The Cabal library depends on the process library which depends on the unix library. So by replacing the same version of the unix package you're breaking everything else which depends on it, including Cabal and thus runhaskell Setup.lhs.
So the solution is to not do that. Don't re-install the exact same version of any of the core libs that come with ghc. Adding new versions is fine, replacing existing versions is not fine because it breaks all the other packages that were already built against that package.
But Duncan, let's suppose I build "unix" putting in a "local" directory with a different version number than the released version of "unix". 1) How do I get the "local" package.conf built and populated? 2) How do I get a test case to link against this experimental local version of "unix"? Is there a "--prefix" or something like that I pass on runhaskell Setup.hs build? Regards, Vasili
Duncan
On 2008 Jun 3, at 16:40, Galchin, Vasili wrote:
1) How do I get the "local" package.conf built and populated?
2) How do I get a test case to link against this experimental local version of "unix"? Is there a "--prefix" or something like that I pass on runhaskell Setup.hs build?
both cases the answer is the same: --user --prefix=whatever -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Duncan,
By installing localling, I "runhaskell Setup.hs configure
--prefix=$HOME" plus add local path to LD_LIBRARY_PATH and LD_RUN_PATH? On
Linux, does ghc use .so's or is it linked statically?
Vasili
On Mon, Jun 2, 2008 at 5:38 AM, Duncan Coutts
On Mon, 2008-06-02 at 00:07 -0500, Galchin, Vasili wrote:
Hello,
I have been developing new code for the "unix" package. I have run into what I think are ghc 6.8.2 anomalies but couldn't see a pattern. Possibly now I do. I have been using the 32-bit x86 ghc binary that I downloaded from http://www.haskell.org and running on Ubuntu Linux. I am pretty I can repeat now. Everything is ok until I do "sudo runhaskell Setup.hs install" which installs a new "unix" package that I just built. Of course the "intall" installs into /usr/local/lib/unix-2.3.0.0/ghc-6.8.2. The "install" seems to destroy some ghc compiler state under /usr/local ...
That sounds right. You're replacing the unix-2.3.0.0 library that comes with ghc-6.8.2 with your own version. It is highly unlikely to be ABI compatible with the one you are replacing and so all the other packages that already depends on the existing unix-2.3.0.0 library end up broken. You'd expect this kind of breakage to be exposed as link errors and segfaults.
I suggest you do not replace any of the libraries that come with ghc. To be more precise, it is perfectly ok to *add new versions* but it is not ok to *replace existing versions* without rebuilding all the other libs that depend on it.
Make sense?
So if you really want to make changes to the unix lib, make sure you change the version number too. I also suggest not installing the packages as root, just install them locally. That way you can guarantee you never mess up your ghc install. You would be able to revert to a clean ghc install just by removing your ~/.ghc/$arch/ghc-6.8.2/package.conf file which will unregister *all* locally registered packages. To unregister individual packages use ghc-pkg --user unregister $pkgname
Duncan
On Tue, 2008-06-03 at 00:04 -0500, Galchin, Vasili wrote:
Duncan,
By installing localling, I "runhaskell Setup.hs configure --prefix=$HOME" plus add local path to LD_LIBRARY_PATH and LD_RUN_PATH? On Linux, does ghc use .so's or is it linked statically?
ghc is linked statically but when you do things like runhaskell Setup.hs you're asking ghc to dynamically load packages. runhaskell/runghc is basically a form of ghci, and ghci does dynamic code loading. If you've broken some of the packages that ghci loads and runs code from then you'll run into problems, mysterious segfaults and the like. As I understand it, in the next version of ghc it will track the ABI of each package so we would be able to detect when people replace packages with ones with the same version but with a different ABI (as you've been doing) and refuse to link or run in those cases rather than running and ending up with segfaults. Duncan
participants (3)
-
Brandon S. Allbery KF8NH -
Duncan Coutts -
Galchin, Vasili