1

the last week I have been trying to set-up a compiler which can compile to netbsd with mips architecture.

I cannot find anything on the internet how to do this. All documents refer to compiling the kernel to the architecture but not programs.

How can this be so hard....

host is netbsd amd64 machine

  • Cross compiling from what host, exactly? – Kuba hasn't forgotten Monica Jun 02 '14 at 00:11
  • amd64 machine running *what*? I mean, come on, don't make it so hard. – Kuba hasn't forgotten Monica Jun 02 '14 at 00:15
  • netbsd, i`m sorry I am just very frustrated that something which seems so simple is not documented well at all –  Jun 02 '14 at 00:16
  • Where did you get the toolchain? Did you compile it yourself (if so, how did you configure it)? What does the makefile for your "hello world" program look like? – Michael Jun 02 '14 at 05:36
  • Did you build the NetBSD/mips image yourself for your target machine on your NetBSD/amd64 development host? – Greg A. Woods Jun 05 '14 at 18:21
  • I have build a netbsd image to mips64el from amd64. I do have mips64el--netbsd-gcc in the tooldir however running generates huge errors. –  Jun 06 '14 at 15:54
  • You don't necessarily want to run the compiler yourself by hand -- you would need to get all the options corret. Try this instead after first doing a cross-build of NetBSD to make sure your TOOLDIR and DESTDIR are up to date. Write a wee program, or steal one (e.g. mkdir ~/mytest && cp /usr/src/cat/* $HOME/mytest && cd $HOME/mytest). Put TOOLDIR in your path (after putting it in your environment): PATH=$TOOLDIR:$PATH And then finally try cross-compiling your test program: nbmake-mips64el dependall If that doesn't work then POST EVERYTHING to show what you did and didn't do! – Greg A. Woods Jun 18 '14 at 20:13

2 Answers2

1

Set the compiler appropriately. Point it at the version of gcc in your TOOLDIR. In this case, something like mips--netbsd-gcc. Definitely make sure TOOLDIR is on your path, so the driver can find the proper assembler, proper loader, and proper libraries.

Take a look at the Makefile in any of src/bin/* as an example, and read through the system mk include files referenced (in src/share/mk)

Eric Schnoebelen
  • 76
  • 2
  • 1
    And this is the problem. what does setting the compiler mean? I have mips64el--netbsd-gcc in my tooldir but if I use it I get massive errors. likely because I dont have set the compiler correctly... looking at /usr/src/share/mk doesn`t give me any clues it seems. I have no idea what it all means. I have never worked with compilers on this level –  Jun 02 '14 at 00:28
  • I think this assumes the OP has already cross-compiled NetBSD/mips for the target machine from the dev host, but it is not clear that was done. – Greg A. Woods Jun 05 '14 at 18:18
0

Generally speaking, the goal is to have a working cross-compiler and a filesystem root for the target, all installed on your development machine. The target root is needed since you need all sorts of libraries to build userland applications. Those libraries need to be compiled for the target, not for the host.

Assuming you build everything from source, it goes as follows:

  1. Choose a prefix for the toolchain (say /opt/mips) and another prefix for the root filesystem of the target (say /opt/target). All of those are on your development machine, not on the target!

  2. Configure, build and install the cross-compiler for your target. This goes into the toolchain prefix.

  3. Configure, build and install the kernel for your target, into the target root prefix. This should install the necessary kernel development headers needed later. If you can install such headers without compiling the kernel, more power to you, of course.

  4. Configure, build and install the C library (say glibc) for your target, into the target root.

  5. Configure, build and install whatever other libraries your userland application needs - into the target root.

  6. Finally, configure, build and install the userland application. Once installed into the target root, you can copy it over to the target into the same prefix (say /opt/target as suggested before).

    Generally to install into a different prefix - one that overlaps stuff on your build host (like /usr) - you'd need to do some tricks to fool make install into seeing the target prefix instead of your own. A simple approach would be to have a chroot environment on your build host, where you can bind-mount the prefix (say /usr) read-only, with a writable (mount_union) overlay on top of it.

When you build stuff for the target, you need to pass proper arguments to configure, of course.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • That'll work, but it's definitely not the much easier NetBSD way to do things, especially as the OP is already running NetBSD on the dev host (though that doesn't really matter as NetBSD can be cross-compiled from most any good POSIX-compatible host, and so thus its cross-compiler toolchain and libraries can also be cross-compiled from almost any good POSIX-compatible host). – Greg A. Woods Jun 05 '14 at 18:17
  • So, what is this much easier NetBSD way to do things? How are you going to do it without having the target root? Of course the target root can be obtained from the target system itself (duh), but what else am I missing? – Kuba hasn't forgotten Monica Jun 05 '14 at 20:59
  • Since the NetBSD source tree can be built on any POSIX host this means it necessarily can also build a cross compiler and all of the necessary libraries for the target system (and install all of those libraries and their associated header files in a directory where the toolchain can use them). Once that's done then all you need to do is put the resulting $TOOLDIR in your path and use the make wrapper script from there (nbmake-$MACHINE) to cross-compile any other code (using BSD Makefiles, of course). That is, after all, exactly how the rest of the OS is cross-compiled. – Greg A. Woods Jun 05 '14 at 22:21