Re: gcc version for GHC 6.10.4 under Sparc/Solaris
On Fri, 2009-08-07 at 10:55 +0200, Christian Maeder wrote:
Duncan Coutts wrote:
I should also note that there is a GHC 6.10.4 binary for Sparc/Linux
that is now included with Gentoo. It's got all features turned on except
for split objects (which fails due to mixing ld -r and --relax flags).
In particular it's a registerised via-C build with ghci, TH and
profiling working.
Does compiling using gcc-4.3.x work if -fvia-C is added?
There's no Sparc NCG in the 6.10 series so it's only -fvia-C. The new
Sparc NCG is in 6.12. This build used gcc-4.1.2 which is the latest
stable one on Gentoo for sparc.
It's a distro package not a generic relocatable GHC binary tarball so
there's no point putting it on the ghc download page, but it's there
nevertheless if people want it (look for the gentoo ghc ebuild).
I've found
http://packages.gentoo.org/package/dev-lang/ghc
Where are ebuilds or downloadable binaries?
For non-gentoo users, the ebuilds are available from cvs:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/ghc/
eg 6.10.4:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/ghc/ghc-6.10.4.ebuild?view=markup
The binaries are not set up for separate distribution but if you inspect
the ebuild you find:
mirror://gentoo/ghc-bin-${PV}-sparc.tbz2
which means ghc-bin-6.10.4-sparc.tbz2 in the distfiles of any gentoo
mirror, eg:
http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/distfiles/ghc-bin-6.10.4-sparc.tbz2
It expects to unpack to / and installs under /usr however it's quite
possible to unpack to a temp dir and relocate the scripts and
package.conf using a bit of sed. In fact this is what the ebuild does
for the bootstrapping binary.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
On Fri, 2009-08-07 at 13:14 +0200, Christian Maeder wrote: Christian Maeder wrote: Matthias Kilian wrote: However, to create an archive, you can use something like $ pax -wf foo.tar directory Do you think gtar --format=posix would be different from pax? I would expect they are the same. The USTAR format is standardised by a POSIX standard from 1988 while the pax extensions are standardised by POSIX from 2001 I think. The pax program has an -x format flag and can use pax, ustar or cpio formats. The pax format is an extension of the ustar format. The only question is, if we should create archives using the ustar, posix/pax, or gnu format. ustar seems to be the least common denominator. Does ustar have any disadvantages? For source code distribution I think the ustar format is ideal. This is what cabal-install's sdist mode uses. As you say it's the lowest common denominator. The limitations of the format (file sizes, lack of extended file meta-data) are not a practical problem for source code or binaries. My plain tar command under solaris cannot handle the pax files, too. So ustar archives should be created (at least under solaris). That's odd since pax is supposed to be a compatible extension of ustar that just adds extra meta-data entries. Older programs should either ignore those entries or extract them as if they were ordinary files. But I don't know why the ustar format can handle long file names, The ustar format can handle file names up to 100+155 characters (bytes) long. The reason for 100+155 is that it's not simply 255. The split into a 100 and 155 field must happen on a directory separator. whereas the gnu format creates a @LongLink file and pax a PaxHeader file (when unpacked with tar). Right, those files are the extended entries. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell Platform 2009.2.0.2
On Thu, 2009-07-30 at 15:12 +0200, Christian Maeder wrote: Don Stewart wrote: Heads up lads, we're about 24 hours from Haskell Platform 2009.2.0.2 http://code.haskell.org/haskell-platform/haskell-platform.cabal I still see time ==1.1.2.4, although ghc-6.10.4 comes with: time-1.1.4 http://trac.haskell.org/haskell-platform/ticket/74 Is this on purpose (possibly installing two time versions)? Yes it is on purpose. The HP policy is to keep the same API for a whole major release series. That is, the API of packages included in each minor release of 2009.2.0.x are the same. The initial release 2009.2.0 included time-1.1.2.4 and so subsequent releases must use a compatible version. Version of time in the extralibs tarball in ghc-6.10.x releases: * GHC-6.10.1: time-1.1.2.4 * GHC-6.10.2: none * GHC-6.10.3: time-1.1.3 * GHC-6.10.4: time-1.1.4 So we have the current situation where the HP supplies one version and ghc's extralibs tarball includes a different version. As far as I know, the windows and osx HP installers (which include ghc) only include one version of time. For the source installer of course we cannot control other pre-existing versions. I only know that time-1.1.4 and time-1.1.3 supply more Typeable instances (which may break existing code) Right, that's not allowed in a HP minor release as it's an API change. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
