LD_LIBRARY_PATH should not end in ':'

[p5pRT]

Migrated from rt.perl.org#2071 (status was 'resolved')

Searchable as RT2071$

[p5pRT]

From @millert

Created by millert@courtesan.com

When building perl5.005_63 with shared lib support on OpenBSD/i386\, LD_LIBRARY_PATH gets set to "`pwd`​:" when there is no existing LD_LIBRARY_PATH in the environment. This confuses the OpenBSD ld.so and thus miniperl is run with /usr/lib/libperl.so instead of the freshly built libperl.so. While I do think that OpenBSD's ld.so should behave reasonably in this case\, it also seems that having a NUL component in LD_LIBRARY_PATH is wrong too. It's not clear what this *should* mean. In sh\, an empty PATH element mean cwd so perhaps that would be reasonable behavior. However\, even if ld.so did behave that way it would still be undesirable. In short\, I think that ldlibpth in Makefile.SH should only append to LD_LIBRARY_PATH if LD_LIBRARY_PATH is already set\, else it should just set LD_LIBRARY_PATH. Unfortunately\, this is easier said than done due to use of eval. In this case it is easier to just strip off errant :'s. Here's a simple patch against perl5.005_63. You may choose to do something more elegant...

Inline Patch

```diff --- Makefile.SH.DIST Tue Dec 7 23:23:10 1999 +++ Makefile.SH Wed Feb 2 11:49:20 2000 @@ -30,7 +30,12 @@ true) # Prefix all runs of 'miniperl' and 'perl' with # $ldlibpth so that ./perl finds *this* shared libperl. - ldlibpth="LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH" + case "$LD_LIBRARY_PATH" in + '') + ldlibpth="LD_LIBRARY_PATH=`pwd`";; + *) + ldlibpth="LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}";; + esac pldlflags="$cccdlflags" case "${osname}${osvers}" in @@ -78,6 +83,8 @@ eval "ldlibpth=\"$ldlibpthname=`pwd`:\$$ldlibpthname\"" ;; esac + # Strip off any trailing :'s + ldlibpth=`echo $ldlibpth | sed 's/:*$//'` ;; esac ;; ```

Perl Info

``` Site configuration information for perl 5.005_63: Configured by root at Fri Jan 28 17:14:17 MST 2000. Summary of my perl5 (5.0 patchlevel 5 subversion 63) configuration: Platform: osname=openbsd, osvers=2.6, archname=i386-openbsd uname='openbsd' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=2.95.2 19991024 (release) cppflags='-I/usr/local/include' ccflags ='-I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=true intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='' libpth=/usr/lib libs=-lm -lc libc=/usr/lib/libc.a, so=so, useshrplib=true, libperl=libperl.so.5.3 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags=' ' cccdlflags='-DPIC -fPIC ', lddlflags='-Bshareable ' Locally applied patches: @INC for perl 5.005_63: /usr/libdata/perl5/i386-openbsd/5.005_63 /usr/local/libdata/perl5/i386-openbsd/5.005_63 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl . Environment for perl 5.005_63: HOME=/home/millert LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/millert/bin/OpenBSD.i386:/home/millert/bin:/home/millert/bin/scripts:/usr/local/gnu/bin:/usr/local/bin:/usr/local/sbin:/usr/local/etc:/usr/local/rcs/bin:/usr/local/mh/bin:/usr/local/news/bin:/usr/local/emacs/bin:/usr/local/netpbm/bin:/usr/local/mtools/bin:/usr/local/netscape/bin:/usr/local/ghostscript/bin:/usr/local/X.V11R5/bin:/usr/local/X.V11R6/bin:/usr/local/frame/bin:/usr/local/teTeX/bin:/usr/local/cvs-1.10.1/bin:/usr/local/games/bin:/usr/local/archivers/bin:/usr/local/ssh/bin:/usr/local/skey/bin:/usr/local/cdrecord/bin:/bin:/sbin:/usr/games:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/X11/bin/.:/usr/X11R6/bin/.:/usr/local/bin/.:/usr/obj/bin/.:/usr/src/bin/. PERL_BADLANG (unset) SHELL=/usr/local/bin/tcsh ```

[p5pRT]

From [Unknown Contact. See original ticket]

ld.so should behave reasonably in this case\, it also seems that having a NUL component in LD_LIBRARY_PATH is wrong too. It's not clear what this *should* mean. In sh\, an empty PATH element mean cwd so perhaps that would be reasonable behavior. However\, even if ld.so did behave that way it would still be undesirable.

POSIX 1003.1 says that open/opendir on a null must fail\, contrary to some existing practices\, but a fine idea nonetheless.

POSIX 1003.2 says that a null path component is considered the cwd.

I wonder whether this has anything to do with the icky problems I had getting Perl to make install on openbsd due to the netbsd-derived loader search bug that Sarathy sent a patch for.

