From joseph@cscaper.com

Created by joseph@5sigma.com

DynaLoader on solaris 7 seems to ignore libpth and follow LD_LIBRARY_PATH
instead. I discovered this when some CGI programs of mine using a new
version of mysql began to fail when execute by the server (as nobody)
because of mysql's affection for libz.so. I had libz.so in /usr/local/lib,
and I see the following in DynaLoader on that machine​:

  push(@​dl_library_path, split(' ', '/usr/local/lib /lib /usr/lib'));

Nevertheless, libz.so was never found unless LD_LIBRARY_PATH was set. I
wound up having to symlink libz.so into /lib. I tried a couple of other
things​:

  BEGIN { $ENV{LD_LIBRARY_PATH} = "/usr/local/lib" }

for example, but that didn't seem to have any effect.

I must be missing something here. Is there a way other than LD_LIBRARY_PATH
to specify a run-time loading path for Perl modules on Solaris? If so,
what is it?

Do @​dl_library_path and/or libpth have ANYTHING to do with how DynaLoader
actually works on Solaris?

(Please reply via email--was dropped from p5p a while ago when I had
a couple of ~1 day net outages, and haven't bothered to resubscribe.)

  -joseph

--
Joseph N. Hall, 5 Sigma Productions mailto​:" <joseph> "@​5sigma.com
Author, Effective Perl Programming . . . . . http​://www.effectiveperl.com
Perlfaq Prime . . . . . . . . . . . . . . . . . . http​://www.perlfaq.com

Site configuration information for perl 5.00502:

Configured by root at Thu Dec 31 02:40:42 MST 1998.

Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
  Platform:
    osname=solaris, osvers=2.7, archname=sun4-solaris
    uname='sunos rom 5.7 generic sun4u sparc sunw,ultrasparc-iii-engine '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='gcc -B/usr/ccs/bin/', optimize='-O', gccversion=egcs-2.91.60 19981201 (egcs-1.1.1 release)
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00502:
    /usr/local/lib/perl5/5.00502/sun4-solaris
    /usr/local/lib/perl5/5.00502
    /usr/local/lib/perl5/site_perl/5.005/sun4-solaris
    /usr/local/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00502:
    HOME=/home/joseph
    LANG (unset)
    LD_LIBRARY_PATH=/usr/lang/SC1.0:/usr/local/lib:/usr/lib:/usr/openwin/lib
    LOGDIR (unset)
    PATH=.:/usr/local/bin:/usr/ucb:/bin:/usr/bin:/usr/5bin:/etc:/usr/etc:/usr/lang:/usr/ccs/bin:/usr/sbin:/usr/X11/bin:/usr/openwin/bin:/usr/local/framemaker/bin:/usr/local/pbmplus/bin:/usr/local/games/bin
    PERL_BADLANG (unset)
    SHELL=/bin/tcsh

From [Unknown Contact. See original ticket]

joseph@​cscaper.com [joseph@​cscaper.com] quoth​:
*>
*>DynaLoader on solaris 7 seems to ignore libpth and follow LD_LIBRARY_PATH
*>instead. I discovered this when some CGI programs of mine using a new
*>version of mysql began to fail when execute by the server (as nobody)
*>because of mysql's affection for libz.so. I had libz.so in /usr/local/lib,
*>and I see the following in DynaLoader on that machine​:

I don't think this is a bug as I've seen this behaviour before...From the
Dynaloader docs;

"@​dl_library_path

The standard/default list of directories in which
dl_findfile() will search for libraries etc. Directories are searched in
order​: $dl_library_path[0], [1], ... etc

@​dl_library_path is initialised to hold the list of 'normal'
directories (/usr/lib, etc) determined by Configure ($Config{'libpth'}).
This should ensure portability across a wide range of platforms.

@​dl_library_path should also be initialised with any other
directories that can be determined from the environment at runtime (such
as LD_LIBRARY_PATH for SunOS).

After initialisation @​dl_library_path can be manipulated by
an application using push and unshift before calling dl_findfile().
Unshift can be used to add directories to the front of the search
order either to save search time or to override libraries with the same
name in the 'normal' directories.

The load function that dl_load_file() calls may require an
absolute pathname. The dl_findfile() function and @​dl_library_path can
be used to search for and return the absolute pathname for
the library/object that you wish to load."

Also, I've seen;
"mysqld restarted on Wed Jan 19 00​:13​:37 CST 2000
mysqld started on Wed Jan 19 23​:44​:58 CST 2000
ld.so.1​: /pkg/usr-local/mysql/libexec/mysqld​: fatal​: libz.so​: open failed​:
No such file or directory"

But this was after I built a new version of mySQL and forgot to compile it
statically so that I needed to set LD_LIBRARY_PATH on start-up.

So, it would appear to be a 'feature' with mySQL.

e.

From [Unknown Contact. See original ticket]

Elaine -HFB- Ashton writes​:

joseph@​cscaper.com [joseph@​cscaper.com] quoth​:
*>
*>DynaLoader on solaris 7 seems to ignore libpth and follow LD_LIBRARY_PATH
*>instead. I discovered this when some CGI programs of mine using a new
*>version of mysql began to fail when execute by the server (as nobody)
*>because of mysql's affection for libz.so. I had libz.so in /usr/local/lib,
*>and I see the following in DynaLoader on that machine​:

I don't think this is a bug as I've seen this behaviour before...From the
Dynaloader docs;

"@​dl_library_path

To make the long story short​: @​dl_library_path is used *by Perl* to
find an extension DLL. After DLL is found, it is being loaded. But
this DLL *in turn* may require loading of other DLLs - and now this
loading is done by the system, not by Perl.

Thus during to loading of this "chained" DLLs the value of
@​dl_library_path is not relevant.

Ilya

From [Unknown Contact. See original ticket]

How did you wind up replying to joseph@​cscaper.com? As I recall, I
used "joseph@​5sigma.com" for BOTH perlbug addresses. Is this a
bug in perlbug?

(Obviously, mail to joseph@​cscaper.com gets a bounce message and
goes into my spam bucket.)

  -joseph

--
Joseph N. Hall, 5 Sigma Productions mailto​:" <joseph> "@​5sigma.com
Author, Effective Perl Programming . . . . . http​://www.effectiveperl.com
Perlfaq Prime . . . . . . . . . . . . . . . . . . http​://www.perlfaq.com

On Mon, 21 Feb 2000 13​:32​:50 -0600 elaine@​chaos.wustl.edu (Elaine -HFB- Ashton)
wrote​:

* Return-Path​: <elaine@​history.perl.org>
* Delivered-To​: joseph@​cscaper.com
* Received​: (qmail 29580 invoked from network); 21 Feb 2000 19​:35​:54 -0000
* Received​: from chaos.wustl.edu (elaine@​128.252.133.13)
* by rom.cscaper.com with SMTP; 21 Feb 2000 19​:35​:54 -0000
* Received​: (from elaine@​localhost)
* by chaos.wustl.edu (8.9.3+Sun/8.9.3/HappyFunMail) id NAA20441;
* Mon, 21 Feb 2000 13​:32​:50 -0600 (CST)
* Date​: Mon, 21 Feb 2000 13​:32​:50 -0600
* From​: Elaine -HFB- Ashton <elaine@​chaos.wustl.edu>
* To​: joseph@​cscaper.com
* Cc​: perl5-porters@​perl.org
* Subject​: Re​: [ID 20000218.005] DynaLoader behavior w.r.t. LD_LIBRARY_PATH
* confuses me
* Message-ID​: <20000221133250.K15259@​chaos.wustl.edu>
* References​: <20000219015645.17833.qmail@​mail.cscaper.com>
* Mime-Version​: 1.0
* Content-Type​: text/plain; charset=us-ascii
* X-Mailer​: Mutt 1.0pre3i
* In-Reply-To​: <20000219015645.17833.qmail@​mail.cscaper.com>
* X-HappyFunBall​: Do Not Taunt.
*
* joseph@​cscaper.com [joseph@​cscaper.com] quoth​:
* *>
* *>DynaLoader on solaris 7 seems to ignore libpth and follow LD_LIBRARY_PATH
* *>instead. I discovered this when some CGI programs of mine using a new
* *>version of mysql began to fail when execute by the server (as nobody)
* *>because of mysql's affection for libz.so. I had libz.so in /usr/local/lib,
* *>and I see the following in DynaLoader on that machine​:

From [Unknown Contact. See original ticket]

On Mon, 21 Feb 2000 15​:04​:18 -0500 (EST) ilya@​math.ohio-state.edu (Ilya
Zakharevich) wrote​:

* To make the long story short​: @​dl_library_path is used *by Perl* to
* find an extension DLL. After DLL is found, it is being loaded. But
* this DLL *in turn* may require loading of other DLLs - and now this
* loading is done by the system, not by Perl.
*
* Thus during to loading of this "chained" DLLs the value of
* @​dl_library_path is not relevant.
*
* Ilya

That's clear enough, I guess, although it doesn't work "right" as
far as I'm concerned and I doubt anyone else would consider it
"right" either.

Why does changing $ENV{LD_LIBRARY_PATH} appear to have no effect?

Would it make sense for DynaLoader to alter LD_LIBRARY_PATH to
ensure it contains at least the libraries mentioned in libpth or
@​dl_library_path?

  -joseph

--
Joseph N. Hall, 5 Sigma Productions mailto​:" <joseph> "@​5sigma.com
Author, Effective Perl Programming . . . . . http​://www.effectiveperl.com
Perlfaq Prime . . . . . . . . . . . . . . . . . . http​://www.perlfaq.com

From [Unknown Contact. See original ticket]

On Tue, Feb 22, 2000 at 12​:37​:41PM -0700, Joseph N. Hall wrote​:

That's clear enough, I guess, although it doesn't work "right" as
far as I'm concerned and I doubt anyone else would consider it
"right" either.

Why does changing $ENV{LD_LIBRARY_PATH} appear to have no effect?

How could it have an effect? I would think environ structures are
parts of CRT library structures. How would kernel know that you
modified environ?

Would it make sense for DynaLoader to alter LD_LIBRARY_PATH to
ensure it contains at least the libraries mentioned in libpth or
@​dl_library_path?

If this is possible (yes on OS/2, but not via environment)​: should
DynaLoader check that LD_LIBRARY_PATH did not change between loading
of two modules? Should this propagate to kid processes?

I think this is opening a larger can of worm than what we do now.

Ilya

From [Unknown Contact. See original ticket]

Joseph N . Hall <joseph@​5sigma.com> writes​:

Why does changing $ENV{LD_LIBRARY_PATH} appear to have no effect?

Perhaps because it is ignored for setuid programs.

Would it make sense for DynaLoader to alter LD_LIBRARY_PATH to
ensure it contains at least the libraries mentioned in libpth or
@​dl_library_path?

Not really dlopen() DynaLoader does not really work that way, and as
pointed out above LD_LIBRARY_PATH is not sufficient for setuid applications.

On solaris and other SVR4 derived things extensions are supposed to be
built with LD_RUN_PATH set so that right paths are "compiled in" and
hence trusted for setuid purposes.

Running 'ldd' on the loadables should show whether the LD_RUN_PATH
has "worked". Note that if you use GNU ld then a different scheme
is needed (--rpath ???) is needed rather than LD_RUN_PATH - that
is assuming your can find a GNU ld that works at all ;-)

