unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: "Sjoerd van Leent Privé" <svanleent@gmail.com>
To: guile-devel@gnu.org
Subject: Re: [PATCH] Don't augment LD_LIBRARY_PATH (was Re: [PATCH] do not augment environment)
Date: Fri, 05 Oct 2012 11:43:01 +0200	[thread overview]
Message-ID: <506EABA5.8070309@gmail.com> (raw)
In-Reply-To: <87y5jnn8y4.fsf_-_@tines.lan>

Hi Mark,

Just a quick note. Now with GUILE_SYSTEM_EXTENSIONS_PATH, this could be 
very practical when developing a module. However, if a module is already 
present AND is inside SCM_LIB_DIR or SCM_EXTENSIONS_DIR, it would never 
override that situation. I believe there should be a way to be able to 
override the normal behavior.

Regards,
Sjoerd

On 10/03/2012 12:31 PM, Mark H Weaver wrote:
> Hello all,
>
> Here's a preliminary patch to avoid modifying LD_LIBRARY_PATH.
>
> Following Bruce's suggestion, it causes 'sysdep_dynl_link' to manually
> search additional directories if 'lt_dlopenext' fails to find the
> library in the default paths.  However, I took a somewhat different
> approach, and tried to be more careful with regard to portability and
> correctness.
>
> I read the code of libltdl, and mimicked their handling of path
> separators and directory separators, to ensure that this patch will not
> reduce our portability.
>
> I also followed their lead in deciding when to perform a search.  If any
> directory separators are present (even if it's a relative pathname),
> then libltdl does not perform a search.  I used precisely the same
> criterion to decide whether to search additional directories.
>
> So what additional directories does it search?
>
> If GUILE_SYSTEM_EXTENSIONS_PATH is set (even if it's empty), then it
> specifies the additional directories to search.  If it's unset, then the
> default is to search SCM_LIB_DIR and SCM_EXTENSIONS_DIR.
>
> *** Note that this changes the search order in the case where
> GUILE_SYSTEM_EXTENSIONS_PATH is set to a non-empty string.
>
> Currently, a non-empty GUILE_SYSTEM_EXTENSIONS_PATH is passed to
> lt_dladdsearchdir, so it is searched before LTDL_LIBRARY_PATH and
> LD_LIBRARY_PATH, but this patch causes GUILE_SYSTEM_EXTENSIONS_PATH to
> be searched last, to be consistent with the handling of the default
> directories SCM_LIB_DIR and SCM_EXTENSIONS_DIR.  This seems sensible to
> me.  Does anyone see a problem with this change?
>
> This patch also adds robust handling of the case where
> GUILE_SYSTEM_EXTENSIONS_PATH contains more than one path component.
>
> See below for my preliminary patch.  I have not yet tested it carefully.
> It's a context diff, because 'diff' made a mess of the unified diff.
>
> Comments and suggestions solicited.
>
>       Mark
>
>




  parent reply	other threads:[~2012-10-05  9:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-21 23:36 [PATCH] do not augment environment Bruce Korb
2012-10-01  1:13 ` Bruce Korb
2012-10-01  2:38 ` Mark H Weaver
2012-10-01 14:24   ` Bruce Korb
2012-10-01 14:39   ` Bruce Korb
2012-10-01 16:59     ` Mark H Weaver
2012-10-01 18:27       ` Bruce Korb
2012-10-03 10:31   ` [PATCH] Don't augment LD_LIBRARY_PATH (was Re: [PATCH] do not augment environment) Mark H Weaver
2012-10-04 20:37     ` Ludovic Courtès
2012-10-06  2:30       ` Mark H Weaver
2012-10-06 12:36         ` Mark H Weaver
2012-10-07 21:16           ` Ludovic Courtès
2012-10-06 12:42         ` Ludovic Courtès
2012-10-06 14:31           ` Mark H Weaver
2012-10-05  9:43     ` Sjoerd van Leent Privé [this message]
2012-10-05 21:58       ` Mark H Weaver
2012-11-27 22:54     ` [PATCH] Fix library search order and don't change LD_LIBRARY_PATH Mark H Weaver
2012-11-27 22:59       ` Ludovic Courtès
2012-11-27 23:23         ` Mark H Weaver
2012-11-27 23:01       ` Bruce Korb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=506EABA5.8070309@gmail.com \
    --to=svanleent@gmail.com \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).