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

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <19981211153649.1877.qmail@hotmail.com>you write:
  > 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:
Yes.  Though I think we should probably make the multilibs for t-m68kelf
match those for t-m68kbare.   I'll check in a patch for that shortly.


  > don't understand.  Should t-m68kelf look more like t-m68kbare?
It should for multilibs.

  > Does there need to be a t-m68kelf? 
Yes.  ctors/dtors and their interactions with the C startup code are different
than for other embedded m68k ports.

  > 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.
Read the documentation.  It describes the operations of those macros in
detail.


  > 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.
It's in a state of flux right now.


  > 4.  When building, it appeared to build the libraries correctly 
  > (although it always looks to me like it's running around in circles).  
Because it's building multilibs.

  > 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?
This can happen when clocks get out of sync.  I've also seen it happen a
lot when using HP's "make" for reasons  unknown.  Use gnu-make :-)

  > 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?
They can coexist.  I've had install dirs with 10+ cross compilers living
together in the past.

libiberty can be both a host and a target library.n


  > 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.
The testsuites can talk to real hardware, though it can be difficult to get
set up.  The m68k is unfortunately one of those configurations without a
simulator, so testing is limited to either making a board work or finding a
m68k unix box you can run code on.

jeff