This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
- From: Denis Excoffier <cygwin at Denis-Excoffier dot org>
- To: cygwin at cygwin dot com
- Date: Sat, 25 Oct 2014 19:29:47 +0200
- Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
- Authentication-results: sourceware.org; auth=none
- 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>
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
> - 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple