Re: 1.6.0 problems with libguilereadline-v-12 and fix

[Marius Vollmer <mvo@zagadka.ping.de>]

Greg Troxel <gdt@ir.bbn.com> writes:

> 1) 'Shared libraries' and guile's dlopening of libguilereadline-v-12
>    are not the same thing.

Can't we make them the same?  That would simplify things, I'd say.

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

How does dlopen behave on BSD?  Does it honor the -R linker options?
Can we do the same in ltdl_dlopen?

>    dlopening does not use this link-time binding.  (perhaps on NetBSD
>    the -R values are being used by dlopen

Could you try to find out?

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

I don't agree that this is a sign of brokeness.

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

It sounds convincing to me to do away with library searching
completely.  However, this doesn't seem to be the way the current
system works.  Debian appearantly even has a policy against using '-R'
or equivalent.

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

This is not a typical situation I think.  If you need to have two
mutually incompatible hacked versions of a single Guile release on
your system, and have them active at the same time, you need to hack
one of them to use different major versions for its libraries, or
different library names.

Alternatively, you could have scripts that setup the environment for
one of the two hacked versions, like so

  $ cat with-guile-env
  #! /bin/sh
  prefix=$1; shift
  PATH=$prefix/bin:$PATH LD_LIBRARY_PATH=$prefix/lib:$LD_LIBRARY_PATH exec "$@"

that you would use as

  $ with-guile-env /usr/guile-16-foo guile
  
> 5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations.  Guile
>    should not foreclose this option.

Good point.  Off hand, I would say that a setuid program should use a
Guile that works without LD_LIBRARY_PATH, for example, one installed
in /usr.

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

Yes, we should do this checking.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user