RE: build of GHCi 5.04.3 fails to work (libgcc.a)

> > > 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.
> 
> So my question is: why aren't HSBase_cbits.o, etc., _statically_
> linked with libgcc?  Then you wouldn't have to worry at all about
> this, right?

I don't know how to do that!

HSbase_cbits.o is linked by invoking ld directly, as:
   
  ld -r -x foo.o bar.o ... -o HSbase_cbits.o

so we'd have to do something like

  ld -r -x foo.o bar.o ... -o HSbase_cbits.o \
    -L/usr/lib/gcc-lib/... -lgcc

which means knowing where libgcc.a lives (possible to figure it out, I
suppose).  Anyway, I just tried this and it results in an HSbase_cbits.o
which *exports* __umoddi3, which inevitably leads to problems when
linking.

Alternatively, to avoid the portability problems, we could try

  gcc -o HSbase_cbits.o foo.o bar.o -Wl,-r -Wl,-x

but that doesn't seem to work here (results in a 6M HSbase_cbits.o).

Any ideas?

Cheers,
        Simon