James Swaine wrote:
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 attemp
On 2008 Nov 14, at 13:09, James Swaine wrote:
/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/jswai
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
On Fri, 2008-11-14 at 12:09 -0600, James Swaine wrote:
> we tried that, but then we got this error:
> ghc: missing -B 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 di
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 th
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 (
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
>
This is a straight forward ld.so path problem, by the sounds of it.
Are you sure you're setting ld environment search paths correctly?
-- Don
james.swaine:
>that didn't fix the problem - i still get the same error message. the
>configure script help should be updated though to show that
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
<[EMAIL PROTECTED]>wrote:
> 2008/11/13 James Swaine <[EMAIL PROTECTED
2008/11/13 James Swaine <[EMAIL PROTECTED]>:
> 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
it says:
libedit.so.0 => not found
libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x0039e220)
libutil.so.1 => /lib64/libutil.so.1 (0x0039dba0)
libdl.so.2 => /lib64/libdl.so.2 (0x0039cfc0)
libm.so.6 => /lib64/libm.so.6 (0x0039cf80)
libgmp.so.3 =>
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
(t
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 environ
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
14 matches
Mail list logo
