On Mon, Mar 31, 2003 at 03:45:26PM +0100, Simon Marlow wrote:
> > 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).
Sure: gcc -print-libgcc-file-name is one way.
> Anyway, I just tried this and it results in an HSbase_cbits.o
> which *exports* __umoddi3, which inevitably leads to problems when
> linking.
Oh, ugh. You can undefine them with the linker (ld --exclude-symbols),
but that has the same problem with having to know when to do it and
exactly which symbols you need to undefine. (Although I suppose you could
do it for all symbols defined in libgcc.a)
> 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).
I assume this is because it is passing in the crt0.o, libc, etc...
Yes, current libc is very, very bloated.
-nostdlib gets rid of them, and you can re-add libgcc.a with either
-lgcc or -Wl,-lgcc. But this takes us back to having __umoddi3, etc.
exported.
Oh, hmm: --retain-symbols-file would let you collect all the symbols
you know you want to export from the input files of HSbase_cbits.o:
nm --defined-only foo.o bar.o | awk '{ print $3 }' | sort -u > syms;
gcc -o HSbase_cbits.o foo.o bar.o -Wl,-r -Wl,-x -lgcc -nostdlib
-Wl,--retain-symbols-file=syms
Seems to actually work (though I cheated slightly by deleting a blank
line in the file), with file size of 17379 vs 13735 for the ld -r, no
libgcc link.
> Any ideas?
A couple above, but they're messy. How do you feel about adding text
munging and temporary files to the build? Asking the gcc maintainers
might give some useful tips, but I think they're most likely to say
"What are you doing that for? Just use shared libraries instead of
.o." Which would work for _most_ things as the gcc invocation will not
export the libgcc symbols. I assume you want to avoid this, in
the hopes of working on systems without shared libraries, right?
--
Aaron Denney
-><-
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
