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
>
>
next prev 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).