This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: problem with gcc3.2 compiler
- From: Bart Veer <bartv at ecoscentric dot com>
- To: jifl at eCosCentric dot com
- Cc: ottawaguy81 at yahoo dot com, ecos-devel at sources dot redhat dot com,ecos-patches at ecos dot sourceware dot org
- Date: Fri, 24 Oct 2003 19:24:12 +0100 (BST)
- Subject: Re: problem with gcc3.2 compiler
- References: <20031024062418.85743.qmail@web13010.mail.yahoo.com> <m3u15z114j.fsf@miso.calivar.com> <20031024120441.9DAB97886B@deneb.localdomain> <1066997432.24207.20.camel@hermes> <20031024144911.1C322EC1C0@delenn.bartv.net> <3F99697D.7020406@eCosCentric.com>
>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
Jifl> Bart Veer wrote:
>> Question for Mark - do you happen to know if -finit-priority
>> was already the default by gcc 2.95.2? Alternatively, does
>> anybody still have a vintage compiler of that era around and
>> can run some tests? I think 2.95.2 is the oldest version of the
>> compiler we care about. If -finit-priority was already ignored
>> by then we could just extend the pkgconf/rules.mak hack to
>> remove it completely. That would be preferable to trying to
>> figuring out the compiler version at configure-time or
>> build-time.
Jifl> As it happens, I have 2.95 sources sitting here, and it does
Jifl> indeed look like -finit-priority was the default in 2.95
Jifl> (and presumably 2.95.2).
Jifl> So it looks like your hunch was right, and we should just
Jifl> drop it in rules.mak.
Jifl> The attached patch will do that, and I thought we may as
Jifl> well divvy up the CFLAGS and CXXFLAGS now anyway for
Jifl> symmetry; and remove -fvtable-gc which is at best broken,
Jifl> and at worst deprecated and to be removed from GCC
Jifl> (unfortunately).
Agreed. Doing this stuff at build-time is an expense we should try to
avoid as long as possible, hopefully it will not become necessary
until we have a new makefile generator with a single top-level
makefile.
Even then I would probably have implemented it rather differently from
your COMPILERVER approach, using a single invocation of a Tcl script
rather than four $(shell ) invocations. Probably with a cache file
somewhere as well. But we can worry about that when it becomes
unavoidable.
Bart