Is anyone using ghc-ios with cabal sandbox? I am having trouble with it. I can 'cabal-ios install’ fine. That installs the packages properly in the sandbox for arm and x86. But the ghc-ios script doesn’t use the sandbox environment. And running a simple 'cabal exec ghc-ios …’ clobbers the package-db path: I get... "Using binary package database: /…/sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache” and then a bunch of errors like: Bad interface file: /usr/local/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052) I guess the best solution is for cabal’s exec command to respect the arguments that cabal-ios provides. But maybe in the meantime perhaps I can tweak the ghc-ios script to add an argument to look for the presence of sandboxing, unless anyone else has a better idea. Thanks, Axis
Hi Axis,
I'm looking at my notes from my (brief) attempt to try sandboxes with
ghc-ios, and it looks like one major issue is that the --builddir flag
isn't paid attention to when installing into a sandbox, thus the object
files from different architectures get mixed up. That will likely need a
patch to cabal (I don't think many of the cabal devs are using multiple
architectures/cross compilation) -- filing a bug would be great.
Best
Luke
On Wed, Oct 15, 2014 at 1:57 PM, Axis Sivitz
Is anyone using ghc-ios with cabal sandbox? I am having trouble with it.
I can 'cabal-ios install' fine. That installs the packages properly in the sandbox for arm and x86.
But the ghc-ios script doesn't use the sandbox environment. And running a simple 'cabal exec ghc-ios ...' clobbers the package-db path:
I get... "Using binary package database: /.../sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache" and then a bunch of errors like: Bad interface file: /usr/local/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052)
I guess the best solution is for cabal's exec command to respect the arguments that cabal-ios provides. But maybe in the meantime perhaps I can tweak the ghc-ios script to add an argument to look for the presence of sandboxing, unless anyone else has a better idea.
Thanks, Axis
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
Oh, I think you’re right, it wasn’t actually installing correctly. I will
file a bug with cabal.
Thanks
On Wed, Oct 15, 2014 at 6:58 PM, Luke Iannini
Hi Axis,
I'm looking at my notes from my (brief) attempt to try sandboxes with ghc-ios, and it looks like one major issue is that the --builddir flag isn't paid attention to when installing into a sandbox, thus the object files from different architectures get mixed up. That will likely need a patch to cabal (I don't think many of the cabal devs are using multiple architectures/cross compilation) — filing a bug would be great.
Best Luke
On Wed, Oct 15, 2014 at 1:57 PM, Axis Sivitz
wrote: Is anyone using ghc-ios with cabal sandbox? I am having trouble with it.
I can 'cabal-ios install’ fine. That installs the packages properly in the sandbox for arm and x86.
But the ghc-ios script doesn’t use the sandbox environment. And running a simple 'cabal exec ghc-ios …’ clobbers the package-db path:
I get... "Using binary package database: /…/sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache” and then a bunch of errors like: Bad interface file: /usr/local/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052)
I guess the best solution is for cabal’s exec command to respect the arguments that cabal-ios provides. But maybe in the meantime perhaps I can tweak the ghc-ios script to add an argument to look for the presence of sandboxing, unless anyone else has a better idea.
Thanks, Axis
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
I filed a bug: https://github.com/haskell/cabal/issues/2213
Someone commented that it should basically work.
I’m trying to track down exactly where it goes wrong for me. There’s a
problem in the way "cabal exec” interacts with the ghc-ios script.
If I run…
ghc-ios -v3 test.hs
Glasgow Haskell Compiler, Version 7.8.3, stage 1 booted by GHC version 7.8.2
Using binary package database:
/usr/local/lib/arm-apple-darwin10-ghc-7.8.3/package.conf.d/package.cache
Using binary package database:
/Users/axis/.ghc/arm-ios-7.8.3/package.conf.d/package.cache
It correctly finds the package database.
But if I run…
cabal exec ghc-ios -- -v3 test.hs
Glasgow Haskell Compiler, Version 7.8.3, stage 1 booted by GHC version 7.8.2
Using binary package database:
/usr/local/lib/ghc-7.8.3/package.conf.d/package.cache
Using binary package database:
/Users/axis/sandbox/.cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache
It correctly uses the sandbox, but not the arm ghc.
I looked into /usr/local/bin/arm-apple-darwin10-ghc, which does the
following:
#!/bin/sh
exedir="/usr/local/lib/arm-apple-darwin10-ghc-7.8.3/bin"
exeprog="ghc-stage1"
executablename="$exedir/$exeprog"
datadir="/usr/local/share"
bindir="/usr/local/bin"
topdir="/usr/local/lib/arm-apple-darwin10-ghc-7.8.3"
executablename="$exedir/ghc"
exec "$executablename" -B"$topdir" ${1+"$@“}
I’m not sure what’s going on at the end (what is the -B flag?), but somehow
that topdir variable doesn’t make it through the sandbox call.
Thanks for your help.
On Wed, Oct 15, 2014 at 9:30 PM, Axis Sivitz
Oh, I think you’re right, it wasn’t actually installing correctly. I will file a bug with cabal.
Thanks
On Wed, Oct 15, 2014 at 6:58 PM, Luke Iannini
wrote: Hi Axis,
I'm looking at my notes from my (brief) attempt to try sandboxes with ghc-ios, and it looks like one major issue is that the --builddir flag isn't paid attention to when installing into a sandbox, thus the object files from different architectures get mixed up. That will likely need a patch to cabal (I don't think many of the cabal devs are using multiple architectures/cross compilation) — filing a bug would be great.
Best Luke
On Wed, Oct 15, 2014 at 1:57 PM, Axis Sivitz
wrote: Is anyone using ghc-ios with cabal sandbox? I am having trouble with it.
I can 'cabal-ios install’ fine. That installs the packages properly in the sandbox for arm and x86.
But the ghc-ios script doesn’t use the sandbox environment. And running a simple 'cabal exec ghc-ios …’ clobbers the package-db path:
I get... "Using binary package database: /…/sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache” and then a bunch of errors like: Bad interface file: /usr/local/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052)
I guess the best solution is for cabal’s exec command to respect the arguments that cabal-ios provides. But maybe in the meantime perhaps I can tweak the ghc-ios script to add an argument to look for the presence of sandboxing, unless anyone else has a better idea.
Thanks, Axis
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
The arm-apple-darwin10-ghc wrapper is autogenerated during GHC installation
and I don't think ghcios changes anything there (e.g. /usr/local/bin/ghc
looks nearly identical)
Oh, here's the likely culprit: the cabal.sandbox.config hardcodes the
packages.conf.d -- e.g. in one of my projects it placed:
package-db:
/Users/lukexi/Projects/Thop/.cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d
On Thu, Nov 13, 2014 at 11:32 AM, Axis Sivitz
I filed a bug: https://github.com/haskell/cabal/issues/2213 Someone commented that it should basically work.
I'm trying to track down exactly where it goes wrong for me. There's a problem in the way "cabal exec" interacts with the ghc-ios script.
If I run...
ghc-ios -v3 test.hs Glasgow Haskell Compiler, Version 7.8.3, stage 1 booted by GHC version 7.8.2 Using binary package database: /usr/local/lib/arm-apple-darwin10-ghc-7.8.3/package.conf.d/package.cache Using binary package database: /Users/axis/.ghc/arm-ios-7.8.3/package.conf.d/package.cache
It correctly finds the package database.
But if I run...
cabal exec ghc-ios -- -v3 test.hs Glasgow Haskell Compiler, Version 7.8.3, stage 1 booted by GHC version 7.8.2 Using binary package database: /usr/local/lib/ghc-7.8.3/package.conf.d/package.cache Using binary package database: /Users/axis/sandbox/.cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache
It correctly uses the sandbox, but not the arm ghc.
I looked into /usr/local/bin/arm-apple-darwin10-ghc, which does the following:
#!/bin/sh exedir="/usr/local/lib/arm-apple-darwin10-ghc-7.8.3/bin" exeprog="ghc-stage1" executablename="$exedir/$exeprog" datadir="/usr/local/share" bindir="/usr/local/bin" topdir="/usr/local/lib/arm-apple-darwin10-ghc-7.8.3" executablename="$exedir/ghc" exec "$executablename" -B"$topdir" ${1+"$@"}
I'm not sure what's going on at the end (what is the -B flag?), but somehow that topdir variable doesn't make it through the sandbox call.
Thanks for your help.
On Wed, Oct 15, 2014 at 9:30 PM, Axis Sivitz
wrote: Oh, I think you're right, it wasn't actually installing correctly. I will file a bug with cabal.
Thanks
On Wed, Oct 15, 2014 at 6:58 PM, Luke Iannini
wrote: Hi Axis,
I'm looking at my notes from my (brief) attempt to try sandboxes with ghc-ios, and it looks like one major issue is that the --builddir flag isn't paid attention to when installing into a sandbox, thus the object files from different architectures get mixed up. That will likely need a patch to cabal (I don't think many of the cabal devs are using multiple architectures/cross compilation) -- filing a bug would be great.
Best Luke
On Wed, Oct 15, 2014 at 1:57 PM, Axis Sivitz
wrote: Is anyone using ghc-ios with cabal sandbox? I am having trouble with it.
I can 'cabal-ios install' fine. That installs the packages properly in the sandbox for arm and x86.
But the ghc-ios script doesn't use the sandbox environment. And running a simple 'cabal exec ghc-ios ...' clobbers the package-db path:
I get... "Using binary package database: /.../sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache" and then a bunch of errors like: Bad interface file: /usr/local/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052)
I guess the best solution is for cabal's exec command to respect the arguments that cabal-ios provides. But maybe in the meantime perhaps I can tweak the ghc-ios script to add an argument to look for the presence of sandboxing, unless anyone else has a better idea.
Thanks, Axis
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
Ah ok, thanks. That makes sense. I tried changing that line to use
variables ($os, $arch, etc.), but it doesn’t seem to pick them up for some
reason. I’ll take that back to the cabal issue I filed.
On Thu, Nov 13, 2014 at 11:57 PM, Luke Iannini
The arm-apple-darwin10-ghc wrapper is autogenerated during GHC installation and I don't think ghcios changes anything there (e.g. /usr/local/bin/ghc looks nearly identical)
Oh, here's the likely culprit: the cabal.sandbox.config hardcodes the packages.conf.d — e.g. in one of my projects it placed: package-db: /Users/lukexi/Projects/Thop/.cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d
On Thu, Nov 13, 2014 at 11:32 AM, Axis Sivitz
wrote: I filed a bug: https://github.com/haskell/cabal/issues/2213 Someone commented that it should basically work.
I’m trying to track down exactly where it goes wrong for me. There’s a problem in the way "cabal exec” interacts with the ghc-ios script.
If I run…
ghc-ios -v3 test.hs Glasgow Haskell Compiler, Version 7.8.3, stage 1 booted by GHC version 7.8.2 Using binary package database: /usr/local/lib/arm-apple-darwin10-ghc-7.8.3/package.conf.d/package.cache Using binary package database: /Users/axis/.ghc/arm-ios-7.8.3/package.conf.d/package.cache
It correctly finds the package database.
But if I run…
cabal exec ghc-ios -- -v3 test.hs Glasgow Haskell Compiler, Version 7.8.3, stage 1 booted by GHC version 7.8.2 Using binary package database: /usr/local/lib/ghc-7.8.3/package.conf.d/package.cache Using binary package database: /Users/axis/sandbox/.cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache
It correctly uses the sandbox, but not the arm ghc.
I looked into /usr/local/bin/arm-apple-darwin10-ghc, which does the following:
#!/bin/sh exedir="/usr/local/lib/arm-apple-darwin10-ghc-7.8.3/bin" exeprog="ghc-stage1" executablename="$exedir/$exeprog" datadir="/usr/local/share" bindir="/usr/local/bin" topdir="/usr/local/lib/arm-apple-darwin10-ghc-7.8.3" executablename="$exedir/ghc" exec "$executablename" -B"$topdir" ${1+"$@“}
I’m not sure what’s going on at the end (what is the -B flag?), but somehow that topdir variable doesn’t make it through the sandbox call.
Thanks for your help.
On Wed, Oct 15, 2014 at 9:30 PM, Axis Sivitz
wrote: Oh, I think you’re right, it wasn’t actually installing correctly. I will file a bug with cabal.
Thanks
On Wed, Oct 15, 2014 at 6:58 PM, Luke Iannini
wrote: Hi Axis,
I'm looking at my notes from my (brief) attempt to try sandboxes with ghc-ios, and it looks like one major issue is that the --builddir flag isn't paid attention to when installing into a sandbox, thus the object files from different architectures get mixed up. That will likely need a patch to cabal (I don't think many of the cabal devs are using multiple architectures/cross compilation) — filing a bug would be great.
Best Luke
On Wed, Oct 15, 2014 at 1:57 PM, Axis Sivitz
wrote: Is anyone using ghc-ios with cabal sandbox? I am having trouble with it.
I can 'cabal-ios install’ fine. That installs the packages properly in the sandbox for arm and x86.
But the ghc-ios script doesn’t use the sandbox environment. And running a simple 'cabal exec ghc-ios …’ clobbers the package-db path:
I get... "Using binary package database: /…/sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/package.cache” and then a bunch of errors like: Bad interface file: /usr/local/lib/ghc-7.8.3/base-4.7.0.1/Prelude.hi magic number mismatch: old/corrupt interface file? (wanted 129742, got 33214052)
I guess the best solution is for cabal’s exec command to respect the arguments that cabal-ios provides. But maybe in the meantime perhaps I can tweak the ghc-ios script to add an argument to look for the presence of sandboxing, unless anyone else has a better idea.
Thanks, Axis
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
-- Axis Sivitz http://asivitz.com http://buttonbrigade.com/ (513) 535-1668
participants (2)
-
Axis Sivitz -
Luke Iannini