Gasgow Haskell compiler

General talk about packaging procedures and packages.
User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Gasgow Haskell compiler

Post by mimosa » 24. Oct 2012, 15:04

Would it be OK if I packaged ghc? There is a slackbuild but it doesn't work without a hack for an old version of a library. It's also rather a long build, and ghc is a dep for xmonad. The package would also be useful for anyone with an interest in Haskell itself. That version of ghc is the one to have to work with Haskell-platform, which is sort of Haskell's IDE. At least, the 'official' choice would actually be the version of ghc prior to that, but that one works; and a newer one (perhaps without the missing library problem) might well not.

I should mention I don't fully understand the policy on what to package or not. I used to be under the impression that if there's a slackbuild, don't package it unless it is a dependency of something you're packaging - but it seems that isn't quite right. This is a case where there is a real advantage to making a package (the missing library problem has come up several times in the Salix forum) and Haskell is a major, up-and-coming language.

I would do it without the hack, like this:

http://www.salixos.org/forum/viewtopic. ... gmp#p25086

User avatar
fredg
Posts: 232
Joined: 3. Oct 2009, 16:50
Location: Lyon, France
Contact:

Re: Gasgow Haskell compiler

Post by fredg » 24. Oct 2012, 16:03

Would it be OK if I packaged ghc?
Yes of course.
I should mention I don't fully understand the policy on what to package or not.
I think that if you want to maintain a package just go ahead ;)

++

User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Re: Gasgow Haskell compiler

Post by mimosa » 24. Oct 2012, 16:24

Thanks fredg; I'll go ahead then. Let's see if I have time before the repos are frozen 8-)

I posted the missing library file in my repo some time back. Is it OK to just use that (perhaps including the source file for transparency) or should I actually be building the library in my SLKBUILD? I see no difficulty in so doing, but I've never seen a SLKBUILD like that; normally, it would be a separate package, but this one doesn't do anything on its own and one wouldn't want to install the (ancient) library as such. Obviously, I will need to rebuild the file in question for both architectures.

If it's not clear what I'm talking about, maybe the post I linked to above will make it clear.

User avatar
fredg
Posts: 232
Joined: 3. Oct 2009, 16:50
Location: Lyon, France
Contact:

Re: Gasgow Haskell compiler

Post by fredg » 24. Oct 2012, 17:36

I think that the best and proper way is to build it in your SLKBUILD.

++

User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Re: Gasgow Haskell compiler

Post by mimosa » 24. Oct 2012, 17:44

It also occurred to me that if I supply a binary, it would need to be different for each arch, which would be almost as fiddly. I can see I'm going to have fun with this one! :mrgreen:

User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Re: Gasgow Haskell compiler

Post by mimosa » 25. Oct 2012, 10:49

A further puzzle is that the source is different for each arch. I believe that it contains a skeleton binary compiler used to bootstrap the build of the actual compiler. This is a big file (>100MB).

Is it better to have a separate SLKBUILD for each arch or just have it download both files and let the build script choose which one to work with later?

EDIT

Also, thinking of this problem and also compiling the library: what does slkbuild do with any tarballs in the source line? Looks like if there's just one, it gets unpacked into src/$pkgname/$pkgver. But in the case of the libgmp tarball, I want to unpack it into a subdirectory. Or does everything automatically get unpacked into its own subdirectory, with uncompressed files simply being copied over? I had a look at the code for slkbuild but got lost :shock:

EDIT2

I've partially answered my own question by creating a dummy SLKBUILD with the build section largely commented out - libgmp gets put in its own directory, and I can build it there and manually transfer what's needed to pkg/foo/bar. But I'm still not sure whether I should be making separate SLKBUILDs for each architecture.

EDIT 3

I compared the size of the directories and it seems clear the 64-bit version was untarred over the top of the 32-bit one (which comes first in alphabetical order, i before x). So slkbuild is *not* making an intelligent choice based on the architecture - no reason to expect it would.

