I ended up make my own sysroot using tar on a minimal OI installation with gcc-10 installed.
Now I have a working cross compiler, even for C++. The key is also include /usr/gcc/10/include and /usr/gcc/10/lib in the tarball. But I don't think I could cross compile Pale Moon for OI from Linux at all. I think I still have to mess with distribution constructor. ---- On Mon, 18 Jan 2021 05:04:59 +0700 Joshua M. Clulow via openindiana-discuss <[email protected]> wrote ---- > On Sun, 17 Jan 2021 at 05:24, Peter Tribble <[email protected]> wrote: > > On Sun, Jan 17, 2021 at 11:15 AM Hung Nguyen Gia via openindiana-discuss < > > [email protected]> wrote: > > > I wanted to use your sysroot here to build a cross compiler for OI from > > > Linux: > > > > > > https://github.com/illumos/sysroot > > > > > > But it seemed you didn't include the C++ part. I couldn't find them. > > > There > > > is no C++ headers, e.g: cmath, iostream,... nor the C++ standard library > > > itself. > > Those are supplied by the toolchain, in our case usually gcc. And you > > would > > normally > > need to ensure that the versions in the sysroot are compatible (for > > whatever definition of > > compatible you're interested in) with the toolchain you're using. > > Right. The official illumos sysroot contains, as much as possible, > only things that are delivered directly from illumos-gate. A small > exception is made for libssp and libgcc_s, after an extensive survey > was undertaken to determine if compatible versions of those libraries > were available in basically all shipping distributions. As described > in the release notes, the copies of these libraries included within > the archive are stubs: they contain no executable code, and would not > actually _work_ if you attempted to use them on an illumos system. > They're just for cross-compilation. > > Unlike libgcc_s and libssp, there aren't sufficiently strong backwards > compatibility guarantees made about any of the C++ runtimes, or > OpenSSL, or many other commonly used components. On that basis, > they're not good candidates for an illumos sysroot. > > You could, on the other hand, select a specific distribution (and > presumably a specific version) to create a different sort of sysroot. > That sysroot archive could then include anything that was guaranteed > to be available within the distribution; a process of selection that > would depend a lot on the policies of that specific distribution and > on your goals. > > > > This sysroot is also a bit old, too. > > A sysroot can be used for a variety of uses. This one is targetted at > > building software on > > a current host that will still run correctly on an older system. > > More specifically than that, it was built almost exclusively at the > time with Rust in mind. The Rust project uses this sysroot archive > within a Linux docker container to cross-compile the Rust toolchain > (including Cargo, etc) for illumos. Selecting the specific version > here was a balance between the widest possible audience (thus, the > oldest contents) and the inclusion of the getrandom(2) public API. > More details on our choice are in the release notes: > > https://github.com/illumos/sysroot/releases/tag/20181213-de6af22ae73b-v1 > > We will likely at some point select a new version of the gate to > create a new sysroot. This will probably not happen until we need to > use a new interface of some kind that was added some time after > December 2018. When we get there, it will likely _still_ seem to be > an old version -- the 20181213 sysroot was, after all, created in > April 2020. > > If we were to create a new sysroot in April 2021, it may well be from > gate bits towards the end of 2019 or very early 2020. Any newer and > it is unlikely to result in binaries that can be used on, as much as > possible, all supported distribution releases. You can see from the > release schedule at OmniOS that some of their LTS releases are > supported for a long time, and we want the sysroot to produce binaries > that can be used there: > > https://omniosce.org/schedule > > The current LTS release is r151030, which was released in May 2019 and > will be supported until May 2022. That makes it unlikely that the > released sysroot would advance past May 2019 until 2022, unless we > could find a way around the problem. > > > Generally I would expect anyone using a sysroot to have a pretty specific > > target in mind. > > It's not that hard to create, either simply copying an existing system > > that > > has the bits you > > want, or using packaging - pkg has the image-create functionality designed > > for exactly > > this purpose. > > Yes, you could definitely use "pkg image-create" to install any set of > OpenIndiana packages into a directory tree. This is, as it happens, > basically what the Distribution Constructor does today to create the > install media. The OmniOS folks also use this approach to build cloud > images in their Kayak tools. > > You could also use the tools we included in the "illumos/sysroot" > repository, with minor configuration or modification, to make your own > sysroot from any built copy of illumos. > > > Cheers. > > -- > Joshua M. Clulow > http://blog.sysmgr.org > > _______________________________________________ > openindiana-discuss mailing list > [email protected] > https://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
