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. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
