Re: Understanding ghc-pkg dependencies when not using cabal
On Sat, Jun 2, 2012 at 5:38 AM, Joachim Breitner wrote: > Hi, > > as I’m involved with the Debian packaging I can probably answer a few of > your questions. > > Am Samstag, den 02.06.2012, 00:01 +1000 schrieb Tim Cuthbertson: >> For an example, lets use ansi-terminal [1] (and assume we're building >> it on a unix host) >> >> ansi-terminal depends on `base` and `unix` packages. Do these need to >> be present in source form, or just in "compiled package" form? I'm >> assuming the latter. >> (by "compiled package", I mean the stuff that ends up in e.g >> ~/.cabal/lib/PACKAGENAME) > > Correct. See > http://packages.debian.org/sid/amd64/libghc-ansi-terminal-dev/filelist > for what Debian packages contain; that is sufficient to build libraries > depending on this one. (We have separate -prof and -doc packages, > though.) > >> When I built ansi-terminal, the package.conf I got out of `cabal >> register` had the following field: >> >> depends: base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e >> unix-2.5.1.0-c004d6a0692bba682bbf2ac7b61d8322 >> >> So presumably this is the exact version that was used for compilation. >> Obviously the first part is the version, but what is the second part? >> Is it the abi-hash of the library that was used at compile time? > > It is a hash across everything that is being exposed by the library, so > yes. > >> If I want to use ansi-terminal in a program that I'm compiling, how >> strict are these dependencies? Will a `unix` package of a different >> version and the same abi-hash be acceptable? Does it need to be >> strictly _newer_ than 2.5.1.0 (and still have the same abi-hash)? Or >> is this an exact dependency? If I distribute the `unix` library in >> compiled form, how likely is it that a given compiled version of >> `unix` will satisfy the requirement? > > They are very strict, i.e. both version _and_ hash have to match. > >> If I have compiled two libraries that both depend on `unix`, but they >> ended up referencing a different abi-hash of `unix` (maybe I compiled >> them on a different computer, or on slightly different versions of the >> source), what happens when I try to compile an application that >> depends on these two libraries? I presume it couldn't work, > > it can work, at least if the unix libraries they have _different_ > versions and the two libraries do not try to interact using types or > type classes from unix. We have had this situation with parsec-2 and > parsec-3 for a while in Debian and worked ok, but should probably be > avoided. > >> even if I >> had registered both versions of `unix` simultaneously (is this even >> possible to do?). > > AFAIK it is not yet possible, but it is planned to make that possible. > >> Under what circumstances will the same package source code (e.g >> "unix-2.5.1.0") have two different abi-hashes? From [2], it sounds >> like only major GHC version changes should affect it. Is the abi-hash >> consistent on different platforms (assuming the same major GHC version >> is used)? > > Different GHC versions, different versions of depending libraries, in > some cases other stuff. E.g. the abi hash of the ghc library itself > varies depending on the version number of the ghc you compile ghc with. > So the first build of a new ghc version has a different abi hash than > the second build (if it is the first built with the new version). This > causes some problems here on the Debian front. Generally assume ABI > hashes to be fragile, and be happy if they don’t change. > >> Can the output of `ghc --abi-hash` (with no arguments) be used as a >> "linkage" restriction? (i.e if I have the exact same source and two >> versions of ghc with the same abi-hash, will the compiled library >> necessarily end up with the same abi-hash in both cases?). > > Likely, but I suggest not to rely on it in your packaging processes. Or > at least prepare to detect if it goes wrong and clean up. > >> If the `unix` package releases a new version that is compatible with >> ansi-terminal, what would I have to do to get this updated code into >> my application (that depends on ansi-terminal)? >> - install new version of `unix`, and recompile my application >> - as above, but also rebuilding the current version of >> `ansi-terminal` before I rebuild my application (despite ansi-terminal >> not actually changing itself) > > The latter. > >> Perhaps the above question could be rephrased as "if a new version of >> `unix` is source-compatible with the previous, what
Understanding ghc-pkg dependencies when not using cabal
Hi all,
I'm very interested in distributing ghc packages via zero-install [0].
I'm excited about ghc 7.4's ${pkgroot} support, since it means that
many packages could now be made relocatable (as long as they don't
need to know about paths to resources, etc). But I'm having some
trouble understanding exactly what relationships exist between
packages and when packages are needed / used. I have a lot of
questions. Answering all of them would be wonderful, but even just
some at least would be handy too ;)
For an example, lets use ansi-terminal [1] (and assume we're building
it on a unix host)
ansi-terminal depends on `base` and `unix` packages. Do these need to
be present in source form, or just in "compiled package" form? I'm
assuming the latter.
(by "compiled package", I mean the stuff that ends up in e.g
~/.cabal/lib/PACKAGENAME)
When I built ansi-terminal, the package.conf I got out of `cabal
register` had the following field:
depends: base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e
unix-2.5.1.0-c004d6a0692bba682bbf2ac7b61d8322
So presumably this is the exact version that was used for compilation.
Obviously the first part is the version, but what is the second part?
Is it the abi-hash of the library that was used at compile time?
If I want to use ansi-terminal in a program that I'm compiling, how
strict are these dependencies? Will a `unix` package of a different
version and the same abi-hash be acceptable? Does it need to be
strictly _newer_ than 2.5.1.0 (and still have the same abi-hash)? Or
is this an exact dependency? If I distribute the `unix` library in
compiled form, how likely is it that a given compiled version of
`unix` will satisfy the requirement?
If I have compiled two libraries that both depend on `unix`, but they
ended up referencing a different abi-hash of `unix` (maybe I compiled
them on a different computer, or on slightly different versions of the
source), what happens when I try to compile an application that
depends on these two libraries? I presume it couldn't work, even if I
had registered both versions of `unix` simultaneously (is this even
possible to do?).
Under what circumstances will the same package source code (e.g
"unix-2.5.1.0") have two different abi-hashes? From [2], it sounds
like only major GHC version changes should affect it. Is the abi-hash
consistent on different platforms (assuming the same major GHC version
is used)?
Can the output of `ghc --abi-hash` (with no arguments) be used as a
"linkage" restriction? (i.e if I have the exact same source and two
versions of ghc with the same abi-hash, will the compiled library
necessarily end up with the same abi-hash in both cases?).
If the `unix` package releases a new version that is compatible with
ansi-terminal, what would I have to do to get this updated code into
my application (that depends on ansi-terminal)?
- install new version of `unix`, and recompile my application
- as above, but also rebuilding the current version of
`ansi-terminal` before I rebuild my application (despite ansi-terminal
not actually changing itself)
Perhaps the above question could be rephrased as "if a new version of
`unix` is source-compatible with the previous, what recompilation (if
any) of downstream libraries is / could be required?
I know that ghc compiles applications statically by default. Given
this, I'm a little confused by the lifetime of packages in ghc. Are
packages (in the sense of "the stuff that is listed by `ghc-pkg
list`") only required at compilation time? If I run a precompiled
program that depends on another haskell package which has been
compiled as a shared library, does this mean I need the ghc package to
be registered, or is it sufficient to just have the compiled .so on my
$LD_LIBRARY_PATH?
Apologies for the large number of questions, and thanks for your time.
- Tim.
[0]: http://0install.net/
[1]: http://hackage.haskell.org/package/ansi-terminal-0.5.5
[2]: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Packages
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
On Thu, May 31, 2012 at 2:41 AM, Ian Lynagh wrote: > On Wed, May 30, 2012 at 08:44:26PM +1000, Tim Cuthbertson wrote: >> >> Configuring hsc2hs-0.67... >> make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. >> make: *** [all] Error 2 >> >> Any hints? > > That file should be included in the source tarball. > > > Thanks > Ian > Ahh, whoops. I had done a `git init && git add * && git commit -m 'pristine'` so that I could see what changed after a full build, or easily start over if I did something wrong. But since I'd tried it a couple of times I'd also done a `git clean -fdx && git reset --hard` (to get back to the pristine state). It turns out that some .gitignore files are included in the source tarball (all under libraries/*/.gitignore), so it actually cleaned up files that were supposed to be there. I'm not sure if it was intentional to include the .gitignore files in the tarball, but it seems like a surprising thing to do. Thanks, - Tim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
I've rm -rf'd my ~/.cabal to ensure old stuff doesn't get in the way, installed all the dependencies (on fedora 17, bootstrapping with ghc-7.0.4), unpacked the ghc-7.4.1 tarball, and run: ./configure --prefix=`pwd`/installed && make && make install and here's the log: https://gist.github.com/20dd47cfac4c8bbe498c (sorry I missed the top, `tee` didn't work right and my scrollback buffer wasn't big enough. I think I got the important stuff though). there seems to be a lot of "*/*.hi is missing (ignoring)" messages, culminating in: Configuring hsc2hs-0.67... make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. make: *** [all] Error 2 Any hints? Cheers, - Tim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc trac not sending verification emails?
On Tue, May 29, 2012 at 10:38 AM, Ian Lynagh wrote: > On Tue, May 29, 2012 at 10:09:47AM +1000, Tim Cuthbertson wrote: >> I signed up for an account on http://hackage.haskell.org/trac/ghc/ to >> report a couple of bugs, but can't file them until my email address is >> verified. >> >> I've tried two different email addresses, waited more than 24 hours, >> and checked my spam folder but sill don't see anything. Is email >> sending busted? I know that the cabal trac is migrating to github, >> does that affect GHC's trac as well? > > Looks like we sent 2 mails to t...@gfxmonk.net, at: > 2012-05-26 22:18:31 > 2012-05-27 04:46:20 > (I think those times are in PDT). > > > Thanks > Ian > Oh damn, looks like I had an old rule to delete emails from cvs-...@haskell.org for some reason (I think I was finding the hackage commit emails all too much some time ago). Terribly sorry for the trouble, - Tim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: relocatable packages: GHC_PACKAGE_PATH and package.conf
On Tue, May 29, 2012 at 12:24 AM, Duncan Coutts
wrote:
> On 28 May 2012 05:36, Tim Cuthbertson wrote:
>
>> - ghc doesn't seem to support ${pkgroot} prefixes. I thought it did,
>> but I'm new to this so I may be misunderstanding where they can be
>> used.
>
> I thought it did too since I think I wrote the code for it. I don't
> recall exactly what version it got into, it may well have been only
> 7.2+
Ahh, right you are - I must have looked at the "reported" version
instead of "milestone" in the bug:
$ git name-rev --tags 40b6bd47cf00f025426746bbd7abdd0eda2a3afd
40b6bd47cf00f025426746bbd7abdd0eda2a3afd tags/ghc-7.2.1-release~397
I'll have to compile it myself, but that's much better than it simply
not working ;)
>> Additionally, the paths that come out of cabal build have the compiler
>> name and version hard coded, e.g lib/packagename/ghc-7.0.4/*. Is there
>> any way to configure how this path is constructed to get rid of the
>> ghd-7.0.4 part?
>
> By default, yes, cabal produces absolute packages. It does have
> support for relocatable packages on some compiler/platform combos:
>
> http://www.haskell.org/cabal/users-guide/installing-packages.html#prefix-independence
>
> sadly ghc on unix is not one of them because we do not have a reliable
> way to find the program location (needed to find data files etc).
> Actually more specifically it's not easy and nobody has implemented
> it, rather than it being impossible.
>
> So at the moment you could work around it in specific cases by hacking
> the package registration info before registering. Do something like:
> cabal copy --destdir=...
> cabal register --gen-pkg-config=blah.pkg
> sed -i =e '...' blah.pkg
>
> Obviously your app/library had better not use the Cabal-provided
> functions for finding data files at runtime since that'll get
> confused.
>
> If you want a proper solution you'll have to help us implement the
> Cabal prefix independence feature for the ghc/unix combo.
Cheers, yeah I'd like to get this working on a simple library first -
so I'm not bothered about the inability to find data files.
But once that's working, I'm sufficiently convinced that this needs to
work to help / implement it myself. When you say it's possible but
nobody's happened to implement it yet, do you have any more specific
hints to give? This would be my first time hacking on GHC, so
hopefully it's not too massive a task.
Thanks,
- Tim.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc trac not sending verification emails?
I signed up for an account on http://hackage.haskell.org/trac/ghc/ to report a couple of bugs, but can't file them until my email address is verified. I've tried two different email addresses, waited more than 24 hours, and checked my spam folder but sill don't see anything. Is email sending busted? I know that the cabal trac is migrating to github, does that affect GHC's trac as well? Cheers, - Tim. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
relocatable packages: GHC_PACKAGE_PATH and package.conf
Hi all,
I'm trying to build a relocatable package using cabal, and running
into some difficulties.
I've created / used the following script to attempt to create a
relocatable package:
https://github.com/gfxmonk/0compile-cabal-build/blob/2cf4a08b146333d9292f6f8fd38431dd5c5c80f1/cabal-build
When this is done I have something that looks like it should work, and
has an inline package.conf. But when I run the following:
---
$ export
GHC_PACKAGE_PATH="/home/tim/dev/haskell/third-party/haskell-ansi-terminal/haskell-ansi-terminal-linux-x86_64/package.conf:"
$ ghc-pkg check
There are problems in package ansi-terminal-0.5.5:
import-dirs: ${pkgroot}/lib is a relative path
library-dirs: ${pkgroot}/lib is a relative path
file System/Console/ANSI.hi is missing
file System/Console/ANSI/Unix.hi is missing
file System/Console/ANSI/Common.hi is missing
cannot find libHSansi-terminal-0.5.5.a on library path
The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
ansi-terminal-0.5.5
---
So it looks like:
- I need to set more environment variabes so that ghc can find the
parts of the package (e.g libHSansi-terminal-0.5.5.a). Unfortunately,
I don't know what "library path" refers to in the above message (I
tried $LD_LIBRARY_PATH and $LIB_PATH to no avail).
- ghc doesn't seem to support ${pkgroot} prefixes. I thought it did,
but I'm new to this so I may be misunderstanding where they can be
used.
Can anyone suggest what I might need to fix (either in the
package.conf or in my environment variables) to get this working?
I've uploaded my package.conf here, apologies for the lack of formatting:
https://gist.github.com/59a0d3e69751c3932579
Additionally, the paths that come out of cabal build have the compiler
name and version hard coded, e.g lib/packagename/ghc-7.0.4/*. Is there
any way to configure how this path is constructed to get rid of the
ghd-7.0.4 part?
If I need to add $DISTDIR/ansi-terminal-0.5.5/ghc-7.0.4/ to a library
path, it would be much easier to declare that if it didn't depend on
the version of GHC used. Assume that since I'm building a standalone
package, there is no problem with collisions (packages for other
versions of GHC or other compilers would have a different $PREFIX).
I'd really like to get relocatable packages working, so any help or
guidance would be appreciated.
Cheers,
- Tim.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
