UNIX admin wrote: >>Are you suggesting, somebody could have ported >>SUNWspro to another >>Architecture for that little money? >> >> > >I'm suggesting that the long term gains of such an action would have >outweighed the costs by far. > >
Can you share a detailed and verifyable causal chain with us, why exactly you think, this would have been the case? I cannot follow you. >>No, POLARIS is not in the works, aha. >>It does not compile thanks a gcc-Xcomplier and >>alsmost boot into user >>land now. >> >> > >Exactly, it's in the works, not 'out and readily usable'. So the port isn't >finished. The count is still at 0. > >And there's an old US colloquialism that says "almost" only counts in horse >shoes and hand grenades. > > I'm sure, the POLARIS community appreciates any help, that might accellerate things. Here you go: http://opensolaris.org/os/community/power_pc/ If you think about that proverb: Nobody should ever begin with anything new then. > > >>Then: Remember the problems, distributors had with >>SUNWspro-built c++ >>code, when the shared C++ libs had been >>unredistributable. >> >> > >-Bstatic? >I though about this problem for a long time. The shared object libraries are >conceptually a great thing, since they can be reused by multiple applications >and are reeentrant, so that system resources such as memory can be saved. > > ??? First, did you notice the relevant changes from Solaris9 to 10? Plus: Did you read a single re-distribution_of_/usr/libC* specific message, that had been posted to this list? The work-around wasn't "-Bstatic", but instead compilation with g++ !! But the problem had been, that a small number (MANY THOUSANDS!) of _existing_ SunCC compiled binaries and libs had been affected by those unsatisfied dependencies. >But in reality, this model does not work very well, as open source software >has clearly demonstrated with a myriad of dependencies. And with the memory >being cheap nowdays, the statically linked binaries are no longer such a >burden on the system's memory resources. > > Solaris 10++ does not ship with static libs anymore, so I would have a dependency problem (yes!), when attempting to link statically (try it out if you don't believe me). One crappy workaround is to copy over Solaris9's /lib/*.a files to Solaris10++. However, I still could not statically link for 64bits then. Did you ever see a 64bit static lib even in pre-Solaris10? >Another issue is that a piece of software might rely on some very specific .so >libs that no other software would have use for -- in which case a dependency >has been created for something that *might*, or *might not* be needed by other >applications in the future. I say, if it's needed in the future, *then* >provide the .so, otherwise -- keep it simple! > > No comment ... > > >>And even today: I can re-distribute them but they >>might never go open >>source. >> >> > >And that's a problem, why exactly? Why must everything be open source? > > Because, if you prefer to have a look, at how things are implemented. Then, for giving you an option to potentially change whatever you want. Where does the subString "Open" come from, in "OpenSolaris? > > >>And, finally, QEMU is tightly integrated into how gcc >>works. >>There is *NO* non-gcc compiler, on any OS or any >>ARCH, that could bring >>QEMU to work. >>Only gcc. >> >> > >Super!!! >So pretty much all the effort of Kernighan & Ritchie that went into creating a >*portable* language has been thrown out of a window!!! >More X-mas tree experts at work. That's why some people shouldn't be allowed >to even go near a computer, let alone "crank out" code. > > Super good: Finally someone who can and probably will fix this. Here is the code: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co /qemu/ _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
