X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=YE+uuBofwuIs8rcli/KQz9OqF+Oj
	3pX8YzNswwxr+4lSbQFZW6+ym1eXjszyPO5kxARN3DLJPE3vjnyYGzmyIjkOQABF
	4ANHJuKf9PQ1/MUzXYlk1eeHVtSflGHQaeVFrrpxrlS3Yc50/G0o2KaBZTgwRa/R
	KkU7JcrYlx02CqI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=ceW5SIQQ5OFJWLaOPz+u0XVrnBI=; b=oL
	G+Qe1vCQ9cfEtnV3m7Ns/20JR/0McJn3Z6Srq+6nUxa2aWCeAO6t3teUGVzlrAGG
	/OOSpHLMJvjnowP90avOYdFaKK52xGE5/K4w5SSXHnRgWOculPxE61PC8x1RIEuZ
	qlI0nMwD8tncWLZAIbFFnHblfR9Sk2/goqjB6LpSQ=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-HELO:	smtp5-g21.free.fr
Mime-Version:	1.0 (Mac OS X Mail 8.0 \(1990.1\))
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
From:	Denis Excoffier <cygwin AT Denis-Excoffier DOT org>
In-Reply-To:	<20141025144934.GB30397@calimero.vinschen.de>
Date:	Sat, 25 Oct 2014 19:29:47 +0200
Message-Id:	<C5ABF401-5848-4C24-BDA0-C6EA98B3BC97@Denis-Excoffier.org>
References:	<announce DOT 20141022092323 DOT GH32374 AT calimero DOT vinschen DOT de> <A0FD00D9-6DFB-4E3D-9FDE-44BC1CAAEEDC AT Denis-Excoffier DOT org> <20141024110209 DOT GJ20607 AT calimero DOT vinschen DOT de> <25D5C8B8-57B7-449C-95C6-CD9055816B6B AT Denis-Excoffier DOT org> <20141024193638 DOT GO20607 AT calimero DOT vinschen DOT de> <544AB396 DOT 5060300 AT t-online DOT de> <09092535-826E-4995-94E8-B4AF3E4F5089 AT Denis-Excoffier DOT org> <20141025111016 DOT GA30397 AT calimero DOT vinschen DOT de> <20141025144934 DOT GB30397 AT calimero DOT vinschen DOT de>
To:	cygwin AT cygwin DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id s9PHU6uj002130

On 2014-10-25 16:49, Corinna Vinschen wrote:
> 
> On Oct 25 13:10, Corinna Vinschen wrote:
>> On Oct 24 23:17, Denis Excoffier wrote:
>>> 2014-10-24 22:16, Christian Franke wrote:
>>>> Another possible solution:
>>>> Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
>>>> 
>>>> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
>>>> else if set to ".", do nothing.
>>>> else call SetDllDirectory(CYGWIN_DLLPATH);
>>>> 
>>>> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
>>> I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
>>> do the job.
>>> 
>>>> 
>>>> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
>>> Also perhaps you can use yet another subitem in the CYGWIN environment variable?
>> 
>> If AddDllDirectory works without much hassle, which I have to test first,
Doesn't the "(>= Win8)" (a few lines before) prevent this scenario from working with XP SP3?
>> why introduce CYGWIN_DLLPATH or another CYGWIN item?
>> 
>> LD_LIBRARY_PATH would be the one we want then, wouldn't it?
> 
> One really big problem with AddDllDirectory is this:  While you can add
> multiple directories to the search path, the order in which these
> directories are added does not specify a search order.  In fact, the
> order in which the paths are searched is unspecified per MSDN.
> 
> In Denis example that means, if we add /usr/bin and /my/dir/bin to the
> DLL search path, Denis case works or it doesn't, and we never know when
> it will work and when it won't, and we have no way to influence this.
> Oh boy.
> 
> Apart from SetDllDirectory and AddDllDirectory, what about this very
> simple solution in Cygwin:
> 
> - Don't call SetDllDirectory at all, thus "." is kept in the search
>  path.
> 
> - In execve, when creating the Windows environment for the child process,
>  check if $PATH is empty.  If so, set $PATH to /bin for the child.
>  Or, check if /bin is in $PATH, if not, add it.
Then you may add it at the beginning. People that would want it at the end (or
elsewhere) can insert it explicitly. Also make sure to consider /usr/bin and /bin
as being equivalent here.

However, modifying PATH behind the scenes may be considered as an unexpected
intrusion by the user (PATH is for user consumption isn't it?). Aren't there
any legitimate scenarios where the user would omit /usr/bin from the PATH?

Is it possible to SetDllDirectory("/usr/bin") only if /usr/bin is _not_ in PATH?
This would be less intrusive.
> 
> That would catch both problems, backward compatibility with Denis
> scenario, as well as the PATH setting in postfix.
This corresponds to my current patched cygwin1.dll (where i commented out 2 lines
in cygheap.cc, see previous messages), since i keep /usr/bin in PATH.

Denis Excoffier.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -