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