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

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
-><-