On Wed, 29 Aug 2012 15:23:25 +0200 Lionel Cons wrote:
> On 29 August 2012 15:10, Glenn Fowler <g...@research.att.com> wrote:
> >
> > we're going to take some research leeway and investigate the implications
> > of {a}
> > we're not strangers to doing stuff like that (3d(1))
> > and we're not strangers to having research prove us wrong
> Well, if you use {a} then please remove the mamfile code which
> generates libshell.so - libshell.a is sufficient to build ksh. So far
> a shared library of libshell doesn't make sense until it gets actually
> usable for embedding. Right now it doesn't work for that purpose and
> if you pick {a} over {b} then I don't see a chance that it'll get any
> better anytime soon.
I'm not sure if you are pointing out problems with bootstrap build from source
or libshell.so built the right way with ast nmake -- the ksh93 Mamfile has
no actions for generating shared libs -- it does have the capability to set
cc -c options to generate .o's suitable for use in generating a shared lib
if you plan on using ast shared libs and plugins then you must build with at
least ast-base
this will build nmake first and then build everything else with nmake
its nmake that figures out the native incantations for building shared libs and
dlls
linux is not the only target
there are uses for shared/dll libshell
PACKAGE_OPTIONS=optimize-space uses it for a smaller ksh a.out footprint
and uwin builds shell.dll by default
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
