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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=d8ZI1fHIcFIZN47fV9hjnWhu8t9AaLrvCPyrxUFY/Tw
	IRtF9oDcYVcS5NLWNmtAKwKuz7dxKwFtt1lNqn+6F4Nlj45liRC1P+vQVy5+qfr2
	pEh2gJHPtP302mmefi7VByuen7ZF4SpB1UtGlld87D/g3f0u6vRVZQ34ol7S3sOg
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=kdubRuvniYh0apssSfapGyDj2nQ=; b=sTHtVJQt6W05dv56B
	komKIfwJofns+c+kyAIg/F85pLxq467oHIQvmeGCPQBvaT0rKyBCqCsnZ+n8f+j/
	43OEDGpXlrS0jd/D6jdZ8OFh9sN9etF5zOE4xNt3V6eK8eSn64tAn6zI+A/EjFiY
	v5LdqTfZkJBmk4EF4VCqns9Wrg=
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.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: mailout12.t-online.de
Message-ID: <544DE6C3.3080005@t-online.de>
Date: Mon, 27 Oct 2014 07:31:31 +0100
From: Christian Franke <Christian DOT Franke AT t-online DOT de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
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>
In-Reply-To: <20141025144934.GB30397@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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,
>> 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.
>
> That would catch both problems, backward compatibility with Denis
> scenario, as well as the PATH setting in postfix.

OK for me. For postfix, the '$PATH is empty' check would be sufficient.

Christian


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