Re: Definitely Getting Closer

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Mark Palmerino wrote:
> 
> Hi Kai et. al.,
> 
> > Just look at what '-Dm68xyz' options the compiler gives to the 'cpp' there and
> > you will see that the addresses being the same is right for m68332 !!! The
> > DOS- hosted compiler under Windoze produced m68000-code, not m68332-code...
> 
> Hmmm, does this mean that if I use the right flags that I can coax 2.8.1 to
> produce "working" executables?  If so, it isn't as easy as -m68000, is it?

 I tried to say that the options given by your Windows-hosted 'gcc' to 'cpp' were
something really insane. You gave the compile log :

-------------------- clip -----------------------------------
gcc -c -b 68k -mcpu32 -Ic:\xgcc\68k\2_8_1\include hell1.c -v
Using builtin specs.
gcc version 2.8.1
 cpp -lang-c -v -Ic:\xgcc\68k\2_8_1\include -undef -D__GNUC__=2
-D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -D__unix__ -D__i386__
-D__GO32__ -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__MSDOS -Asystem(unix)
-Asystem(msdos) -Acpu(i386) -Amachine(i386) -Di386 -Asystem(unix)
-Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) -Acpu(i386)
-Amachine(i386) hell1.c C:\WINDOWS\TEMP/ccaaaaaa.i
 GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (68k, Motorola
syntax)
-------------------- clip -----------------------------------

 The compiler driver, 'gcc' was seemingly version 2.8.1 and built for
DOS/DJGPP and this couldn't find the right specs (for m68k-coff) and
so used the built-in specs for DOS/DJGPP2/i386. No '-Dm68*' defines
at all... Weren't there a 'gccm68k.exe' at all ?

 The startup, 'rm_crt0.S' was also compiled using these defines, so when
there weren't any '-D__m68332__', the code for m68000 was compiled into
the 'rm_crt0.o' and the vector code addresses were different...

 But you claimed that you could produce "working" executables under the
Unix-system, using the pre-built libs, the compiled startup, 'rm_crt0.o'
and the compiled object for your example 'hello' program. So only the
C-libraries which were compiled using gcc-2.8.1 were problematic... 

> >> I guess the next question is, how can I discover why the libraries from the
> >> windows system are successful at producing a working program while the
> >> libraries that were built under unix are not successful?
> >
> > Perhaps there really is some problem with the mcpu32-support in gcc-2.8.1,
> > just remember that it was originally disabled ! The "Windows"-libs were
> > compiled with egcs-1.1.2, not with gcc-2.8.1 although the '2.8.1' was a ghost
> > there...
> >
> >> Again, I hardly know where to begin...
> >
> > What about building gcc-2.95.3-pre4 for m68k-coff now or later ? ;-) And
> > adding the ISR-patches I sent into the sources. The 2.95.3 should serve for a
> > while...
> 
> Ok, ok (squirming with arm up behind back), I give up!  I will try to build
> a "higher" version of gcc. (I guess you don't mind my pestering to much!)
> 
> Are you really suggesting something other than 2.95.2?  Should I procure
> this thing called gcc-2.95.3-pre4?  And remember, I'm working on MachTen
> under the MacOS - I'm gonna need some hand holding...

The differences between gcc-2.95.2 and gcc-2.95.3-test4 seem to be mainly in
PowerPC and ARM support and in C++, perhaps somewhere else too, but I cannot
remember now... The bettered PowerPC-support was the reason to suggest the
gcc-2.95.3-test4... The gcc-2.95.3 hasn't yet officially appeared, but I
wouldn't expect any big changes any more.

Unfortunately the Machten patches are quite big so installing them into
gcc-2.95.2 seems to be safer... Trying to install them on 2.95.3 could
reject a lot...

Cheers, Kai



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