James Carlson wrote: > Alan Coopersmith writes: > > 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. > > I like that idea; it should minimize duplication while allowing the > new libcmd to be delivered separately.
And we would have another library around for no technical reason. Another problem is that if we start (after the lawyers decided whether we can do that) to exchange code between OS/Net's native commands and the builtin commands in ksh93's libcmd for things like synconizsing the codebase and any of these commands needs the functions in the current Solaris version libcmd.so we end-up in a constellation where we need to link ksh93's libcmd.so against libsuncmd.so.1. That will be fun: First we rename the current Solaris libcmd.so to libsuncmd.so and then we make the new libcmd.so depend on libsuncmd.so.1 ... =:-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
