This is a reply to anybody who is interesting in trying to get NetBSD
cross compilation support up and running, I am planning on typing up a
full document on the subject but I figured that this should work for now
as there were a few questions about it, I hope it helps...

Tyrel


Well, as it turns out I'm in the same boat as you and I just got over a
few annoying problems along the way.

1.   The best source of docuementation is going to be the netbsd cross
compile document located at www.netbsd.org/Documentation/cross - make
sure you get the 'D' and not 'd'

2.   The most current source code is available via cvs through the
anoncvs.netbsd.org server.  See the www.netbsd.org/Documentation/current

for information about setting up cvs and starting to track
netbsd-current as this branch is the super state of flux.

3.   If you are going to build a netbsd-current you will need to have
the latest version of the tools such as the config program( which gave
me problems ) what I did is simply d/l a snapshot( a compiled netbsd
dist in the release(7) format) and I installed this onto my host system
which will be preforming all the cross-builds.  This means that I've go
the updated config program but you don't have to do it this way, I just
did it so I would know for sure that I had all the latest tools and
such.

4.   Getting cross compile toolchain support:

        a.  using the netbsd package system will give you access to a
cross-compile enviroment.  However first of all you need to d/l and
install the pkgsrc.tar file( from:
ftp.netbsd.org/pub/NetBSD/packages/pkgsrc.tar.gz )  It should be
installed under the /usr directory.  Next within the
/usr/pkgsrc/cross/shel-netbsdcoff direcorty you can type make ; make
install to have the package and dependancies d/l and installed into the
/usr/pkg/cross/bin directory which you will need to add to your path
file.  This will give you the ability to get a cross-compile enviroement

up and running, however, this will produce binaries in coff format( i'm
not sure if it is ECOFF or just coff or what)

       b.  you can build your own tool change if you want to get elf
binary support but this is a bit harder and it is what I'm currently
working on, I'm going to post another short question regarding the
potential benifits of this and how/why to get it working, Andrew as it
up and working, however, he ran into a few issues which you might want
to keep in mind, the relevant messages are in the list archives.  See
gcc.gnu.org for more details about building cross compilers yourself.
Also as we speak I'm waiting for a compile to finish to see if NetBSD
will do most of the work for me to get an elf binary toolchain up and
running, what I did was change a few variables in the
/usr/pkg/cross/shel-netbsdcoff/Makefile.  Everywhere it said coff
I changed to elf and I'm hoping that might work but I might also be just

plain off the right page.

Now you should have most of the right ideas in place and if you follow
the netbsd cross-build doc you should be able to bang it out.  Also as
just a little note the build-script that they talk about in the
cross-build doc can be found in the /usr/src/sys/arch/sh3 direcoty.  You

want the one which says 'el' at the end of it becasue the dreamcast is a

little endian machine.

Tyrel





Yeah, I ran into this problem to.  I'm not sure what the cause is but I
belive
it is realated to the some of the developement tools - similar to the
config
problem.  What I did to get everything working was to d/l and install a
snapshot for my current arch.  I'm running an i386 system and it was
really
easy to d/l a binary snapshot and install it.  Point your ftp to
ftp.netbsd.org/pub/NetBSD/arch/i386/snapshot/20010206/binary/ for the
latest
set of binaries( as of this email )

1.  In the kernel direcorty you should find the kernel which matches you

system, most likely netbsd.GENERIC.gz
     download and install this kernel BEFORE you install the binary sets

because new system calls may have been
     and things could get dirty and such.

2.   Download the sets from the sets directory.  BACKUP your current
/etc
directory because the etc.tgz here will
      cause a few problem as it will revert your settings like rc.conf
and
such.... which might, if you don't up date the
      rc.conf it installs will drop you into single user mode with a
read-only
dirve mounted... that sucked when I did it ;-)

3.   With the kernel you just d/l installed and running go ahead and
install
the binaries with permissions presrved.
      Also these sets will expand into the current directory if you
