> X-Unix-From: roland.mainz at nrubsig.org Wed Feb 15 16:01:03 2006
>
> Glenn Fowler wrote:
> > On Wed, 15 Feb 2006 16:13:27 +0100 Felix Schulte wrote:
> > > On 2/15/06, Henk Langeveld <hlangeveld at mailworks.org> wrote:
> > > > Glenn Fowler wrote:
> > > > > libast -- major components used by ksh
> > > > > libcmd -- builtin commands (can be pruned to essential builtins)
> > > > > libdll -- portable runtime plugin interface
> > > > As an alternative, we could consider creating an AST BRANDZ distribution
> > > > for Solaris...
> > > And this makes sense - how?
> > > libast is similar to Mozilla NSPR (portable run time) library idea and
> > > the total size of all the three libs doesn't justify a whole new
> > > distribution.
> >
> > for solaris packaging
> >
> > if the goal is dynamic ksh linked against the shell shared lib then
> > it would be possible to link { libshell.a libcmd.a libdll.a libast.a }
> > into an all-in-one libshell.so so that the only ksh specific shared lib
> > would be libshell.so
> >
> > this fits in with the ast build system where shared libs are built from
.a's,
> > so building the all-in-one libshell would just be one extra ld command
>
> Did any distribution tried this "all-in-one-libshell.so"-approach yet ?
>
> > user -lcmd style plugins are currently documented to link against -lshell
> > the (ast nmake) build system maps -lshell to its constituents
> > so on solaris
> > -lshell => -lshell
> > and on non-solaris
> > -lshell => -lshell -lcmd -ldll -last
> >
> > I haven't tested this but it should be possible to package other ast
> > commands for solaris to be linked against the all-in-one -lshell
>
> April - what do you think about this ? Should we...
> a) ... treat libast/libcmd/libdll as seperate libraries distributed over
> the Solaris source tree
> b) ... should we just put them all together into libshell.so as Glenn
> proposed
> ... or how else should we handle the problem ?
My preference, at least initially, is
to compile the libraries statically into ksh93 and to postpone the
sharing of the libraries for a later phase of the project.
I think this will simplify things for now and will allow us to get
ksh93 integrated and into Open Solaris sooner. I appreciate the
functionality that these interfaces offer, but right now, I'd like to
focus on getting a ksh93 that will boot and build Solaris and which
works for the existing Open Solaris scripts. Please let me know if
there are strong objections to this.
Thanks,
April
>
> libast may be usefull for other applications so haveing it seperate (in
> both source tree and /usr/lib/ (/usr/sfw/lib/ cannot be used as it may
> be mounted seperately late during boot and therefore may screw-up boot
> scripts if ksh relies on libs there)) may be usefull... but [b] sounds
> good for me, too. I am unsure how to proceed... ;-(
> April ?
>
> ----
>
> Bye,
> Roland
>
> --
> __ . . __
> (o.\ \/ /.o) roland.mainz at nrubsig.org
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
> /O /==\ O\ TEL +49 641 7950090
> (;O/ \/ \O;)
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/ksh93-integration-discuss
