April Chin 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 ?
>
> Yes, libcmd is a Sun private library, and its interfaces are
> used in some 40-odd source files in our ON (OS-Networking) consolidation.
> However, there appear to be dependencies on libcmd from consolidations
> outside of ON (so they're not part of Open Solaris),
Ouch...
> to which I have no access.
> So, yes, we may be able to change the libcmd name, but the change will need
> to be communicated and coordinated with other groups and needs to be
> approved by our architecture review committee (PSARC).
>
> However, I also think that we may need to narrow the scope
> of the ksh93 work and not create libcmd and the other shared libraries,
> at least initially.
Well, at least having libshell.so would be nice as people could then
start to rip-out all the homegrown commandline parsing code in some
applications (which will likely also produce feedback how well ksh93 is
working in Solaris). Splitting the all-in-one (e.g. contains libshell,
libcmd, libdll and libast) version of libshell.so won't hurt as
libshell.so is a consumer of all these libraries anyway so the linker
will pull them in anyway (e.g. I do not expect problems with binary
compatibility).
Additionally dbx people could start their work in parallel...
> I'm sorry I haven't kept up with some threads of the discussion
> regarding the libraries, so you have understandably gone ahead to work on
> including the libraries. I'll put my reply in that thread.
Ok...
BTW: I have attached a small script
("buildksh93_solarisx86_20060301.ksh") which I hacked yesterday night
(erm... which means the quality isn't perfect... it's the usual
5mins-before-falling-asleep-hack) which allows to build a dynamically
linked ksh. The resulting "ksh" binary is just 5k (stripped, 12k
non-stripped debug) ... :-)
Build sequence is then simply (on Solaris 10 x86):
% gunzip -c INIT.2006-01-24.tgz | tar -xf -
% gunzip -c ast-ksh.2006-01-24.tgz | tar -xf -
% ksh buildksh93_solarisx86_20060301.ksh 2>&1 | tee -a buildlog.log
In the meantime I've also hacked a ON-compatible build system for
libast...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
-------------- next part --------------
#!/usr/bin/ksh
set -e -x
IGNORE=""
CCFLAGS="-g -xs $IGNORE"
HOSTTYPE=sol10.i386
CC=/opt/SUNWspro/bin/cc
export CCFLAGS CC HOSTTYPE
bin/package make
root=$(echo ${PWD}/arch/sol10.i386)
test -d $root || exit 1
log=${root}/lib/package/gen/make.out
test -s $log || exit 1
# libcmd cannot be dynamically for now as there is a squatter in solaris
for lib in libast libdll libshell ; do
test $? -eq 0 || exit 1
case "$lib" in
libshell)
base=lib/
vers=1
link="-L${root}/lib/ -lcmd -ldll -last -lm"
;;
*)
base=src/lib/$lib
vers=1
link=""
;;
esac
(
cd ${root}/${base}
$CC -G -o ${root}/lib/${lib}.so.${vers} ${lib}.a -Wl,-zallextract
-Wl,-zmuldefs $link
#rm ${lib}.a
mv ${lib}.a disabled_${lib}.ax
cd ${root}/lib
ln -sf ${lib}.so.${vers} ${lib}.so
)
done
(
base=src/cmd/ksh93
cd ${root}/${base}
rm -f ${root}/lib/libshell.a
rm -f ${root}/lib/libdll.a
rm -f ${root}/lib/libast.a
# uhm... this only works for a full build... ;-(
cc -g -xs -L${root}/lib/ -o ksh pmain.o -lshell -lcmd -ldll -last -lm -lsecdb
)
# EOF.
