The Sun Developer Tools organization and the Sun OS/Net organization should collaborate to create an environment where customers can reliably create applications on S10 that run on S9. This could be done with very few caveats in the resulting system. In addition to leaving old interfaces in the kernel, you would also have to leave backwards compatible interfaces in the headers and libraries. This would be more work for Sun, but it would be very valuable for software developers.
--chris James Carlson wrote: > Chris Quenelle writes: >> James Carlson wrote: >>> Chris Quenelle writes: >>>> I ran into this problem in spades when Solaris 10 came out with libm.so.2 >>>> No program that uses libm can be linked on Solaris 10 and run on Solaris 9. >>> That sounds odd to me ... why would you _expect_ to be able to link a >>> program on Solaris 10 and then run it on Solaris 9? >> I would (if I didn't know better) expect it to work because my >> program uses only interfaces that are easily stable and available >> on both Solaris 9 and Solaris 10. > > It doesn't work that way. You _must_ build (compile and link) on the > oldest platform you intend to support -- period. There's no "my > program is simple" exception clause. > > The reason for this is obvious: we can and *do* change the internal > implementation of even stable interfaces in incompatible ways, so long > as the external portions are backward compatible. > > For a very simple example of the problem, and one I'm picking because > I happen to know a bit about, consider the fix for CR 4510295 (PSARC > 2002/709). This changed the behavior of the standard (BSD) > SIOCGIFCONF socket ioctl between S9 and S10, because historical > Solaris behavior was wrong. > > However, we didn't want to break existing binaries by springing a new > behavior on them. So, the existing ioctl was renamed to > O_SIOCGIFCONF, and the kernel still supports that ioctl with the old > (broken) behavior. A new one was introduced as SIOCGIFCONF. Thus, > old binaries will still get their old behavior and ones compiled anew > on S10 will get the new behavior. > > If you compile an application on S10 using the new ioctl number, > however, the application won't run at all on S9. The S9 kernel won't > know that number, and the call will fail. > > Similar things are true for the link-edit phase, because the set of > supported ELF sections and flags expands over time. If you link on > S10 and try to deploy on S9, you're on your own. Maybe it'll work. > Maybe it won't. I don't think we could or should or even would try to > support you. > > It's exceedingly difficult at times to engineer a system that keeps > backward compatibility; adding in "forward" compatibility would likely > just make the job impossible. It's a straightjacket. > >> It's intuitive that the program >> should link and run an either platform interchangeably. >> The fact that "no-brainer" compatibility fails on Solaris is >> a barrier to development, if the program needs to run on >> multiple versions of Solaris. > > Compile and link on the oldest version you need to support. > >> The answer I've gotten from some people at Sun boils down to: >> We can't make it work for every case, so we make a rule that says >> we don't have to worry about it. That's fine if you're concerned >> about rules. Most developers are only concerned about whether >> their stuff works or not. > > Indeed. And if they want to take advantage of our compatibility > story, then the rules for doing so are fairly simple -- stick to the > ABI, and compile on the oldest system on which you'll deploy. > > Of course, they don't have to do any of that, and if they don't, then > they're on their own. Their stuff might work, and it might not. > There are no guarantees in that case, and we can't make any. >
