we tried it exactly as you describe below (twice). after it failed the
first time, we deleted everything, redownloaded, and tried again. but i
know the process works - i've done it successfully on two other machines
(though this is the only red hat machine i've ever attempted this on).
are there any flags i need to pass to enable verbose logging, or does the
build process always log everything? also - where do these log files go,
and where should i post them?
thanks for you help.
-james
On Fri, Nov 14, 2008 at 12:13 PM, Don Stewart
It sounds like your tree is mucked up somehow.
The process should be quite simple:
* download the ghc binary release for your platform (e.g. x86_64/linux) * set LD_LIBRARY_PATH to include the directory of any non-standard dynamic libraries.
And you are done.
Can you try this?
Since this is working for all the other x86_64 users, I suspect you may have just missed a step in the process (perhaps setting the wrong environment variable?).
As Simon Marlow said, if your source build is failing, you should post the full logs online of the build process, so we can see which libraries or tools are missing from your development environment, such that the build fails.
-- Don
we tried that, but then we got this error:
grep: packages: No such file or directory make -C libraries boot make[1]: Entering directory `/home/jswaine/ghc/ghc-6.10.1/
libraries' mkdir bootstrapping mkdir: cannot create directory `bootstrapping': File exists make[1]: [cabal-bin] Error 1 (ignored) /home/jswaine/ghc/ghc-6.10.1/ghc/ghc -Wall -DCABAL_VERSION=1,6,0,1 -odir /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -hidir /home/jswaine/ghc/ghc-6.10.1/libraries/bootstrapping -i/home/jswaine/ghc/ghc-6.10.1/libraries/Cabal -i/home/jswaine/ghc/ghc-6.10.1/libraries/filepath -i/home/jswaine/ghc/ghc-6.10.1/libraries/hpc --make cabal-bin -o cabal-bin ghc: missing -B<dir> option make[1]: *** [cabal-bin] Error 1 make[1]: Leaving directory `/home/jswaine/ghc/ghc-6.10.1/libraries' make: *** [stage1] Error 2
which still looks to me like it's somewhat related to linking (the assumption was that -B is used for this sort of thing - linking to libraries in unusual directories). but this option isn't listed in
ghc flag reference. that was when we decided to just install the editline package so it would be where it normally is (/usr/local/lib), but that got us back to the original error message. ugh.
-james
On Fri, Nov 14, 2008 at 12:02 PM, Don Stewart <[1]dons@galois.com> wrote:
Is your LD_LIBRARY_PATH environment variable exported, and set to include the path to the lib dir that libedit lives in?
e.g. $ echo $LD_LIBRARY_PATH /home/dons/lib
Allows the system linker to find things in my home dir.
james.swaine: > it says: > > libedit.so.0 => not found > libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x00000039e2200000) > libutil.so.1 => /lib64/libutil.so.1 (0x00000039dba00000) > libdl.so.2 => /lib64/libdl.so.2 (0x00000039cfc00000) > libm.so.6 => /lib64/libm.so.6 (0x00000039cf800000) > libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00000039d5800000) > librt.so.1 => /lib64/librt.so.1 (0x00000039d3800000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039d0000000) > libc.so.6 => /lib64/libc.so.6 (0x00000039cf400000) > /lib64/ld-linux-x86-64.so.2 (0x00000039cec00000) > > i noticed that my PATH variable doesn't include /usr/local/lib, do you > think this might be the problem? > -james > > On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart <[1][2]dons@galois.com> wrote: > > james.swaine: > > We've had unbelievable problems getting past this ridiculous > 'unable to > > load object file or shared library libedit.so.0' error when > attempting to > > build the 6.10.1 source tree. We initially just built editline in > a user > > directory and attempted to manipulate environment variables to help > the > > linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - > but this > > did no good. > > > > We then just installed the editline package so it's available > globally and > > the libraries (specifically libedit.so.0) live in /usr/local/lib, > so it > > should be found with no problem. Not so for ghc - same error. > We're > > running this on Red Hat. > > What does ldd say? > > It should say something like this (on Arch Linux): > > $ ldd /usr/lib/ghc-6.10.0/ghc > linux-vdso.so.1 => (0x00007fffb09fe000) > libedit.so.0 => /usr/lib/libedit.so.0 (0x00007f6aa8479000) > libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f6aa820f000) > libutil.so.1 => /lib/libutil.so.1 (0x00007f6aa800c000) > libdl.so.2 => /lib/libdl.so.2 (0x00007f6aa7e08000) > libm.so.6 => /lib/libm.so.6 (0x00007f6aa7b85000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f6aa7943000) > librt.so.1 => /lib/librt.so.1 (0x00007f6aa773b000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6aa7520000) > libc.so.6 => /lib/libc.so.6 (0x00007f6aa71cc000) > /lib/ld-linux-x86-64.so.2 (0x00007f6aa86a7000) > > For example, let's you know if the system linker can see
james.swaine: the libedit
(and > the other > C libraries GHC uses) > > I'm part of a research group at Northwestern University
that
is > exploring > > the use of ghc and associated libraries for some
upcoming
projects. > It's > > a shame that this is so difficult to even
compile/install,
and > nobody > > seems to be able to figure out what's wrong. > > Do you have the option of using a distro package? Has GHC
6.10.x
been > packaged for > your distro yet? Do you have the option of using GHC 6.8.x
for
now, or > is there some > feature in 6.10.x you expect to depend on? > -- Don > > References > > Visible links > 1. mailto:[3]dons@galois.com
References
Visible links 1. mailto:dons@galois.com 2. mailto:dons@galois.com 3. mailto:dons@galois.com