The system is a xen virtual machine:
Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212
AuthenticAMD GNU/Linux
With GHC version 6.8.2, ghci gives the error:
$ ghci
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
ghc-6.8.2: internal error: R_X86_64_32S relocation out
James Swaine wrote:
Aha! That *seems* to have fixed the problem with libedit.so.0. Now ghc
is complaining about something else:
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: cann
Bit Connor wrote:
The system is a xen virtual machine:
Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212
AuthenticAMD GNU/Linux
With GHC version 6.8.2, ghci gives the error:
$ ghci
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
ghc-6.8.2: internal error: R_X86_6
Hello
I was wondering if there is a bug in GHC 6.10.1 regarding number precision.
As an example, in GHCi with:
> 3.0 * 0.2
I get:
0.6001
Although:
> 2.0 * 0.2
0.4
I have GHC 6.10.1 on Mac OS X 10.5.
Is this a known bug or should I report it?
Best regards
Zé Pedro
Hi,
Floating point numbers are just inaccurate, so the results you see aren't too
surprisingly.
Interestingly enough, using Hugs, I get the right answer in both cases - so its
possible it's a bug, but unlikely.
If you do want exact floating point manipulation then use rational numbers
instead
Hello José,
Friday, November 14, 2008, 5:32:52 PM, you wrote:
> 0.6001
computers store floating-point numbers in binary form, and it's
imposiible to represent 3/5 in binary form exactly for the same
reasons as impossibility to represent 1/3 exactly in decimal form
(sorry for awkward
On Fri, Nov 14, 2008 at 5:36 AM, Simon Marlow <[EMAIL PROTECTED]> wrote:
> Compiling and running executables should work fine, only GHCi is affected by
> the above bug. Could you try -v when linking and see what stage is hanging?
Here is an example with a standard cabal Setup.lhs file. It outputs
On Fri, 2008-11-14 at 14:43 +, Mitchell, Neil wrote:
> Hi,
>
> Floating point numbers are just inaccurate, so the results you see
> aren't too surprisingly.
>
> Interestingly enough, using Hugs, I get the right answer in both cases
> - so its possible it's a bug, but unlikely.
Hugs probably
I cannot get GHC to work on a fresh ubuntu hardy machine:
On installing using the package manager I get an error when
running ghci:
"R_X86_64_32S relocation out of range:" - similar to
http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is
FreeBSD specific.
I decided to install the bi
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
Rahul Kapoor wrote:
I cannot get GHC to work on a fresh ubuntu hardy machine:
On installing using the package manager I get an error when
running ghci:
"R_X86_64_32S relocation out of range:" - similar to
http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is
FreeBSD specific.
I dec
> Are you running under Xen by any chance?
Yes I am. This is on a SliceHost instance.
Is there a tentative release date for 6.10.2?
Rahul
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/gl
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 =>
Rahul Kapoor wrote:
Are you running under Xen by any chance?
Yes I am. This is on a SliceHost instance.
Is there a tentative release date for 6.10.2?
About 3 months after the 6.10.1 release was the tentative plan.
Is anyone with access to a Xen instance able to work on this bug? It would
n
> Is anyone with access to a Xen instance able to work on this bug?
I can setup an login for a GHC developer on my Zen instance, if that
would help.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/l
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
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
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
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
>
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 (
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
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
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 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
24 matches
Mail list logo