On Thu, May 03, 2007 at 12:14:20AM -0400, Brian Gupta wrote: > I've been reading the materials you linked me to regarding procedures. One > thing that didn't seem clear, was that it wasn't specified what hardware > architecture to compile it on. x86, x64, or Sparc.
Both x86 and sparc. For most applications, Solaris doesn't distinguish between x86 and x64. Notably, unlike many (most?) Linux distros, we don't have separate builds for the two -- you just build for x86, and you can build a 64-bit version of your app if there are good reasons to. > Also, it seems that I need to be running a relatively recent version of > Solaris Express. That would be highly encouraged. Solaris 8 is definitely too old. I've no idea how successful people have been using virtualized environments to build SFW. I would expect that to work, though. As long as you can get it to build on x86, someone else -- here at Sun, or someone else -- can help you on the sparc side. Sun doesn't have any public build machines, but maybe Dennis from Blastwave or Steve from sunfreeware might, I'm not sure. Just be sure that that you don't do anything funny with the makefiles that would make a difference when run on multiple architectures. I don't recall having to do anything like that when I went through the exercise back in December. But you should definitely be running as recent a copy of Nevada as you can get your hands on. I don't recall whether SFW follows the "n-2" rule (builds have to be done on nothing older than two builds prior to the target integration build), but you might as well act as if it did. > An example should illuminate what I am trying to ask. Say, I had a project > to include applicationxyz version 3.4.1 in SOlaris11/nv. Say there were 3 > security patches and 10 bug fixes included in two maint. releases. The new > application version is 3.4.5. As a maintainer would I upgrade the > OpenSolaris package to version 3.4.5 of the package, or would I manually > create a 3.4.1_patched1? Generally you'd just upgrade the package to 3.4.5. Most components in SFW get their bugs fixed by upgrading to the newest release. Sometimes, though, the latest release will have bugs you feel you can't release with, so there's a mechanism whereby you can apply the patch as part of the build process. This generally has to be justified to the c-team. This may also happen if you can't upgrade to the latest version for some reason -- like tons of people have imported the interfaces it exported, and the newest version breaks binary compatibility (cf net-snmp). Danek _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
