--- "Richard L. Hamilton" <[EMAIL PROTECTED]> wrote: > > > > > The correct way to fix this whole situation is > for > > > Linux developers to migrate to Solaris, and > forget > > > about Linux. That would fix all these > compilation > > > issues. > > > > OOh, I like this one. Forget gcc compatibility. > Kill > > Sun Studio gcc extension support now! Just make > that > > hoard of gcc extension using developers port their > > code to Solaris for their users. Sorry? No users > > using > > Solaris? No demand? You get treated like dirt? > > > Actually, you both have a point. > > First, I don't know that he was specifically > referring to gcc extensions.
There is not much else preventing success compilations. > > But it's IMO not wrong to complain about them; it's > not quite as if > gcc and Studio are the only compilers in the > universe, they're just > the main ones on Solaris (and of course gcc does > have the point in > its favor that it's just about everywhere else, > too). In other words, > porting to Solaris may not be the only place where > unencapsulated > dependence on gcc-isms causes problems. > (encapsulated use where needed, > so long as alternatives are generally available, > isn't such a big deal, > as it can be much less of an obstacle to porting) You won't find this problem on the BSDs or even Mac OS X. At least now that Sun Studio is available for free (I tried to keep an eye out for this but I still did not find out until recently) it should be possible to nudge developers to try it out. icc has been around for quite a while already and it still does not compile everything...most probably because it was not free enough. I hope Sun Studio changes all this. > > OTOH, it's a fact that there's a lot of that sort of > code out there, and > I certainly don't have a problem with Studio picking > up compatibility > features, as long as it retains a more strict mode > of operation compatible > with existing Studio makefiles and existing > Studio-compiled C++ object > files; the latter also because it's necessary to > remain aware of when one > is using extensions, so that one can avoid them when > appropriate. > Failing the realism of an extension-free environment > (since there > are some cases where extensions are needed, although > less than where > they are used), having two different sets of > extensions at least allows > one to remain aware of such problem areas. I would not worry about make files. Using gmake, nmake, whatvermake is rather common. That the g++ ABI is different from Sun's has been brought out already in a previous thread. > > That highlights one of the problems that I have with > some of what I > perceive happening with some open-source developers: > they either > aren't aware when they're doing platform or compiler > specific things, > or they just don't care, because they're more > concerned with getting > something running on _their_ platform using _their_ > first choice of > tools than with taking the time to familiarize > themselves with portability > issues enough that the ability to port their work > won't be just an afterthought. > Indeed, I suspect some of them would just as soon > not have their work run > on anything but their preferred platform, which > strikes me as more or > less contrary to the notion of open source, and > going past open source > pragmatism, past even license ideology, and off into > platform religion. That is rather unfair given that access to Sun Studio was previously restricted to those who could and would pay. There is a reason for gcc becoming popular on Solaris. Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ opensolaris-discuss mailing list [email protected]
