[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 1.6.0 problems with libguilereadline-v-12 and fix
From: |
Greg Troxel |
Subject: |
Re: 1.6.0 problems with libguilereadline-v-12 and fix |
Date: |
19 Sep 2002 09:43:44 -0400 |
I'll try to step back and take a broader look - there are multiple
issues here.
1) 'Shared libraries' and guile's dlopening of libguilereadline-v-12
are not the same thing. A normal usage of a shared library
involves link-time binding of the library to the binary.
For example, the guile binary refers to libguile.so.15 and
libltdl.so.4.
The search paths for resolving these libraries at run-time is given
by '-R' linker options, at least on BSD. Thus, these libraries can
be found in the appropriate place at runtime without having to set
environment variables.
Further, I believe that programs linked against different versions
of libguile.so.15 will each find the right one, due to the
differing -R options at link time.
dlopening does not use this link-time binding. (perhaps on NetBSD
the -R values are being used by dlopen
2) On BSD ELF systems, it is my opinion that having to have set
LD_LIBRARY_PATH is a sign of underlying brokenness. I have not had
to do this other than guile. So it's a warning sign that guile
seems to require setting this variable.
3) Stepping back from shared library issues and assuming we have
infinitely wonderful support, consider the correct behavior. Guile
installs a bunch of .scm files and a bunch of .so files that
libguile uses for various purposes. The guile installation is a
complete set, and it doesn't make much sense to mix and match files
between installations. If one has multiple copies of 1.6 (perhaps
some hacked up in various ways) installed, each guile binary in
/usr/guile16-foo/bin should get the corresponding
/usr/guile16-foo/share/guile/1.6.0/ice-9/*.scm and
/usr/guile16-foo/lib/libguilereadline-v-12 dynamic object
(similarly for /usr/guile16-bar). Looking anyplace else for this
shared object, like /usr/bin, or /usr/local/bin, is simply the
wrong thing to do - the build did not put it there and any such
files are either cruft or part of a different build of guile. It
would be equally broken to link in
/usr/lib/libguilereadline-v-12.so as it would be for
/usr/guile16-foo/bin/guile to read ice-9 stuff from
/usr/share/guile/1.6.0/ice-9.
(One can argue for looking for modules in other places, but that's
a different story from things that are "part of guile").
I don't understand the notion of prepending $(libdir) to the search
path as the right answer; this will still look in other places, and
I think it is incorrect to even try those other places for files
that are part of guile.
4) Setting LD_LIBRARY_PATH can't work in general. If one had two
guile installations in /usr/guile16-{foo,bar}, one of the lib dirs
has to come first. The other installation will dlopen the wrong .so
files.
5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations. Guile
should not foreclose this option.
In general, I think the -R concept for shared libraries has been a big
win - library locations get bound into the dynamic executable, rather
than having system changes over time cause libraries in different
directories to get loaded. So I freely admit that this biases my opinions.
If one accepts my point 3, then it follows that guile should try to
dlopen libguilereadline-v-12.so from _exactly one place_, the place
where the guile build put it. So I argue that using any sort of
search path is incorrect for these objects.
Thus, I think we need a new procedure that takes an absolute pathname
of a .so and dlopens it without doing any search operations, and
should call that with the libdir value from the build-time
configuration. Passing the absolute path to the current procedure
appears to more-or-less do this, although it might search for
/usr/lib/usr/foo/lib/libguilereadline-v-12. With this absolute-path
scheme, guile and guile-using-applications will work correctly without
needing to set any environment variables.
It looks like libltdl:try_dlopen needs only to check if the first
character is / and then not do the searching steps in order to fully
implement the above scheme.
I don't think there are any downsides to the try-exactly-one-place
approach, other than perhaps having to modify libltdl to really
implement it. AFAIK, guile already does not support the notion of
putting the bits in other than the prefix they were built for.
Greg Troxel <address@hidden>
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, (continued)
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/20
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Arno Peters, 2002/09/19
Re: 1.6.0 problems with libguilereadline-v-12 and fix,
Greg Troxel <=
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Rob Browning, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Rob Browning, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/19
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Rob Browning, 2002/09/19
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Greg Troxel, 2002/09/20
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Greg Troxel, 2002/09/20
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Rob Browning, 2002/09/20
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/20
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Rob Browning, 2002/09/20