> Date: Wed, 6 Dec 2006 13:08:08 -0800
> From: Danek Duvall <danek.duvall at sun.com>
> To: April Chin <April.Chin at eng.sun.com>
> Cc: gk at onnv.eng.sun.com, roland.mainz at nrubsig.org,
ksh93-integration-discuss at opensolaris.org
> Subject: Re: proposed solution for LD_LIBRARY_PATH problem
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: mutt-ng/devel-r535 (SunOS)
>
> On Wed, Dec 06, 2006 at 12:50:52PM -0800, April Chin wrote:
>
> > 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.
>
> Ah. This last was not something I was aware of. Can you explain what this
> library is and why it won't be delivered?
Originally, the thought was that, other than msgcpp and other AT&T binaries
used for building messages for ksh93, there is no other justification
for installing libpp, so we kept it out of the original ARC case for
ksh93 (PSARC/2006/550). But, if other projects (possibly outside of ON)
use any of the new AT&T libraries from (libshell, libast) in the future,
they would need libpp, msgcpp, and the msgcc ksh93 script, to build
localized messages. So we may want to ARC the addition of
libpp/msgcpp/msgcc now. Roland Mainz has been advocating this, and I'm
beginning to see now that this makes sense.
>
> > 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.
>
> This would certainly be safer than using $ROOT, but the problem doesn't
> entirely disappear -- if there are any interfaces between the AT&T
> libraries and libc (and any other libraries loaded by running ksh93) which
> have changed incompatibly. Could that ever happen?
The libc dependency is probably rare, but not impossible.
If we include the installation of libpp and the message-building
binaries/scripts into Solaris, the use of LD_LIBRARY_PATH pointing to
$TMPDIR could be a transitional solution, to avoid problems (unless
the rare libc mismatch situation appears during that interval) with
build machines until they get upgraded to a build containing ksh93 and
the AT&T libraries.
So would it be reasonable to use a wrapper script to the
message-building portion of the ksh93 build, with
LD_LIBRARY_PATH pointing to a $TMPDIR
containing links to the proto area as a temporary solution?
This wrapper script could be removed after maybe 3 or 4 builds
(whatever seems appropriate), with an accompanying flag day.
Thanks,
April
>
> Danek
