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