This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problem with gcc3.2 compiler


On Fri, 2003-10-24 at 08:29, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > On Fri, 2003-10-24 at 06:07, Jani Monoses wrote:
> > 
> >>>That's really too bad - we can't take it out globally because that
> >>>could possibly break things for folks using older compilers and we
> >>>may have troubles using newer ones..  
> >>>
> >>>The proverbial rock and hard place :-(
> >>
> >>Would a cdl option for the compiler version used be too ugly? 
> > 
> > 
> > We don't have very good handling of options like this.  Also, sadly,
> > the compiler options are somewhat spread around rather than being
> > localized (e.g. in the architecture HAL only).  Currently there
> > are 96! occurrences of -finit-priority, so making any change in this
> > area will be non-trivial.
> > 
> > We recently made some changes in the makefile rule template.  Perhaps
> > we could just make a similar one for this case.
> 
> As Bart was only just recently saying, the only real alternative is to 
> have a step that at the beginning of the build runs $(COMMAND_PREFIX)gcc 
> --version and parses the output, and adjusts the makefile options 
> accordingly. Icky.
> 
> Something along these lines:
> 
> I just tested this mini-makefile which works fine:
> COMMAND_PREFIX=/opt/ecos/gnutools/arm-elf/bin/arm-elf-
> 
> COMPILERVER := $(shell $(COMMAND_PREFIX)gcc --version | head -1 | cut -f3 
> -d " ")
> COMPILERMAJOR := $(shell echo $(COMPILERVER) | cut -f1 -d .)
> COMPILERMINOR := $(shell echo $(COMPILERVER) | cut -f2 -d .)
> COMPILERPATCHLEVEL := $(shell echo $(COMPILERVER) | cut -f3 -d .)
> 
> all:
> 	echo $(COMPILERMAJOR) $(COMPILERMINOR) $(COMPILERPATCHLEVEL)
> 
> If y'all (Hi Bart) is happy that this is the way to do it, I'll put the 
> appropriate stuff in pkgconf/rules.mak
> 

My concern with this is that you need to run at least 6 additional 
processes for every makefile invocation.  Sounds like a lot of overhead.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]