--
Nick Ing-Simmons

From [Unknown Contact. See original ticket]

(CC to Tim Bunce and developer@​lists.mysql.com)

(To summarize, DBD​::mysql was failing when run with a
null LD_LIBRARY_PATH because, apparently, the correct search
path including /usr/local/lib (on my machine) wasn't being
built into -- I think -- DBD​::mysql, and so libz.so wasn't
being found in /usr/local/lib on my machine. Was NOT linking
with GNU ld on Solaris, of course.)

I guess that is either a DBI or MySQL issue then. I attempted to
do a more or less plain build of MySQL on Solaris. The last
version I built failed at first because mysql configure was
unhappy about finding its friend libz.so in /usr/local/lib, or
maybe not finding it. I reported configure's rather peculiar
behavior (manifested as a failure in the "determine the size
of char" test program) to the MySQL developers and I gather
something must have changed. Meanwhile I built *that* version
without compression at all. The current version (which I was
installing for the security fix) behaved a bit differently and
built successfully. I rebuilt DBI and DBD​::mysql also, just
in case, and except for a couple of apparently unrelated failures,
everything worked satisfactorily when I tested DBI. When I threw
it into production, though, it blew up, and it took me about an
hour to figure out exactly what the problem was, and to "fix"
it by linking libz.so to /usr/lib/libz.so because I had no idea
how I might fix the shared library search path in this case.

By the way, the program in question was not running setuid. It
seems to me that it ought to be possible to change LD_LIBRARY_PATH
at runtime through %ENV but then again, maybe it don't work thataway.

  -joseph

--
Joseph N. Hall, 5 Sigma Productions mailto​:" <joseph> "@​5sigma.com
Author, Effective Perl Programming . . . . . http​://www.effectiveperl.com
Perlfaq Prime . . . . . . . . . . . . . . . . . . http​://www.perlfaq.com

On Tue, 22 Feb 2000 20​:56​:06 +0000 nick@​ing-simmons.net (Nick Ing-Simmons)
wrote​:

* Joseph N . Hall <joseph@​5sigma.com> writes​:
* >
* >Why does changing $ENV{LD_LIBRARY_PATH} appear to have no effect?
*
* Perhaps because it is ignored for setuid programs.
*
* >
* >Would it make sense for DynaLoader to alter LD_LIBRARY_PATH to
* >ensure it contains at least the libraries mentioned in libpth or
* >@​dl_library_path?
*
* Not really dlopen() DynaLoader does not really work that way, and as
* pointed out above LD_LIBRARY_PATH is not sufficient for setuid applications.
*
* On solaris and other SVR4 derived things extensions are supposed to be
* built with LD_RUN_PATH set so that right paths are "compiled in" and
* hence trusted for setuid purposes.
*
* Running 'ldd' on the loadables should show whether the LD_RUN_PATH
* has "worked". Note that if you use GNU ld then a different scheme
* is needed (--rpath ???) is needed rather than LD_RUN_PATH - that
* is assuming your can find a GNU ld that works at all ;-)
*
* --
* Nick Ing-Simmons

From [Unknown Contact. See original ticket]

Joseph N . Hall <joseph@​5sigma.com> writes​:

By the way, the program in question was not running setuid. It
seems to me that it ought to be possible to change LD_LIBRARY_PATH
at runtime through %ENV but then again, maybe it don't work thataway.

Oh _that_ feature - ld.so read LD_LIBRARY_PATH when execuable starts
(it needed it to find libc to find the thing that called main() ...)
So you have to set it then re-exec yourself so that loader sees the update.

--
Nick Ing-Simmons