Dan Price wrote:
>
> I've been following this project, although I just joined the
> mailing list.
>
> I have a couple of questions regarding the shape of the
> project:
>
> - What is the nature of the replacing of libcmd.so? If I'm
> not mistaken, I noticed that the existing libcmd.so is
> being overwritten by the tarball which was recently
> published. I wondered why that would be.
Both Solaris and ksh93/AST have a library called libcmd - for Solaris it
is an old "relict" from ancient times which currently only carries the
|def*()|-functions to read+parse files from /etc/default/. ksh93/AST has
a libcmd which contains some ksh93 builtin commands (those commands
which are not mandatory to get libshell up and running - those commands
live in libshell (David/Glenn may be able to explain that better)).
We've looked at the problem and realised that renaming libcmd.so.1 will
be a HORRIBLE pain since many other consolidations depend on it, making
even the process of one or multiple flag days a serious pain. The pain
will even be MUCH harder because I am external contriutor which means
getting one or more flag days syncronised is almost impossible (for me).
Another option would be to rename ksh93's libcmd.so - but that would
break compatibility with the original AT&T version - and to make it
clear: We're NOT going that way in ANY circumstances (remeber why
Solaris /usr/bin/ksh is so bad - because even tiny "excuses" were
enougth to hack it to death which caused more and more diversion from
the origianl ksh88 version and horrible interoperability problems).
A quick analysis revealed a very simple solution:
- All exported symbol names in the Solaris version of libcmd.so start
with "def"
- All exported symbol names in the ksh93 version of libcmd.so start with
"b_" ("b_" is the prefix for ksh93 builtin commands, e.g. the builtin
"printf" has the function name |b_printf|)
- A scan over an Solaris Nevada/B37 installation, Solaris 10U1/SPARC and
Solaris 8/SPARC (all installations done with "full install+OEM support")
showed that there are no symbol name collisions with the only exception
of "dtksh" - but that is a ksh93 variant (with CDE addons) and does not
use libcmd.so
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
(this is important since there are already requests to make a backport
of our work to Solaris 10 once we are ready for that).
The resulting prototype002 sources for the unified version of libcmd.so
can be found under
http://polaris.blastwave.org/browser/on/branches/ksh93/gisburn/prototype002/m1_ast_ast_imported/usr/src/lib/libcmd/
(note that ksh93-integration prototype002 is based on B37).
> - Which consolidation is this project targetting?
We are targeting direct integration into OS/Net (note: All the code has
already been WRITTEN and is ready for integration, excluding the changes
done with "CR# 6357230 - 'specfiles should be nuked'", but those
adjustments can be done in less than two hours (incl. testing, right now
I am waiting for Roger.Faulkner at eng.sun.com to reply on a minor question
here)) since this the place where the old "ksh" originally lived (now in
"closed") and /sbin/sh now lives. libshell (which is ksh93 made
available as shared library (which means that /usr/bin/ksh93 is just a
5k-8k wrapper which directly calls into libshell code)) may be usefull
for other applications like zone/ufs/SMF (adminstration) tools
(supplementing or replacing libtecla) which make it mandatory that ksh93
lives in OS/net directly.
> I
> understand that ksh93 has its own build system, and
> I was wondering which consolidation would best accomodate
> that uniqueness.
We do not use the original AST build system for ksh93 in OS/Net - I
wrote Makefiles which works like all other OS/Net stuff. Everything is
done, see
http://polaris.blastwave.org/browser/on/branches/ksh93/gisburn/prototype002/m1_ast_ast_imported/usr/src
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
