simplifying building ON on an OpenSolaris system

Most of my code lives in the OS/Net consolidation of OpenSolaris (also known as ON). That's true for a lot of other OpenSolaris developers as well, since the majority of the kernel, drivers, and core system software all lives in that consolidation. (Desktop software like Gnome, X, and other pieces of the operating system live in different consolidations.)

It only makes sense to be able to compile the software I primarily work on using my OpenSolaris systems rather than relying on an SXCE build machine. A few folks, primarily Ed and Sherry had assembled early instructions last year. The early instructions required copying some bits from SXCE systems, and installing extra packages. But, since then all of the required packages have been made available in IPS form, and some new requirements have cropped up. I updated the webpage that was put together from Ed's instructions, but the list of packages to install had grown to a fairly large number -- 28 at current count. Rather than forcing people to cut and paste the entire list, I created an IPS package which contains all the dependencies required. That package integrated into OpenSolaris build 111a, now available at the standard development build repository. Once you're running 111a (and have added the extra repository to be able to add a few unfortunately non-redistributable packages), you can pkg install osnet. The package is fully specified as pkg:/developer/opensolaris/osnet.

I'll keep updating developer/opensolaris/osnet with new additions and changes, and any special instructions will be maintained on Indiana's building ON page, which was the subject of an ON heads-up, and is linked to from every place that I could think of, including the Indiana project, the ON community, and a few other spots. But I'll link again here for emphasis, since it will be the best place to get up-to-date instructions for a while:

Next up, I'm working on getting ON to spit out an IPS repo from the binaries it generates... more news on that here and in the ON community as it develops.


This is great to hear. I had previously muddled my way through a more manual process on snv108.

However, there seems to be problems for sparc a t he moment (haven't tried x86).

# pkg install osnet
Creating Plan -pkg: install failed (inventory exception):
No matching package could be found for the following FMRIs in any of the catalogs for the current publishers:

# uname -srvp
SunOS 5.11 snv_111a sparc

# pkg info entire
Name: entire
Summary: entire incorporation
State: Installed
Version: 0.5.11
Build Release: 5.11
Branch: 0.111
Packaging Date: Sat Apr 18 20:02:25 2009
Size: 0.00 B
FMRI: pkg:/entire@0.5.11,5.11-0.111:20090418T200225Z

# pkg publisher
PUBLISHER TYPE STATUS URI (preferred) origin online

Posted by Mike Gerdts on April 24, 2009 at 06:51 AM PDT #

@Mike: You need to be hooked up to the extras repo. There are some non-redistributable packages that are required still, unfortunately (wbem, for the most part, and motif for those who want to run filemerge).

Sorry about that.

Posted by Liane Praza on April 24, 2009 at 06:59 AM PDT #

That got me a little further. Then I realized that python uses https_proxy and ignores http_proxy for https URL's (bug 8432 opened). Now I see...

# pkg install osnet
Creating Plan \\
pkg: 'pkg:/SUNWtss@0.3.1,5.11-0.111:20090418T195314Z' supports the following architectures: i386
Image architecture is defined as: sparc

As I recall from doing this by hand there are a few other packages in the standard instructions that are not appropriate for sparc.

Posted by Mike Gerdts on April 24, 2009 at 08:21 AM PDT #

I filed, and will fix . I don't see any other packages after a quick search, but will test and take care of them as well as any new requirements I find then.

Posted by Liane Praza on April 24, 2009 at 11:10 AM PDT #

Great Artical. Everything worked but my build keeps failing. Any ideas?
uname -srvp
SunOS 5.11 snv_111a i386

isainfo -v
64-bit amd64 applications
tscp ahf cx16 sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov
amd_sysc cx8 tsc fpu
32-bit i386 applications
tscp ahf cx16 sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov
amd_sysc cx8 tsc fpu

amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

/usr/sbin/dtrace -G -32 -C -xlazyload -s ../port/threads/plockstat.d -o pics/plockstat.o pics/alloc.o pics/assfail.o pics/cancel.o pics/door_calls.o pics/pthr_attr.o pics/pthr_barrier.o pics/pthr_cond.o pics/pthr_mutex.o pics/pthr_rwlock.o pics/pthread.o pics/rwlock.o pics/scalls.o pics/sema.o pics/sigaction.o pics/spawn.o pics/synch.o pics/tdb_agent.o pics/thr.o pics/thread_interface.o pics/tls.o pics/tsd.o
dtrace: failed to compile script ../port/threads/plockstat.d: "/usr/lib/dtrace/mpi.d", line 70: failed to resolve type genunix`kthread_t \* for identifier curthread: Module and program data models do not match
\*\*\* Error code 1
dmake: Warning: Target `' not remade because of errors
Current working directory /export/home/ajay/SunStudioProjects/OpenSolarisSource1/onnv-gate/usr/src/lib/libc/i386
\*\*\* Error code 1
The following command caused the error:
cd i386; pwd; VERSION='snv_112' dmake

Posted by Ajay Desai on April 26, 2009 at 02:06 AM PDT #

Hi Liane,

I have a question, but it's not specific to building, but a common result of a build is a BFU archive, and the script is part of the ON build tools, so it's kinda relevant ;)

When I attempt to do a BFU of an archive off-SWAN, it's unfortunately not Blindingly fast - mainly since it hangs waiting to access greenline.eng, which can take ages for the timeout to occur if connected to the internet.

Is there any way around this without having to have either a source pointer or be on SWAN, I ask since many people outside of ON, but wanting to use a BFU archive would see this.



Posted by Dar on April 26, 2009 at 06:57 PM PDT #

@Mike: My sparc build is now running successfully after applying the fix for bug 8434. It should be available in the next respin of 2009.05. We're also getting a new extra repo pushed which has sparc versions of the required wbem packages.

@Ajay: Interesting. I haven't seen that failure, but if you haven't already done so, I'd try running a full clobber nightly (don't use the -i option in your environment file), and compiling again. Based on a quick read of the dtrace source, the error seems surprising. If a clobber doesn't resolve things, the best place to bring the conversation is probably

@Dar: Folks have talked about cleaning up the old cruft in bfu (most attempts to contact other systems are cruft leftover from s10 development), but most of that work has been deferred. I'm sure contributions to the bfu script would be welcome in the ON community, but my personal goal is to spend time making ON upgrades via pkg image-update trivial instead.

Posted by Liane Praza on April 28, 2009 at 06:54 AM PDT #

Post a Comment:
Comments are closed for this entry.

Liane Praza


« March 2015