Alan Coopersmith wrote: > Mike Kupfer wrote: > >>>>>> "Roland" == Roland Mainz <[EMAIL PROTECTED]> writes: > > > > Roland> Note: [libcmd] should not be used if possible. I have plans for it - > > Roland> and I am not sure whether the current API will surive them > > > > I agree that software outside of ON should not rely on the current > > libcmd. > > There are a couple of consumers in other consolidations already: > > % elfdump /usr/dt/bin/dtlogin | grep cmd > libcmd.so.1 SUNWprivate_1.1 > [162] D [8] libcmd.so.1 defopen > [179] D [8] libcmd.so.1 defread > [398] D [8] libcmd.so.1 defcntl > [8] NEEDED 0x16eb libcmd.so.1 > > % elfdump /usr/bin/gdm-binary | grep cmd > libcmd.so.1 SUNWprivate_1.1 > [4] NEEDED 0x298c libcmd.so.1 > > % elfdump /usr/X/bin/xlock | grep cmd > libcmd.so.1 SUNWprivate_1.1 > [107] 0x0002eb14 0x00000050 OBJT LOCL D 0 .data cmdlineTable > [23] DBL [9] libcmd.so.1 defcntl > [55] DBL [9] libcmd.so.1 defread > [76] DBL [9] libcmd.so.1 defopen > [9] NEEDED 0x85c libcmd.so.1
Uhm... why does "xclock" use libcmd.so ? > Not an unmanagable number if change is needed, just enough to require > coordinating with a number of people first. The "dtlogin" example was convincing enougth to go a different path - I found a way to maintain binary compatibility, see http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype001/m1_ast_ksh_imported/usr/src/lib/libcmd/common/ for an unfinished prototype (this is just a proff-of-concept prototype for the ksh93 integration...) ... :-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list [email protected]
