Opened 14 years ago

Closed 3 years ago

#284 closed feature request (invalid)

RPM doesn't support --prefix

Reported by: skaller Owned by: juhp
Priority: normal Milestone:
Component: Build System Version: None
Keywords: Cc: sven.panne@…, bos@…, ydewit@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: N/A
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by igloo)

After installing ghc for linux using rpm with
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:

# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}

After editing, at least the compiler actually starts up :)

Change History (22)

comment:1 Changed 14 years ago by simonmar

Status: assignedclosed
Logged In: YES 

You're trying to install the binary RPM using a different
prefix?  That's not supported, I'm afraid.

comment:2 Changed 14 years ago by skaller

Logged In: YES 

I can see it isn't supported :)

However after the change to those two lines, the compiler
works, links libraries, and the resultant binary executes
(as far as I can tell never having written any Haskell
before .. :)

So why not support it? I had no choice .. my root partition,
containing /usr is 97% full.. :)

comment:3 Changed 14 years ago by simonmar

Summary: minor bug in rpm (x86 linux)RPM doesn't support --prefix
Logged In: YES 

Re-opened.  Any RPM gurus out there who could knock this one
on the head?

Note it's not just the ghc script, there's a couple of other
scripts that need munging (ghci, ghc-pkg, hsc2hs maybe).

comment:4 Changed 13 years ago by nobody

Logged In: NO 

Still a problem with 6.2.4 - Additionally, you now need to
edit the package.conf file. 

Karl M. Syring

comment:5 Changed 13 years ago by juhp

Logged In: YES 

Not really sure what the right solution is - one hack that
comes to mind is adding a %post install script in the spec file
that would replace the default prefix with the specified one.

comment:6 Changed 13 years ago by juhp

Logged In: YES 

This is now fixed in Fedora Haskell as of ghc-6.4-7.
I will send in a spec file patch "as soon as the dust settles".

Feel free to assign this to me. :)

comment:7 Changed 12 years ago by igloo

Architecture: Unknown
Component: NoneBuild System
Description: modified (diff)
difficulty: Unknown
Milestone: 6.6.1
Operating System: Unknown
Owner: changed from nobody to juhp
Status: assignednew

What's the status of this?

comment:8 Changed 12 years ago by igloo

Test Case: N/A

comment:9 Changed 12 years ago by simonmar

Priority: normallow

comment:10 Changed 11 years ago by igloo

Priority: lownormal

We plan to change the build system to always work as if BIN_DIST was set, so the script would have $topdir in it rather than a fixed path. This would be substituted for at install time, so this bug should then be easily fixable.

We're not going to hold 6.6.1 up for it, but it should be easily doable for 6.6.2.

comment:11 Changed 11 years ago by simonmar


comment:12 Changed 11 years ago by simonmar

Cc: Panne <sven.panne@…> added

Sven, is anything happening regarding this bug? Do we intend to fix it?

comment:13 Changed 11 years ago by simonmar

Cc: sven.panne@… added; Panne <sven.panne@…> removed

fix CC

comment:14 Changed 10 years ago by igloo

Milestone: 6.8 branch_|_

comment:15 Changed 10 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:16 Changed 10 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:17 Changed 9 years ago by simonmar

Cc: bos@… added
Type of failure: None/Unknown

Bryan: this is an old bug against GHC. Is it worth keeping around, do you think?

comment:18 Changed 4 years ago by ydewit

There seems to be two areas that need to be fixed to support relocatable installs: the shell wrappers and the .conf files. Both of these set of files have absolute paths.

Regarding the shell wrappers (e.g. $GHC_HOME/bin/{ghc,ghc-pkg,ghci,runghc,runhaskell}), we could simply use a slightly different scheme. For instance, an alternative for the ghc wrapper:

GHC_HOME=$( cd $(dirname $0)/.. ; pwd )
exec "$executablename" -B"$topdir" ${1+"$@"}

The critical piece is GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) since it needs to work for all supported platforms. Other than that, it is pretty straight-forward.

I see that there is support for a RelocatableBuild variable in, but it is turned on only on Windows:

# On Windows we normally want to make a relocatable bindist, to we                                                                  
 # ignore flags like libdir                                                                                                          
 ifeq "$(Windows_Host)" "YES"                                                                                                        
 RelocatableBuild = YES                                                                                                              
 RelocatableBuild = NO                                                                                                               

So it seems that we have two different layouts: one for Windows and one for everything else:

exec_prefix     = ${prefix}
bindir          = ${exec_prefix}/bin
datadir         = ${datarootdir}
libdir          = ${exec_prefix}/lib
includedir      = ${prefix}/include
mandir          = ${datarootdir}/man

docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
$(eval $(call set_default,docdir,$${datarootdir}/doc/ghc))

htmldir = ${docdir}
dvidir  = ${docdir}
pdfdir  = ${docdir}
psdir   = ${docdir}
$(eval $(call set_default,htmldir,$${docdir}))
$(eval $(call set_default,dvidir,$${docdir}))
$(eval $(call set_default,pdfdir,$${docdir}))
$(eval $(call set_default,psdir,$${docdir}))

ifeq "$(RelocatableBuild)" "YES"

# Hack: our directory layouts tend to be different on Windows, so
# hack around configure's bogus assumptions here.
datarootdir = $(prefix)
datadir     = $(prefix)/lib
libdir      = $(prefix)/lib

docdir    = $(prefix)/doc
htmldir   = $(docdir)
dvidir    = $(docdir)
pdfdir    = $(docdir)
psdir     = $(docdir)

ghclibdir = $(libdir)
ghcdocdir = $(datarootdir)/doc


# Unix: override libdir and datadir to put ghc-specific stuff in
# a subdirectory with the version number included.
# datadir is set to libdir here as GHC needs package.conf and unlit
# to be in the same place (and things like ghc-pkg need to agree on
# where package.conf is, so we just set it globally).
ghclibdir     = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion)
ghcdocdir     = $(datarootdir)/doc/ghc

ghclibexecdir = $(ghclibdir)
topdir        = $(ghclibdir)
ghcheaderdir  = $(ghclibdir)/include

Why two layouts?

I also see that the non-windows layout is accounting for cross compilation, which is doesn't seem supported in the Windows layout.

comment:19 Changed 4 years ago by ydewit

Cc: ydewit@… added

comment:20 Changed 4 years ago by carter

I don't think relocating is quite that simple. Eg On OS X, dylibs can't use relative paths (last I checked), so relocating dylibs requires an invocation of the install-name-tool to fixup the paths!

(my recollection could be totally wrong mind you)

comment:21 Changed 4 years ago by ydewit

This is what I see with otool -L:

/t/g/l/g/array- ❯❯❯ otool -L libHSarray-
	@rpath/libHSarray- (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	@rpath/libHSbase- (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSinteger-gmp- (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSghc-prim- (compatibility version 0.0.0, current version 0.0.0)

My understanding is that @rpath, which seems to be a feature added in 10.5, means this dylib can be relocated.

comment:22 Changed 3 years ago by thomie

Resolution: Noneinvalid
Status: newclosed

I'm closing this, since we don't ship RPMs anymore:

commit 22690c9900068b121863dc359b8c7699b453e70d:

Author: Ian Lynagh <>
Date:   Sun Jun 9 18:56:58 2013 +0100

    Remove ghc.spec
    It doesn't look like it would work now, and doesn't really belong in the
    GHC tree anyway.

ydewit: please open a new ticket if you want to investigate relocatable installs on non-windows platforms.

Note: See TracTickets for help on using tickets.