egcs 1.1b *-rtems

joel@OARcorp.com joel@OARcorp.com
Thu Oct 15 06:29:00 GMT 1998


On Wed, 14 Oct 1998, Jeffrey A Law wrote:

> 
>   In message < Pine.LNX.3.96.981014074505.15716E-100000@oar3remote.oarcorp.com >y
> ou write:
>   > This did override INSTALL_ASSERT_H in the generated Makefile.  But doing
>   > this does not prevent the assert.h part of the stanza stmp-fixinc in
>   > Makefile.in from being executed.  It prevents the stanza install-assert-h
>   > from running. It is possible that the path I conditionalized in
>   > Makefile.in should not be there and the install-assert-h stanza alone
>   > should do the install of assert.h.  This would also fix the problem.  
> You're absolutely correct.  Sorry for being dense :-)
> 
>   > My impression was that something was inconsistent in the way the
>   > INSTALL_ASSERT_H feature was installed.
> Yes.

Good.  It was a confusing conclusion to reach.

Another side issue is that newlib's and gcc's assert.h files are pretty
different.  This is what tripped me into looking at this.  You cannot mix
them.  I don't know if this is a problem or just a fact.

>   > I felt uncomfortable removing the assert.h code from stmp-fixinc since
>   > this impacted every target.  If you are more comfortable doing that, I am
>   > happy with that solution.  If that is the intent, it is the more correct
>   > solution.
> I'll hold off on this one :-)   If someone else wants to walk through the
> install targets and verify that the right thing will happen I'll apply their
> patch :-)

With newlib and glibc, a possible better fix long term would be a
mechanism to have those libraries install their header files before the
compiler is built.  This would eliminate the need for inhibit_libc in many
cross cases -- at least most embedded and XXX Linux -> YYY Linux.

--joel




More information about the Gcc mailing list