This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: Gcc-3.0.4 make fails


James Fitzsimons wrote:
> 
> Hi Kai and list,
> Thanks for your help so far Kai!

 You are welcome...

> >> ../../gcc-3.0.4/gcc/builtin-attrs.def:126: (Each undeclared identifier is
> >> reported only once
> >> ../../gcc-3.0.4/gcc/builtin-attrs.def:126: for each function it appears in.)
> >> ../../gcc-3.0.4/gcc/builtin-attrs.def:127: `ATTR_FORMAT_PRINTF_2_3'
> >> undeclared (first use in this function)
> >
> > A quick check showed that these things should have been defined earlier with
> > some macros, but they failed... The first error will tell the reason and
> > putting it here will surely help us to help you...

 Oops, this 3.0.4 was here, but you mentioning earlier the CVS-sources put me look
at the gcc-3.1 snapshots sources and this file was there. When now trying to look
at it in the gcc-3.0.4 sources, it wasn't there, neither with the original 3.0.x
sources I had on CDs...

 So, what on earth your 'gcc-3.0.4' sources now are ?

 The 'ftp://sources.redhat.com/pub/gcc/releases' and its mirrors have the official
FSF 'gcc-3.0.4' sources, while the '/pub/gcc/snapshots/<date>' there have the gcc-3.1
sources, currently in the 'prerelease' phase.  These have been enough for me, the
'CVS' approach seems to be for those with quick and no-cost lines to the net and
working hard with GCC, ie. for the official 'GCC-developers' needing to get their
fixes to the GCC sources and to receive the fixes from the others as soon as
possible...

> > BTW, what are the possibilities for producing a OS X targeted cross-toolkit ?
> Possibility of Apple producing it, or me, or someone else?

 Anyone who would be interested, but not (yet) having an access to a OS X - machine,
ie. for 'the Gates/Allen-approach' (they produced a Basic-interpreter for a system
they hadn't yet seen, the 'Altair-8080', and that was the beginning of their company.)
Apple with its 'Mac OS' has been a 'closed system', the only way to produce executables
for it, has been to purchase an Apple-machine and to use it...  I fear that the same
thing is still true with the OS X, although all kind of rumors now claim the 'Darwin'
being one part of 'Open Source'.  I remember Apple with its 'look-and-feel' cases against
DRI ('Gem') and MS, was boycotted by FSF...

 Choosing an unstandard object format, not 'ELF', chosen by SVR4s, Linuxes, current
BSDs, BeOS etc., sounds weird and puts one to wonder the Apple reasons.  Perhaps the
FSF boycott should be refreshed...

 If the GNU binutils don't support the 'Mach O' format, perhaps the sources for the
assembler and linker used on the native 'Darwin' could however be somewhere....
 
> > (The GNU binutils don't seem to know about the 'Mach O' format mentioned in
> > the GCC-config headers for Darwin...)
>
> Some stuff is available from the apple open source cvs server. I don't know
> about binutils though. I managed to get the GNU binutils-2.11.2 to build and
> install with no errors on my Mac OSX system.

 You mean the very big 'native GCC for OS/X' packages ?  With a modem connection it
is insane to download those and then just see that the needed stuff is not there...

 The 'binutils-20020312' snaphots I have now as the newest, don't have any support
for 'darwin' as the target, the 'gas/configure' however mentions it as one possible
'host'... If you managed to build GNU binutils-2.11.2 for OS X target, what patches
and from where were needed ?  Perhaps you mean some other target (m68k-coff ?) on
the OS X host...

 Ok, cross-compilers can surely be produced for MacOS/PPC and OS X, but the assembling
and linking must be done in the Apple systems, so 'cross-compiling' for them isn't as
convenient it could be, if the cross-assembler and cross-linker would exist for them.
And their headers & libs would be freely available.  The MacOS headers and libraries
used to be available, but the OS X case is more than unclear...

 So it seems to be a stupid thought that Apple would like developers to produce apps
FOR their OS X. Instead they seem to wish this happening only ON their OS X, and they
want to sell their machines to everyone, to the end-users or the developers.  HP-UX
seems to be another 'closed system', the GNU binutils cannot be built for it...

> /Users/james/projects/source/gcc-3.0.4/gcc/builtin-attrs.def:94: missing
> right curly brace, found `_0'

 If you try the original gcc-3.0.4 sources, it may happen that you will succeed and
don't meet other problems, than just the normal ones related to the 'm68k-coff/elf'
targets. Or you may succeed with the gcc-3.1 prerelease.  But your sources now are
something really weird and it may be tough to get any support for them.  Please stay
with the known sources like the official GCC releases and the official GCC development
snapshots.  If you use the CVS-stuff you are expected to be one of the GCC-developers
and knowing what you are doing and not needing much help on it...

 But if you choose to try the gcc-3.1 prerelease and get this same problem...

 Here is the pointed part from 'gcc/builtin-attrs.def' in my gcc-3.1 sources :

-------------------------------- clip ----------------------------------------
/* Construct a tree for a format attribute.  */
#define DEF_FORMAT_ATTRIBUTE(TYPE, VALUES)				 \
  DEF_ATTR_TREE_LIST (CONCAT4 (ATTR_,TYPE,_,VALUES), ATTR_NULL,		 \
		      CONCAT2 (ATTR_,TYPE), CONCAT2 (ATTR_LIST_,VALUES)) \
  DEF_ATTR_TREE_LIST (CONCAT4 (ATTR_FORMAT_,TYPE,_,VALUES), ATTR_FORMAT, \
		      CONCAT4 (ATTR_,TYPE,_,VALUES), ATTR_NULL)
DEF_FORMAT_ATTRIBUTE(PRINTF,1_0)	<--- line 94
DEF_FORMAT_ATTRIBUTE(PRINTF,1_2)
DEF_FORMAT_ATTRIBUTE(PRINTF,2_0)
-------------------------------- clip ----------------------------------------

 The '#define DEF_FORMAT_ATTRIBUTE(TYPE, VALUES)' depends on the earlier
'DEF_ATTR_TREE_LIST', 'CONCAT4' and 'CONCAT2' macros, so this looks a little
complicated to try to solve by looking at them... The easy way is to let the
'cpp' do the work and to use the '-save-temps' option when compiling :

-------------------------------- clip ----------------------------------------
-save-temps
	Store the usual "temporary" intermediate files permanently; place them
	in the current directory and name them based on the source file.  Thus,
	compiling foo.c with -c -save-temps would produce files foo.i and foo.s,
	as well as foo.o.
-------------------------------- clip ----------------------------------------

 A 'make CFLAGS="-O -save-temps"' or something should do this, and a 'c-common.i'
file (I remember the 'c-common.c' to '#include' the 'builtin-attrs.def') should
appear into the $build/gcc directory. And there these macros should be expanded
and the preprocessed line to replace the 'DEF_FORMAT_ATTRIBUTE(PRINTF,1_0)' should
be seen and if any 'missing right curly brace' being there...

Cheers, Kai

PS. The Apple-site:

   http://www.opensource.apple.com/projects/darwin/1.2/projects.html

seems to need a username & password for download !!!!  I really have got these
for the 'Apple Developer'-stuff, but didn't work here, sigh...

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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