Roland Mainz writes: > > Does anyone outside of this project ever need to link against the new > > symbols provided in libcmd? > > Yes, there will be consumers outside the ksh93-integration project and > outside OS/Net.
Thank you. That's what several of us have been trying to get to -- an understanding of whether the theoretical future users included only wrapper versions of 'wc', 'expr', and others, or if there were significant *other* things that could not be dealt with by interface contracts. If so, then I agree that we can't change the name of this library. Nor can we change the name of the library used to reach the def* functions, because of the widespread (ab)use of that. This leaves us with accepting that /lib/libcmd.so.1 (currently on the root file system) grows from about 10KB to about 212KB, that libast.so.1 (on which this new libcmd.so.1 depends) must be in the root file system (adding another 992KB), and that every program previously linked with libcmd now goes from 260 bytes of .data and 4 bytes of .bss up to 30KB of .data and 60KB of .bss, even though those programs use none of the new functionality. It looks unattractive to me, but given the overconstrained problem, I see no other choices but to accept all this or to outlaw external applications from linking against this library. The latter seems somewhat possible, as I still doubt that having those programs link against this library is a good idea in the long run. It means that the applications can't take advantage of exec-time features, such as RBAC. That seems to me like a relatively high cost in exchange for a modest performance gain. Is it possible to discuss the utility of this library for things other than a new /usr/bin/wc implementation, or is the eventual use of it by diverse things (rather than a mere handful) just a fundamental assumption? -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
