On Mon, May 7, 2012 at 4:33 AM, Irek Szczesniak <[email protected]> wrote: > On Fri, May 4, 2012 at 5:14 PM, Glenn Fowler <[email protected]> wrote: >> >> On Fri, 4 May 2012 16:33:24 +0200 Irek Szczesniak wrote: >>> On Fri, May 4, 2012 at 7:15 AM, Glenn Fowler <[email protected]> wrote: >>> > and we should all be a bit skeptical since dgk and I are using experience >>> > with -lcmdtst(grep,xargs) >>> > to update the documents on how to code ksh builtins >> >>> Are these documents included in the next ast-open release? >> >> I'm checking with dgk on the progress today >> >>> Oh, and the usual question: When will the git be updated? :) >> >> the git will be updated with the beta update >> we located the problem and it shouldn't happen (in this way at least) again >> >>> Does nmake support including other makefile fragments, e.g. does it >>> have an #include statement? >> >> many different ways >> * --file=file (on the command line) >> * --global=file (on the command line, user makefile vars override global >> makefile vars) >> * include [-] "file" (- for dontcare if it doesn't exist) >> * :ASSERTION_NAME: (if not already defined includes ASSERTION_NAME.mk) >> * create src/cmd/nmake/Localrules.mk and then nmake install from >> $INSTALLROOT/src/cmd/nmake >> Localrules.mk will not be clobbered by new package distributions >> >> you can also insert command line args from a top level component dir >> (arch/...) >> by placing the args, one per line in one of these files { Makeargs, >> makeargs, Nmakeargs, nmakeargs) >> >>> > bin/.paths >>> > BUILTIN_LIB=cmdtst >>> > LD_LIBRARY_PATH=../lib >>> > lib/cmdtst.so >> >>> Well, OK. The trouble I tried to avoid was to have a second >>> libcmd.so.1 (called libcmdtst.so.1) floating around which has to link >>> explicitly against Roland Mainz's version of busybox >>> (https://raw.github.com/joyent/illumos-joyent/master/usr/src/cmd/ksh/builtins/alias.c). >>> Having all of these builtins in one shared library would've made >>> logistics much easier. >> >> "easy" is a relative term >> for a space-optimized ksh implementation I can see your point >> in that case I'm guessing ksh is built with SHOPT_CMDLIB_HDR==1 to make all >> -lcmd builtin >> >> I'm pushing alternative -lcmdfoo a bit because { *grep xargs } won't be the >> last builtin candidates >> and we can probably expect many more non-posix-section-1 builtins that would >> not be appropriate for -lcmd >> we don't want to get bug reports on frankenstein ksh builds that will be >> hard to reproduce on our side >> having separate non-standard plugin libs will help isolate problems to >> either ksh or the plugins >> >> we modeled the .paths builtin lookup after PATH lookup >> if there weren't builtins you would have to populate a PATH dir with a.out's >> I have to double check with dgk but I believe a .paths file can have more >> than >> one BUILTIN_LIB statement, so you could install libcmdtst.so in the same dir >> as libcmd.so >> and just add BUILTIN_LIB=cmdtst after BUILTIN_LIB=cmd >> >> does the busybox ksh link against libshell.so or libshell.a? > > ast busybox links against libshell.so to conserve space since busybox > and ksh are still independent executables. I may have to persuade > Roland to merge at least sh/ksh and busybox so libshell can be linked > statically into this binary.
Erm... which means libshell can't be used by other consumers anymore. IMO the busybox stuff and /usr/bin/sh should continue to link seperately dynamically to libshell. That help at least a bit with the risk management, e.g. if someone touches the busybox wrapper /usr/bin/sh can't be screwed-up (and reverse). > Busybox is used on machines which have little room, usually running > with as little as 64MB memory and 512MB disk space (for ARM and MIPS32 > architectures). AST busybox fits tightly into this footprint, but > there is little margin for more. I wish we could reduce disk footprint > a bit more. Well, we didn't even start yet with optimisations for disk space... ;-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
