> On Mon, Mar 31, 2003 at 11:43:46AM +0100, Simon Marlow wrote:
> > The boxes I have access to all have __umoddi3 in libc
>
> That's rather odd; AIUI it really shouldn't be in libc. It's part of
> how gcc implements 64 bit division, and pollutes the
> namespace for other
> compilers (including other gcc versions) that want to link
> against libc.
> A gcc compiled libc should have those routines, but they shouldn't
> be exported.
>
> Of course, I just checked and three of the systems I have access to do
> export it from libc, a redhat 7 (glibc 2.2.5), a redhat 8,
> (glibc 2.2.93)
> and a debian stable "woody" (also glibc 2.2.5), while two
> other systems,
> debian unstable "sid" (glibc 2.3.1), and a "homebrew" with glibc 2.3.2
> don't export it. I've only checked for this bug on the
> debian unstable
> system though, which is also using a prerelease gcc-3.2.3
>
> I can try building it with gcc 2.95.4 if that would help get another
> data point, but it will take a while to do.
>
> > libgcc, presumably). Perhaps it wouldn't do any harm to always add
> > these symbols to the Linker's symbol table (on Linux, at least).
>
> It shouldn't, but I think the relevant test is probably "am I
> compiling
> with gcc on a platform that isn't 64-bit."
Ok, I've done that. I'd be interested to know if GHCi on the HEAD now
works for people with this problem.
> If you call the linker
> through gcc, I would expect it to automatically add libgcc.a when
> necessary, unless told not to. I assume you have your reasons
> for linking the way you do, however.
Yes, the problem is our dynamic linker which can only get access to (a)
symbols it knows about from objects it loaded and (b) symbols from other
dynamic libraries. These libgcc symbols are statically linked, so they
need to be listed explicitly in the linker's symbol table. This is kind
of an ugly wart, but there doesn't seem to be an easy way around it.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
