[OpenIndiana-discuss] Could you update your sysroot, jclulow?

[Hung Nguyen Gia]

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 <openindiana-discuss at openindiana.org> wrote ----

 > On Sun, 17 Jan 2021 at 05:24, Peter Tribble <peter.tribble at gmail.com> wrote: 
 > > On Sun, Jan 17, 2021 at 11:15 AM Hung Nguyen Gia via openindiana-discuss < 
 > > openindiana-discuss at openindiana.org> 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 
 > openindiana-discuss at openindiana.org 
 > https://openindiana.org/mailman/listinfo/openindiana-discuss 
 >