> My Blastwave experience goes back to Solaris 7/8, so maybe it wasn't a 100% fair statement. Around the time when the Sun Freeware collection came out, I had to choose between 2 distribution sets. Even if I had installed the SFW version of ncurses, I would still have to install the Blastwave release of ncurses just to satisfy another dependency from another Blastwave package. I had to choose from 2 separate code branches that would never cross over. I decided to stick with stuff that was released from Sun. > > If there was other code that I didn't need, I just compiled it on my own and built my own SVR4 packages. To this day, I still compile my own stuff if I think it's going to be easier to deal with.
Sounds like you go back years and years. We are compiling things here ALL the time. Night and day, on just about everything from Solaris 8 ( baseline, no patches, no kidding ) all the way up to snv_115 on various architectures[1], and testing. Testing. Then test some more. Then one more test. Then release into a testable user accessible stack. That is how we released GNU bash, version 4.0.24(1). Sorry, we have not tested it on a sun4m machine because, let's face it, that would be almost insane. But we have a quad CPU Sparc 20 in the rack[2] just in case of an emergency. :-) So if you were to go to look at something like a GCC compile and testsuite report from Blastwave.org Inc. you would see pretty much the latest and most up to date bits for a GNU runtime or dev environment : http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html Go and get pkgutil : www.blastwave.org/howto.html Go and install GNU gettext, gsed, libiconv and you will see that they are all 64-bit ready and all up to date. But not everything is of course, and that is an uphill battle that never ends. Nothing is perfect and this is not a perfect process. However, I will say that rigid dependecies are not the cure for cancer or even the boogey man people like to make them out to be. I recently took an old build of MPlayer as well as a stack of libs all built on Solaris 8 and stuffed them into /tmp on a OpenSolaris Live CD and it all worked. None of the paths are correct and nothing is in the correct place. Yet it works. See http://www.blastwave.org/dclarke/blog/?q=node/145 or Feel free to comment liberally at http://wiki.blastwave.org/forum/index.php Dennis [1] including the obscure : $ uname -a SunOS aequitas 5.11 snv_115 i86pc i386 i86pc $ isalist -v i486 i386 i86 $ isainfo i386 $ psrinfo -pv The physical processor has 1 virtual processor (0) x86 (CentaurHauls 6A9 family 6 model 10 step 9 clock 1200 MHz) VIA Esther processor 1200MHz $ psrinfo -v Status of virtual processor 0 as of: 06/07/2009 17:26:53 on-line since 06/07/2009 08:24:11. The i386 processor operates at 1200 MHz, and has an i387 compatible floating point processor. [2] actually it sits on the floor switched off. If I need it, ever, I can deal with it then. $ uname -a SunOS fossil 5.8 Generic_117350-56 sun4m sparc SUNW,SPARCstation-20 $ fpversion A SPARC-based CPU is available. CPU's clock rate appears to be approximately 66.5 MHz. Kernel says CPU's clock rate is 66.0 MHz. Kernel says main memory's clock rate is 50.0 MHz. Sun-4 floating-point controller version 0 found. A Fujitsu/Ross RT620 hyperSPARC chip is available. FPU's frequency appears to be approximately 66.7 MHz.
