> > > 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
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
