Re: Fix calls to malloc, realloc in prefix.c

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Sun, Feb 13, 2000 at 11:46:47PM -0500, Kaveh R. Ghazi wrote:
>  > From: Zack Weinberg <zack@wolery.cumb.org>
>  > 
>  > > gcc/cppalloc.c: defines xmalloc()/xrealloc()
>  > > 
>  > >   Looks like that's its purpose. Why not libiberty?
>  > 
>  > Because of fix-header.
>  > 
>  > fix-header is a build program (compiled with $(HOST_CC)) and it uses
>  > libcpp.a.  In general, code compiled with $(CC) cannot be linked with
>  > code compiled by $(HOST_CC).  libiberty is only compiled with $(CC),
>  > so fix-header can't use it, and therefore neither can cpplib.
>  > 
>  > This argument is somewhat absurd, because libcpp.a is compiled with $(CC),
>  > and has always been compiled thus.  Therefore, all build/host/target
>  > triples that would break if libcpp required libiberty are already broken.
>  > No one has complained, therefore this is not a problem in practice.
> 
> I'd guess that one doesn't run fixproto/fix-header automatically in a
> triple cross compile. (???)  Look at all.build vs all.internal and
> all.cross in Makefile.in.

all.cross depends on $(STMP_FIXPROTO), which triggers fix-header, unless
the x-files disable it.  all.internal depends on rest.encap which
depends on $(STMP_FIXPROTO).

>  > I'd be delighted to patch cppalloc.c out of existence.
> 
> IIRC, I think Per mentioned libcpp.a was meant at one time to be
> standalone, thus it provides xmalloc, etc.  There was some ambivalence
> about whether this was still useful.  Perhaps getting rid of it is okay?

If he said that, I never saw it.  I personally think that's more
trouble than it's worth; using libiberty would let me get rid of a
private strerror() as well as xmalloc etc, and I'd also like to use
some of the abstract-data-type code.

>  > There's a related issue: libiberty should be 3-staged.  We don't do that
>  > right now.  That's harder than just building one with $(HOST_CC) and
>  > should be addressed separately.
> 
> Yes, my patch did exactly that, it 3-staged libiberty and built both
> host/build copies similarly to how we do it for rtl.c.  The details
> are foggy but it all started when I was having ABI problems on Irix6
> when using cc for stage1 and gcc switched from o32 to n32 at stage2.
> The libiberty built at the top level was o32 ABI so it wouldn't link
> with n32 stage2.  3-staging libiberty in the gcc dir would have solved
> that but Jeff rejected it.

Do you still have this patch?  I'd like to look at it.

zw