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 <[EMAIL PROTECTED]> wrote: > 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 > > james.swaine: > > 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 > the > > 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 <[EMAIL PROTECTED]> > 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 > > <[EMAIL PROTECTED]> 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 > 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:[EMAIL PROTECTED] > > > > References > > > > Visible links > > 1. mailto:[EMAIL PROTECTED] > > 2. mailto:[EMAIL PROTECTED] > > 3. mailto:[EMAIL PROTECTED] >
_______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
