We have a question for the gatekeeers on a proposed solution for what is partly a bootstrapping problem for the ksh93 project. This message is being cc'd to the external mailing list ksh93-integration-discuss at opensolaris.org.
For building l10n messages for the ksh93 project, we need to use ksh93 itself and the AT&T libraries it uses--libast, libshell, libcmd, and libdll. This process also requires using another AT&T library, libpp, which will not be part of the Solaris release, although it has dependencies on (and should probably be kept in sync with) libast. Neither ksh93 nor its libraries will initially be on any build machines. The initial solution was to run the message-building script and binaries with LD_LIBRARY_PATH set to usr/lib in the proto area. James Carlson pointed out a potential problem if we link to the latest libc.so.1 in the proto area and it does not match an older kernel on the build machine. See http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-November/00 1884.html After some discussion, we'd like to build the message files by pointing LD_LIBRARY_PATH at a newly-created temporary directory under $(TMPDIR) (or /tmp by default) which would contain symlinks to the needed AT&T libraries in the proto area and a symlink to the newly-built libpp in $(SRCDIR)/usr/lib/libpp/$(MACH)/libpp.so.1. In this way, the message-building scripts and binaries would always run using the latest AT&T libraries, without inadvertently picking up newer versions of other libraries which might be a mismatch for the build system. Does this sound like a reasonable approach? Thanks, April
