Roland Mainz wrote: > While working on getting all the parts of ksh93 integrated in the ON > tree I discovered a serious problem: > /usr/src/lib/libcmd/ is already IN USE by something else. While the > library there only has one tiny source file > (http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libcmd/common/deflt.c) > it seems to be used by some applications in the tree. > > Questions (to the Sun staff here): > - Is on/usr/src/lib/libcmd/ a public API supported by Sun (e.g. > "stable"/"evolving" API) or is it something like "private" or "unstable" > which can be changed every second ? > - Can we still put ksh93's libcmd.so into /usr/lib/ without renaming it > ? > - Can we get the current source in on/usr/src/lib/libcmd/ moved to > somewhere else ?
Small update: I asked on irc://irc.freenode.org/#opensolaris about the issue and got the following responses (see http://servlet.uwyn.com/drone/log/bevinbot/opensolaris/20060301 for parts of the log): - libcmd currently build from on/usr/src/lib/libcmd/ only contains "private" API, e.g. it can be changed any moment by Sun without warning to the customers - Most of it's functionality was removed duing Solaris 10 development since it was unused, the remaining API is just a bunch of functions which read defaults from files in /etc/default/ - The remaining API isn't worth to be stored in a seperate shared library. - Quote: "<jmcpAtSun> gisburn: file an RFE to remove what's left of libcmd" So far my proposal would be to get rid of libcmd.so - either via... 1. ... moving the functionality into the consumers, 2. ... renaming libcmd to something like libdefcmd or 3. ... link the library statically into consumers. April - any comments/ideas/suggestions ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
