Project

General

Profile

Actions

Bug #14254

open

usr/src/tools is confused about what native means

Added by Andrew Stormont 14 days ago. Updated 14 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Hard
Tags:
Gerrit CR:

Description

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 14 days ago

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

https://github.com/twistmyarm/illumos-gate/commits/armv7a

Actions #2

Updated by Andrew Stormont 14 days 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 14 days 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 14 days 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 14 days 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

Also available in: Atom PDF