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 wrote:

...

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

...

linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but

james.swaine: the 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

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 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.

...

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@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)

james.swaine: -

...

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@galois.com

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 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

...

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

On Fri, 2008-11-14 at 12:09 -0600, James Swaine wrote:

we tried that, but then we got this error:

ghc: missing -B<dir> option

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).

The ghc -B option is not related to linking. The ghc program is actually a shell script that calls the real ghc program with the -B flag to tell ghc where to look for it's libraries and other config files. For example my /usr/local/bin/ghc-6.8.2 is: #!/bin/sh GHCBIN=/usr/local/lib64/ghc-6.8.2/ghc-6.8.2 TOPDIROPT=-B/usr/local/lib64/ghc-6.8.2 exec $GHCBIN $TOPDIROPT ${1+"$@"}

but this option isn't listed in the ghc flag reference.

It's internal.

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.

I think what that did was add an extra error that you hit before this one. On fixing that error you got back to this original error. So it looks to me like your bootstrapping ghc is messed up. If it's not getting the -B option then perhaps the ghc shell script is messed up. Does your bootstrapping compiler work at all for other things? Duncan

there wouldn't be any issue with using the 6.8.x binaries. we'd ideally like to be working with the latest source tree (we're planning on tweaking the source, specifically in the parallel and concurrency libraries). but the distro we're using to compile the sources is the 6.10 for 64-bit Linux (the one that expects the libedit.so.0 as opposed to libedit.so.2). so maybe we should drop back to 6.8 and use the Red Hat-specific distro? -james On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart wrote:

...

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

...

linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but

james.swaine: the 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

that didn't fix the problem - i still get the same error message. the configure script help should be updated though to show that these two options are available. thanks, james On Fri, Nov 14, 2008 at 11:28 AM, Judah Jacobson wrote:

2008/11/13 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.

I'm not sure whether this will fix your problem, but if you want to build ghc using a libedit in a nonstandard location, there's an easier solution than setting all of those environmental variables: just configure ghc with (for example)

./configure --with-editline-includes=/opt/local/include --with-editline-libraries=/opt/local/lib

-Judah