Opened 10 years ago

Last modified 11 months ago

#284 new feature request (None)

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 Revisions:

Description (last modified by igloo)

After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:

#!/bin/sh
GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2";
TOPDIROPT="-B/usr/lib/ghc-6.2.2";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}

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

Change History (21)

comment:1 Changed 10 years ago by simonmar

  • Status changed from assigned to closed
Logged In: YES 
user_id=48280

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

comment:2 Changed 10 years ago by skaller

Logged In: YES 
user_id=5394

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
correctly
(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 10 years ago by simonmar

  • Summary changed from minor bug in rpm (x86 linux) to RPM doesn't support --prefix
Logged In: YES 
user_id=48280

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 10 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
[email protected]

comment:5 Changed 10 years ago by juhp

Logged In: YES 
user_id=139853

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 10 years ago by juhp

Logged In: YES 
user_id=139853

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 9 years ago by igloo

  • Architecture set to Unknown
  • Component changed from None to Build System
  • Description modified (diff)
  • difficulty set to Unknown
  • Milestone set to 6.6.1
  • Operating System set to Unknown
  • Owner changed from nobody to juhp
  • Status changed from assigned to new

What's the status of this?

comment:8 Changed 9 years ago by igloo

  • Test Case set to N/A

comment:9 Changed 9 years ago by simonmar

  • Priority changed from normal to low

comment:10 Changed 8 years ago by igloo

  • Milestone changed from 6.6.1 to 6.6.2
  • Priority changed from low to normal

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 8 years ago by simonmar

  • Milestone changed from 6.6.2 to 6.8

comment:12 Changed 8 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 8 years ago by simonmar

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

fix CC

comment:14 Changed 7 years ago by igloo

  • Milestone changed from 6.8 branch to _|_

comment:15 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:16 Changed 7 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:17 Changed 6 years ago by simonmar

  • Cc bos@… added
  • Type of failure set to None/Unknown

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

comment:18 Changed 11 months 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:

#!/bin/sh
GHC_HOME=$( cd $(dirname $0)/.. ; pwd )
exedir="${GHC_HOME}/lib/ghc-7.8.2/bin"
exeprog="ghc-stage2"
executablename="$exedir/$exeprog"
datadir="${GHC_HOME}/lib"
bindir="${GHC_HOME}/bin"
topdir="${GHC_HOME}"
executablename="$exedir/ghc"
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 config.mk, 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                                                                                                              
 else                                                                                                                                
 RelocatableBuild = NO                                                                                                               
 endif

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

else

# 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
endif

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 11 months ago by ydewit

  • Cc ydewit@… added

comment:20 Changed 11 months 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 11 months ago by ydewit

This is what I see with otool -L:

/t/g/l/g/array-0.5.0.0 ❯❯❯ otool -L libHSarray-0.5.0.0-ghc7.9.20140709.dylib
libHSarray-0.5.0.0-ghc7.9.20140709.dylib:
	@rpath/libHSarray-0.5.0.0-ghc7.9.20140709.dylib (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-4.7.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSinteger-gmp-0.5.1.0-ghc7.9.20140709.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSghc-prim-0.3.1.0-ghc7.9.20140709.dylib (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.

Note: See TracTickets for help on using tickets.