more libedit.so.0 issues

[Don Stewart]

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]dons at 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 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:dons at galois.com