shared libgcc build support
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
More information about the Gcc-patches