Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LD_LIBRARY_PATH should not end in ':' #1113

Closed
p5pRT opened this issue Feb 2, 2000 · 8 comments
Closed

LD_LIBRARY_PATH should not end in ':' #1113

p5pRT opened this issue Feb 2, 2000 · 8 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Feb 2, 2000

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

Searchable as RT2071$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Feb 2, 2000

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
--- 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
Copy link
Author

@p5pRT p5pRT commented Feb 2, 2000

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
Copy link
Author

@p5pRT p5pRT commented Feb 2, 2000

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
Copy link
Author

@p5pRT p5pRT commented Feb 2, 2000

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
Copy link
Author

@p5pRT p5pRT commented Feb 2, 2000

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
Copy link
Author

@p5pRT p5pRT commented Feb 2, 2000

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
Copy link
Author

@p5pRT p5pRT commented Feb 3, 2000

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
Copy link
Author

@p5pRT p5pRT commented Feb 3, 2000

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant