Dan Price wrote: > On Wed 23 Aug 2006 at 05:30PM, Alan Coopersmith wrote: > > Roland Mainz wrote: > > >Therefore we choose the solution of "merging" both libraries - we take > > >the ksh93 version of libcmd and the Solaris libcmd and make one library > > >from it, avoiding major problems with other consolidations and even > > >honor binary backwards-compatibility to older versions of libcmd.so > > > > You can preserve binary compatibility without doing a full merge. > > Move the old one to libsuncmd.so.1 and then add filter entries to > > the mapfile for the ksh libcmd.so.1 to redirect users there. > > If nothing else it's easier for others to build their own ksh > > binaries and retain this compatibility, since they won't need to > > copy in the Sun libcmd sources. > > That's a good trick too. > > But to be clear: much has been made of binary compatibility in > this discussion, and that's a canard. We care about binary > compatibility for interfaces which are not private; since > solaris:libcmd.so is private, there is no end-user-facing binary > compatibility.
Small correction: We have to deal with that problem for a backport to Solaris 10. A removal (or move) of the |def*()| functions will make such backport MUCH more difficult because it will generate extra work to undo exactly what will be done in this "move" work. At some point we may have to give up the dream that we can backport anything to Solaris 10 or we have to agree to a compromise. As far as I know (not speaking for Sun, just a "feeling") there isn't simply enougth manpower at Sun to handle a backport for ksh93 if this putback makes libcmd.so incompatible to the version shipped with Solaris 10, right ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