EDIT 4

Solved, pinched from the SlackBuild:

Code: Select all

#arch=noarch
#choose which source tarball we want to fit the architecture
case "$( uname -m )" in
	i?86) tararch=i386 ;;
	x86_64) tararch=x86_64 ;;
	*) tararch=$( uname -m ) ;;
esac

source=("http://www.haskell.org/ghc/dist/7.4.2/ghc-7.4.2-$tararch-unknown-linux.tar.bz2" "http://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2")

User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Re: Gasgow Haskell compiler

Post by mimosa » 25. Oct 2012, 15:34

I've come up against a different problem now: this library is a build-time dependency (and may be a run-time dependency too for some purposes, though I've never had any trouble without it). So after the build script has created it, not only does it need to go in the right place in $startdir/pkg, but it needs to be placed in /usr/lib IRL in order to build ghc itself. But that requires being root.

Code: Select all

build() {
	#build old version of libgmp
	cd $startdir/src/gmp-4.3.2
	./configure
	make
	make check
	mkdir -p $startdir/pkg/usr/lib
	cp -P ./.libs/libgmp.so.3* $startdir/pkg/usr/lib # -P to copy the symlink and not the file it points at
	cp -P ./.libs/libgmp.so.3* /usr/lib # this is a build dependency so we need it now
	#build ghc
	cd $startdir/src/$pkgname-$pkgver
	./configure --prefix=/usr --libdir=/usr/lib${LIBDIRSUFFIX} --mandir=/usr/man --docdir=/usr/doc
	make install DESTDIR=$startdir/pkg
	chmod -R go-w $startdir/pkg/usr/doc
} 
I could obviously just do that manually, but it kind of defeats the object of making the SLKBUILD build it.

What is the correct way to approach this?

User avatar
fredg
Posts: 232
Joined: 3. Oct 2009, 16:50
Location: Lyon, France
Contact:

Re: Gasgow Haskell compiler

Post by fredg » 25. Oct 2012, 15:44

I will run slkbuild as root (can be done only if you are sure what you are doing ;) ).

Just add cp YOUR_LIB to /usr/lib{LIBDIRSUFFIX}/ in your SLKBUILD
..
build
..
And, at the end, clean up:
rm /usr/lib{LIBDIRSUFFIX}/YOUR_LIB

++

User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Re: Gasgow Haskell compiler

Post by mimosa » 25. Oct 2012, 15:58

(can be done only if you are sure what you are doing ;))
Moi? ;)

I thought of another approach: first build the library, then check /usr/lib on the build system to see if it's already there. If not, echo a message telling the user to do it (and where to find the file and symlink).

A problem with your way as well is what if the user already has that file and wants to keep it? OK, installing the package will putit back ... maybe it doesn't matter. But if it matters, you could check first, and only remove the file if it wasn't present initially.

Thanks fredg.

User avatar
mimosa
Salix Warrior
Posts: 3094
Joined: 25. May 2010, 17:02
Contact:

Re: Gasgow Haskell compiler

Post by mimosa » 27. Oct 2012, 03:00

Just tried to build the package for 64 bits, and the library build failed. I think this may be a situation where something needs to be set in the cflags line in the SLKBUILD:

Code: Select all

tar -xf gmp-4.3.2.tar.bz2
checking build system type... viac32-unknown-linux-gnu
checking host system type... viac32-unknown-linux-gnu
checking for a BSD-compatible install... /bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=32
checking compiler gcc -O2 -fPIC ... yes
checking compiler gcc -O2 -fPIC has sizeof(long)==4... no
checking compiler icc -O2 -fPIC ... no
checking whether cc is gcc... yes
checking compiler cc -O2 -fPIC ... yes
checking compiler cc -O2 -fPIC has sizeof(long)==4... no
configure: error: could not find a working compiler, see config.log for details
I've yet to try for i486.

Post Reply