Minor note​: _64 just snuckered out the door.

--tom

[p5pRT]

From @millert

In message \13497\.949524439@​chthon   so spake Tom Christiansen (tchrist)​:

POSIX 1003.2 says that a null path component is considered the cwd.

Yup\, and I have a patch to the OpenBSD ld.so that makes it behave in that manner. Something should get committed in the next day or so. However\, other OS's may get bitten by this as well so I do think it is worth chopping off the extra '​:' in Makefile.SH.

- todd

[p5pRT]

From @doughera88

On Wed\, 2 Feb 2000\, Todd C. Miller wrote​:

In message \13497\.949524439@​chthon so spake Tom Christiansen (tchrist)​:

POSIX 1003.2 says that a null path component is considered the cwd.

Yup\, and I have a patch to the OpenBSD ld.so that makes it behave in that manner. Something should get committed in the next day or so. However\, other OS's may get bitten by this as well so I do think it is worth chopping off the extra '​:' in Makefile.SH.

I'd agree with Todd here. The cost of being defensive is zero for us (now that Todd's done the work and produced the patch).

  Andy Dougherty doughera@​lafayette.edu   Dept. of Physics   Lafayette College\, Easton PA 18042

[p5pRT]

From @gsar

On Wed\, 02 Feb 2000 13​:42​:59 MST\, "Todd C. Miller" wrote​:

When building perl5.005_63 with shared lib support on OpenBSD/i386\, LD_LIBRARY_PATH gets set to "`pwd`​:" when there is no existing LD_LIBRARY_PATH in the environment. This confuses the OpenBSD ld.so and thus miniperl is run with /usr/lib/libperl.so instead of the freshly built libperl.so. While I do think that OpenBSD's ld.so should behave reasonably in this case\, [...]

There's a OpenBSD-specific fix in v5.5.640 that might help here. Can you try that version? Thanks.

Sarathy gsar@​ActiveState.com

[p5pRT]

From @millert

In message \200002030321\.TAA25578@​maul\.activestate\.com   so spake Gurusamy Sarathy (gsar)​:

There's a OpenBSD-specific fix in v5.5.640 that might help here. Can you try that version? Thanks.

That's a different bug\, for which I already committed your fix. :-) This one may hit FreeBSD and NetBSD a.out ld.so's too\, so here's the patch I did to fix the problem.

- todd

Index​: shlib.c

RCS file​: /cvs/src/gnu/usr.bin/ld/shlib.c\,v retrieving revision 1.8 diff -u -r1.8 shlib.c --- shlib.c 2000/01/16 14​:31​:26 1.8 +++ shlib.c 2000/02/03 02​:14​:35 @​@​ -80\,7 +80\,10 @​@​   n_search_dirs++;   search_dirs = (char **)   xrealloc(search_dirs\, n_search_dirs * sizeof search_dirs[0]); - search_dirs[n_search_dirs - 1] = strdup(name); + if (*name == '\0') + search_dirs[n_search_dirs - 1] = strdup("."); + else + search_dirs[n_search_dirs - 1] = strdup(name); }

void Index​: rtld/rtld.c

RCS file​: /cvs/src/gnu/usr.bin/ld/rtld/rtld.c\,v retrieving revision 1.15 diff -u -r1.15 rtld.c --- rtld/rtld.c 2000/01/11 22​:27​:07 1.15 +++ rtld/rtld.c 2000/02/03 02​:14​:32 @​@​ -1309\,10 +1309\,12 @​@​   ipath ? ipath : "");

  while ((cp = strsep(&dp\, "​:")) != NULL) { - cp = findhint(name\, major\, minor\, cp); - if (cp) { - free(lpath); - return cp; + if (*cp) { + cp = findhint(name\, major\, minor\, cp); + if (cp) { + free(lpath); + return cp; + }   }   }   free(lpath);

[p5pRT]

From [Unknown Contact. See original ticket]

In message \13497\.949524439@​chthon so spake Tom Christiansen (tchrist)​:

POSIX 1003.2 says that a null path component is considered the cwd.

Yup\, and I have a patch to the OpenBSD ld.so that makes it behave in that manner. Something should get committed in the next day or so. However\, other OS's may get bitten by this as well so I do think it is worth chopping off the extra '​:' in Makefile.SH.

FYI​: 1003.2 was only referring to the shell's behavior on the bin PATH envariable\, not all possible pathish vars.

--tom

[p5pRT]

From @millert

In message \18369\.949578546@​chthon   so spake Tom Christiansen (tchrist)​:

FYI​: 1003.2 was only referring to the shell's behavior on the bin PATH envariable\, not all possible pathish vars.

I understand that\, but I think it makes sense to emulate that behavior. There are two obvious ways to treat an empty element in LD_LIBRARY_PATH a) treat as '.' b) ignore it You could make a case for either one and I'm still a bit undecided which is best.

- todd