don't tell
them to go to the root dir.

      e.g.

      tar -zxpf <binary set name> -C /

4.   Repeat 3 for all the binary distrobution sets and you should have
painlessly updated you system to a current
      status.  Reboot for good mesure and try it out.

Also, I don't know if you were thinking what I was thinking when the
config
program didn't work but I copied over the makefile from the
sys/arch/sh3/conf
directory and I made it my Makefile.dreamcast.  This is wrong and it
might
also be causing your problem if that is what you did.

I hope this helps, I think just going all out and updating all the
system
binaries is the easy thing to do because all you need to do is expand a
few
tar archives and you don't need to dig around makefiles looking for the
logic
which is failing.

Tyrel






Yeah, your right about the coff vs. elf trade off, however, if you want
to use the program created by marcus, ip_slave, which will allow you to
push and run binaries over ethernet you will need to setup up elf... I
haven't gotten that far yet.  However, I was able to get my all of the
system binaries built.  However, there werer four bumps along the road.

1.    After following the steps in the cross-build document and building

all the libs and include files and such I ran into a problem when
attempting the <build-script obj build> setup.  My problem was pretty
simple once I figured out what was going on.  When doing a <build-script

dependall> within the src/lib direcorty it(for some reason unknown to
me) dosen't build the object files within the obj.dreamcast direcorty(It

dosen't even create this dir).  The problem was that when I came back
around with the <build-script obj build> command it tries to go into the

src/lib directory and preform another dependall, however just before the

dependall it does a cleandir to make sure all the stale files have been
removed.  This causes a problem on the second time around because what
has happend is that the first time around all of the objects are build
inside the dir instead of within the obj.dreamcast directory.  When make

comes around to do the cleandir it is hardcoded(I had to check out the
source to confirm) to automaticlly cd to first the obj direcorty if
present and then if not cd to any dir with obj.<arch> as the name and
build.  Well to say the less my stale files were not being removed
because it was trying to remove them from the obj.dreamcast dir which
had just been created!  So, to keep things simpile I had a copy of the
clean cvs which I burned to cd and I just did an rm -fr lib and the
copied over a fresh one from the cd and it cleared up the problem.

2.    For some reason unknown to myself when it tries to build the
libexec/kadmind this fails becasue it cannont locate the
dlopen/dlsym/dlclose calls which allow a program to control the linking
of dynamic libs.  I'm pretty sure I didn't need most of the stuff so I
just commented out the offending line in the makefile within the libexec

dir.

3.    There was a typo in the usr.sbin/mlxctl/cmds.c file which I
spotted, it seems that line 330 had an unessecary argument being passed
to it, I let the current-users list know about it and they fixed it
promptly, so you can get a fresh copy of it if you like or just clean it

up by hand.

4.    Durring compilation of  dependall ===> gnu/usr.bin/egcs/common it
fails informing me that there is some sort of assembler error.
"Error: Signed .word overflow: switch may be to large", I really wasn't
to exited about trying to figure this one out so I just removed the egcs

dir from the gnu/usr.bin/egcs makefile.

After these few fixes(and a few hours I was able to get it to compile
right!!! :-)

Now I'm working on figuring out the ins-and-outs of burning my own cds
with all the good IP.BIN and stuff included, which is all described at
mc.pp.se/dc but I'm having a few problems getting things to work out for

me.  But that dosen't strike me as odd at this point ;-)  I'm hopefully
going to get a document typed up on the current "state" of the dreamcast

port and how to get everything build and working right as the current
docs on the subject are somewhat lacking... Other than that I'm looking
forward to hacking around with some dreamcast device drivers and trying
to keep current on the pmap debuging that some of the guys are doing...

Also, what project ideas do you have, I'd be interested to hear about
them and if you know or have any ideas related to the solution of the
problems I've outlined I would be happy to hear them.

Thanks,
Tyrel