RE: Newbie question on building cross-compiler for Vr4100 targets

[David Korn <dkorn at pixelpower dot com>]

>-----Original Message-----
>From: James Jenkins [mailto:jjenkins@iddaerospacecorp.com]
>Sent: 08 November 2001 18:48


>Hi -
>
>I am having trouble making a cross-compiler for the NEC vr4121 

  I'm afraid my help will be limited to a couple of general points, since
I never even heard of the thing before!

>	- Got the following files for the cross-compiler and 
>unpacked them under 
>directory c:\cross-compile:
>		       ftp://ftp.gnu.org/gnu/gcc/gcc-2.95.1.tar.gz
>		       
>ftp://ftp.gnu.org/gnu/binutils/binutils-2.9.1.tar.gz
>		       
>ftp://sources.redhat.com/pub/newlib/newlib-1.8.1.tar.gz
>
>	   so have directory structure as follows after unpacking:
>		c:\cross_compile\newlib-1.9.0
>		c:\cross_compile\gcc-3.0.2
>		c:\cross_compile\binutils-2.11.2	

  Yeah?  Shome mishtake shurely? :)


>	Note that "-target=mips64vr4100elf" would not work for 
>some reason.  The 
>config.sub has mips64vr4100el in it instead of mips64vr4100elf.

  'el' and 'elf' are two separate things.  'el' means for little-endian
operating mode rather than big-endian, that's pretty much standard for all
cpus that can run in either mode.  'elf' means the object file format as
you expect, but needs to be separated from the cpu spec by a dash.  So the
target you probably wanted is "-target=mips64vr4100el-elf", unless you
didn't really mean little endian, in which case change the 'el' to 'eb' (or
it may be the default, in which case you could just omit it altogether, but
I don't know whether or not it is).

>then attempted to redirect newlib directrory to a directory 
>called newlib 
>under gcc-3.0.2 directory:
>	ln -s newlib c:/cross_compile/newlib-1.9.0/newlib
>
>That did not seem to work as a directory link under cygwin.

  Yeah, I can see that not working.  Although many cygwin commands will
kinda-run-ish with dos paths like that, you can't really expect all of the
unix apps to be ok with it.  Use unix-style paths for all cygwin commands
except the mount command!  You'll want to get familiar with that mount
command too: when building under cygwin you generally want to build in a
separate directory to where the source is, and reference the source via
a cygwin mount point in textmode.  Your next move should probably be:

$ mkdir /cross-src
$ mount -t c:\\cross_compile\\ /cross-src
      [note: unix command lines, escape your backslashes!]
$ cd /cross-src/gcc-3.0.2/
$ ln -s newlib /cross-src/newlib-1.9.0/newlib
$ ln -s libgloss /cross-src/newlib-1.9.0/libgloss
   [note: I don't use newlib myself but all the standard build docs that
          I've seen say you need this second link as well]
$ cd ~
$ mkdir build
$ cd build
$ /gcc-src/configure [...options...]

....except of course that it seems that gcc doesn't support your target!

>Thus it would seem that binutils and GDB both support mips64vr4100el 
>targets.  In addition, at
> 
>   http://www.redhat.com/docs/manuals/gnupro/GNUPro-Toolkit-99r1 [snip]
>the indications are that GCC does support Vr4100 targets.
>
>  I suppose it is a possibility the GNUPro toolkit supports the Vr4100
> targets but the freely available GNU tools do not. 

  This is by far the most likely possibility.  GNUPro is a value added
version of the free tools, RedHat have added things like extra targets and
support for interrupt routines for some targets and generally made it more
useful for embedded work, and they haven't donated all the improvements to
the FSF/GNU's version of the source (the GPL obliges us all to give out our
source code freely, but nobody is obliged by it to make their work into
patches suitable for submission to the gcc main source repository).

>I am also a bit confused since it seems to me that the GCC 
>build would need to know where the binutils build is located.

  Absolutely correct it does.  That's why binutils and gcc both have the
same default setting for --prefix; and if you want to override that, you
must supply the same setting to both binutils and gcc when you build them.
The gcc cross-compiler makefile expects to find the target tools in 
$prefix/$bin/$target-$toolname and they're also installed into 
$prefix/$target/bin/$toolname.  Furthermore, some of these paths get coded
into the executables in such a way that means it can be difficult to get
them to work if you move the installation to a different directory (you can
work round it by providing lots of flags, path and environment settings, 
but once you've got the hang of building a cross-compiler it becomes easier
to just rebuild with new --prefix settings).

  Anyway, your next move is probably to look into getting hold of the
gnupro toolkit, or start searching the various mailing list archives at
sources.redhat.com and gcc.gnu.org to see if you can find patches that
you could merge into the free source yourself for that target.

      DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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