guile-user
[Top][All Lists]
Advanced

[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>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]