Bug #14254


usr/src/tools is confused about what native means

Added by Andrew Stormont 6 months ago. Updated 6 months ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


If we ever want to support cross-compiling we must first sort out the mess around what exactly a "native" build is. The "native" label should be analogous to the "build" system used in the standard GNU host/build/target naming, where it indicates that the code is being compiled using a native compiler against native headers and libraries.

This means that anything that is compiled against the system headers in illumos-gate, such as usr/src/head, usr/src/uts, should be considered foreign. In other words, we should not expect it to run, and we should absolutely not depend on it being able to run. The same goes for anything linked against libraries in proto.

Right now usr/src/tools is getting this horribly wrong. Part of the problem is that NATIVECC happens to point to the rather unfortunately named BUILDCC, which is the compiler we use to produce target binaries. The first step to sorting this out is probably to introduce separate build and target compiler variables.

Actions #1

Updated by Joshua M. Clulow 6 months ago

Might be worth looking at what's been done in some of the prior ARM porting work, which was cross-built:

Actions #2

Updated by Andrew Stormont 6 months ago

My goal is to be able to build illumos-gate on a Mac, which makes things more complicated. Some of the problems with usr/src/tools and usr/src/cmd/sgs are:

- __sun is defined when building the native stuff.
- "-nostdinc" is passed along with "-I$(SRC)/uts/common", which is wrong even when building on illumos.
- A similar thing is done with "-nostdlib" for libraries.

Those aren't too tricky to solve. I was able to get a version of cw and smatch built without much trouble by using a modified version of Igor Pashev's sunmake which I will publish at some point in the near future.

The ctf stuff is where it gets more complicated, because that depends on libelf (our modified version) which is not built until later in the build process. That could be solved by bringing it into usr/src/tools.

Actions #3

Updated by Joshua M. Clulow 6 months ago

I'm not sure as a project that we really want to support building the OS on foreign systems. That's a pretty big change, and would definitely constrain the way we can evolve it in the future; in the limit you could imagine we end up needing to build a tools copy of quite a lot of the base system.

Before spending too much effort on it I would encourage you to write an IPD describing your goals and constraints and get buy in from other folks!

Actions #4

Updated by Andrew Stormont 6 months ago

I think it's worth fixing the native stuff regardless. I would also like a version of illumos LD which can run on a Mac for cross-compilation. binutils does the job, but it would be nice to use the same linker as a normal illumos system.

Actions #5

Updated by Joshua M. Clulow 6 months ago

Andrew Stormont wrote in #note-4:

I think it's worth fixing the native stuff regardless.

Definitely, whatever improvements for native/target hygiene in the build when running on illumos systems are very welcome.

I just wanted to call out that beyond that, we'll need a broader discussion about goals and planning.

Actions #6

Updated by Rich Lowe 6 months ago

is the cross-built tools stuff we did. At the time this was done, this allowed you to cross-build (at least) all the common kernel code, and what machdep code there was, from an i386 system successfully.


Also available in: Atom PDF