This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Success (and a few questions: egcs-2.92.72 19981206, m68k-elf


I finally got around to trying the new m68k-elf support in egcs 
(snapshot 19981206, the core & g++ files only).  I built it as a cross 
compiler, under HPUX-10.20 egcs-1.1a.  It appears to build correctly, 
although I ran across a few oddities that I want to ask about:

1.  One of the new files apparently needed for elf support is t-m68kelf.  
This is almost identical to t-m68kbare, as shown by the following diff:

*** t-m68kbare  Thu Dec 10 11:36:11 1998
--- t-m68kelf   Thu Dec 10 13:04:47 1998
***************
*** 16,26 ****
        cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c
  
  # Testing - JAB, 1998-12-10
! #MULTILIB_OPTIONS = m68000/m68020/m5200/mcpu32 m68881/msoft-float
  MULTILIB_OPTIONS = m68020/mcpu32 m68881/msoft-float
  MULTILIB_DIRNAMES =
! MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 mcpu32=m68332 
m68020=mc68020 m68020=m68040 m68020=m68060
! MULTILIB_EXCEPTIONS = m68000/msoft-float m5200/m68881 
m5200/msoft-float mcpu32/m68881 mcpu32/msoft-float
  
  LIBGCC = stmp-multilib
  INSTALL_LIBGCC = install-multilib
--- 16,31 ----
        cat $(srcdir)/config/m68k/fpgnulib.c >> xfgnulib.c
  
  # Testing - JAB, 1998-12-10
! #MULTILIB_OPTIONS = m68000/m68020/m5200 m68881/msoft-float
  MULTILIB_OPTIONS = m68020/mcpu32 m68881/msoft-float
  MULTILIB_DIRNAMES =
! MULTILIB_MATCHES = m68000=mc68000 m68000=m68302 m68000=m68332 
m68020=mc68020 m68020=m68040
! MULTILIB_EXCEPTIONS = *m5200/*m68881 *m5200/*msoft-float
  
  LIBGCC = stmp-multilib
  INSTALL_LIBGCC = install-multilib
+ 
+ # from ../t-svr4
+ EXTRA_PARTS=crtbegin.o crtend.o
+ # no pic for now
+ #CRTSTUFF_T_CFLAGS=-fpic

(Note that I edited MULTILIB_OPTIONS; look at the commented-out ones for 
the original lines).  The differences seem to be mainly in the absence 
of mcpu32 in t-m68kelf, as well as a couple of other differences that I 
don't understand.  Should t-m68kelf look more like t-m68kbare?  Does 
there need to be a t-m68kelf?  If so, why isn't there a t-m68kcoff, 
etc.?

2.  As shown above, I edited MULTILIB_OPTIONS in an attempt to keep from 
building multilibs I don't need (changing t-m68kbare didn't do anything, 
which I kind of suspected).  All I want is support for m68020 and 
mcpu32.  Did I do it right? Is there an easier way?  I don't really like 
modifying files in the source tree.

3.  It didn't like the host that config.guess came up with.  With 
egcs-1.1a, it was hppa1.1-hp-hpux10.20; now it spits out 
hppa2.0-hp-hpux10.20.  I know host identification on HPUX has been a 
recent topic, so I just mention it for completeness.

4.  When building, it appeared to build the libraries correctly 
(although it always looks to me like it's running around in circles).  
But when I went to install (with: make install LANGUAGES="c c++"), it 
looked like it did the library builds all over again; it certainly did 
more work than I expected it to.  I think I saw the same thing with 
egcs-1.1a.  I'm using newlib, with links in the egcs source tree over to 
the newlib source.  Is this expected?

5.  The install died with "No rule to make c++" or something similar 
(sorry, I didn't write down the full message; I can give more details 
the next time I do a build). I don't really have any plans to use c++, 
but I thought it'd be fun to have around.  I remember this happening 
with egcs-1.1a also.

6.  I looked around to see what files had been updated/replaced.  Since 
I installed the cross compiler in the same directory that the native 
egcs is in, I wanted to make sure they coexist peacefully.  One updated 
file that surprised me was libiberty in {installdir}/lib.  Is this used 
by a native compiler?  If so, why was it updated?  What exactly is it, 
anyway?

7.  How does one test a cross compiler?  Do the test suites actually try 
to run the compiled code (which would obviously fail in this case), or 
do they just look at the compiler output?  We're close to needing to use 
this "for real", and I want to make sure I've validated it as much as 
possible.

Thanks for all the hard work everyone has put into this.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


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