shared libgcc build support

Richard Henderson rth@cygnus.com
Fri Oct 6 13:24:00 GMT 2000


On Fri, Oct 06, 2000 at 02:17:47PM -0400, David Edelsohn wrote:
> 	1) The shared object filename is assumed to have a file extension
> of ".so" and assumed to be created directly from the PIC object files.

I should have remembered the extension thing.  That's easily
fixed by providing a SHLIB_EXT variable to mklibgcc.

> AIX wants a shared object (customarily with file extension ".o") which is
> archived into a normal library.
[...]
> 	2) The shared object needs to be linked with different system
> libraries depending on multilib information (libpthread in this case).
> SHLIB_LIBS does not appear to provide the flexibility and there are no
> Makefile variables to test for the multilib commandline arguments.

I guess the SHLIB_LIBS thing doesn't work so great.  

How about SHLIB_LINK is taken as the entire command.  We
replace @libgcc_objs@ with the list of objects, which allows
you to make SHLIB_LINK consist of more than one command.

I already do substitution on @libgcc_base_name@, which does
contain multilib information, e.g. libgcc_s_pthread, so you
could do something like

  `case @libgcc_base_name@ in *pthread*) echo -lpthread ;; esac`

I can't think of any particularly convenient form in which
you could receive this information; this seems just about
as good as any other.

If you want me to gen up a patch to implement this, say
so and I'll send it to you and let you experiment.

Hmm.  Didn't Geoff tell me that AIX puts both 32-bit and 64-bit
objects into the same archive file?  Is this something you'll
be wanting to do, or just be content to leave libgcc_s_ppc64.a
separate?


r~


More information about the Gcc-patches mailing list