This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
On Tue, Jul 11, 2000 at 12:41:40AM -0700, Richard Henderson wrote:
> On Mon, Jul 10, 2000 at 06:10:55PM -0700, Zack Weinberg wrote:
> > I ask again, why do we need libtool? What supported platform cannot
> > be handled by teaching the Makefile the magic switches to pass to the
> > compiler and linker?
>
> We don't, necessarily. But make in general doesn't have complex
> macro expansion. Which implies we'll have to have some sort of
> script-y thing. Either that or leave the entire library target
> in the target makefile fragment.
I don't see the need for complex macro expansion, either. You write
SO_OBJS = a.os b.os c.os d.os
libfoo$(soext): $(SO_OBJS)
$(CC) $(CFLAGS) $(SHLIB_LDFLAGS) $(SO_OBJS) -o $@
$(MAYBE_POSTPROCESS_SHLIB) $@
.SUFFIXES: .os
.c.os:
$(CC) $(CFLAGS) $(CPPFLAGS) $(PIC_CFLAGS) $< -o $@
and have soext, PIC_CFLAGS, MAYBE_POSTPROCESS_SHLIB, and SHLIB_LDFLAGS
set by either configure or the target fragments. And that is enough
for every shared library system I've ever seen except Linux/a.out,
which we don't care about anyway.
I might also point out that this is libgcc we're talking about. Which
means we know that CC is gcc, and we already have the mklibgcc script
should we need to do anything contorted.
[We do have to worry about libgcc1.c - I'd be in favor of eliminating
it for GCC 3.0. And the .asm files some systems put in libgcc will
have to be ifdefed up for PIC, but that's not hard.]
zw