ghc binary on virtualized solaris

[Christian Maeder]

I've created a new binary release with a ranlib path /usr/ccs/bin/
http://www.dfki.de/sks/hets/pc-solaris/versions/ghc-6.8.2-i386-unknown-solaris2.tar.bz2
(46826578 Bytes)
and a fixed bug
http://hackage.haskell.org/trac/ghc/ticket/1980

I have not tested it, though.

I'm not sure, if it should replace
http://www.haskell.org/ghc/dist/6.8.2/maeder/ghc-6.8.2-i386-unknown-solaris2.tar.bz2

The other paths to haddock, alex, happy and hugs in setup-config files
are also somehow disturbing for a distribution.

Cheers Christian

Christian Maeder wrote:
> the entry in Makefile-vars is irrelevant for Solaris. it should be:
> 
> RANLIB      = :
> 
> I did not know that the paths like for ranlib are so deeply burned into
> each library package (by cabal). Indeed I have:
> 
> -bash-3.1$ type -all ranlib
> ranlib is /usr/local/bin/ranlib
> ranlib is /usr/ccs/bin/ranlib
> 
> I could try to rebuild my binary dist with a proper PATH.
> 
> HTH Christian
> 
> Ryan Wisnesky wrote:
>> Hi Christian,
>>
>> I'm trying to install ghc onto a Joyent accelerator, which is an
>> instance of virtualized open solaris.  I've noticed that even if I set
>> my RANLIB variable in the Makefile-vars to be its actual location (in
>> this case, /usr/ccs/bin/ranlib), there are a bunch of files, like
>> libraries/process/dist/setup-config, where the LocalBuildInfo haskell
>> structs have an entry for ranlib that looks like "ranlib",
>> ConfiguredProgram { ... programLocation = FoundOnSystem{locationPath =
>> /usr/local/bin/ranlib ... }.  When I make install haskell, during
>> installation of the libraries, the installPackage haskell program is
>> eventually called and it will fail because it tries to invoke a
>> non-existent ranlib.  These ranlib locations aren't set by the configure
>> script, because they are present even before that script is run.
>>
>> Unfortunately I can't just link my ranlib to /usr/local/bin because I
>> have a virtualized machine...
>>
>> Do you have any thoughts?  Any help would be greatly appreciated.
>>
>> Regards,
>> Ryan Wisnesky