Running a program using a DLL under Cygwin

Running a program using a DLL under Cygwin

[Dr Rainer Woitok]

Greetings,

I'm running  a program which requires a DLL  sitting in my "~/bin/" dir-
ectory.  Since "~/bin/" is contained  in my "PATH" environment variable,
everything works  as desired.   Recently I moved  the DLL elsewhere, re-
placing it with a symbolic link in "~/bin/".  This caused the program to
fail to locate the DLL.  Moving the DLL back in place caused the program
to work again.

Is this a Windows problem  (since DLLs are Windows  rather than Unix) or
Cygwin's?   The link was created with the normal  "ln -s" command.  And,
if that matters, Cygwin is running on Vista here.

Sincerely,
  Rainer

PS: Please also reply  to me personally,  as I'm not  subscribed to this
list.

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

Re: Running a program using a DLL under Cygwin

[Yucong Sun]

I think symlink is a cygwin thing.  Windows won't find that DLL (just
like you won't find it using windows explorer.)

Windows only support loading DLL from project directory, or  system32
as far as I know.

On Thu, Oct 8, 2015 at 9:37 PM, Dr Rainer Woitok
<rainer.woitok@gmail.com> wrote:
> Greetings,
>
> I'm running  a program which requires a DLL  sitting in my "~/bin/" dir-
> ectory.  Since "~/bin/" is contained  in my "PATH" environment variable,
> everything works  as desired.   Recently I moved  the DLL elsewhere, re-
> placing it with a symbolic link in "~/bin/".  This caused the program to
> fail to locate the DLL.  Moving the DLL back in place caused the program
> to work again.
>
> Is this a Windows problem  (since DLLs are Windows  rather than Unix) or
> Cygwin's?   The link was created with the normal  "ln -s" command.  And,
> if that matters, Cygwin is running on Vista here.
>
> Sincerely,
>   Rainer
>
> PS: Please also reply  to me personally,  as I'm not  subscribed to this
> list.
>
> --
> 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
>

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

Re: Running a program using a DLL under Cygwin

[Csaba Raduly]

Hi,

On Thu, Oct 8, 2015 at 3:56 PM, Yucong Sun  wrote:

Please don't top-post (https://cygwin.com/acronyms/#TOFU)

> I think symlink is a cygwin thing.  Windows won't find that DLL (just
> like you won't find it using windows explorer.)
>
> Windows only support loading DLL from project directory, or  system32
> as far as I know.

There are rather more possibilities, listed here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get
the path of this directory.
4. The 16-bit system directory. There is no function that obtains the
path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get
the path of this directory.
6. The directories that are listed in the PATH environment variable.
Note that this does not include the per-application path specified by
the App Paths registry key. The App Paths key is not used when
computing the DLL search path.

If SafeDllSearchMode is enabled, the current directory is demoted from
#2 to #5 (just before the PATH search).

There's also SetDllDirectory (
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx
)

>
> On Thu, Oct 8, 2015 at 9:37 PM, Dr Rainer Woitok
> <rainer.woitok@gmail.com> wrote:
>> Greetings,
>>
>> I'm running  a program which requires a DLL  sitting in my "~/bin/" dir-
>> ectory.  Since "~/bin/" is contained  in my "PATH" environment variable,
>> everything works  as desired.   Recently I moved  the DLL elsewhere, re-
>> placing it with a symbolic link in "~/bin/".  This caused the program to
>> fail to locate the DLL.  Moving the DLL back in place caused the program
>> to work again.
>>
>> Is this a Windows problem  (since DLLs are Windows  rather than Unix) or
>> Cygwin's?   The link was created with the normal  "ln -s" command.  And,
>> if that matters, Cygwin is running on Vista here.

If the CYGWIN environment contains    winsymlinks:native
(https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks) ,
Cygwin creates symlinks that Windows can understand. I don't know
whether Windows will load a DLL if a native symlink to the DLL is in
the PATH (or any other directories in the search list).

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Re: Running a program using a DLL under Cygwin

[Andrey Repin]

Greetings, Yucong Sun!

https://cygwin.com/acronyms/#TOFU pretty please...

> I think symlink is a cygwin thing.  Windows won't find that DLL (just
> like you won't find it using windows explorer.)

Unless he have created a Windows symlink, that is correct.
Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.

> Windows only support loading DLL from project directory, or  system32
> as far as I know.

That's not correct. Windows can be told to load DLL's from multiple places,
and you can add to that by registering your DLL in AppPaths registry key.

But a bottom point of the issue is that the OP's project is poorly designed
and needs a rework in the part of finding and loading custom plugins
(I suppose).

There should be no need to move DLL's around, least to place them in a shared
location like user's ~/bin...


-- 
With best regards,
Andrey Repin
Thursday, October 8, 2015 18:08:16

Sorry for my terrible english...


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

Re: Running a program using a DLL under Cygwin

[Linda Walsh]

Andrey Repin wrote:
> Greetings, Yucong Sun!
> 
> https://cygwin.com/acronyms/#TOFU pretty please...
> 
>> I think symlink is a cygwin thing.  Windows won't find that DLL (just
>> like you won't find it using windows explorer.)
> 
> Unless he have created a Windows symlink, that is correct.
> Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.
----
Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native export'
in your 'CYGWIN' env var at startup -- preferably in your Win profile.

However, cygwin occasionally has some bugs in how it creates links:
/tmp> touch x
/tmp> ln -s x y    
/tmp> ll x y
-rw-rw-r--+ 1 0 Oct 10 22:27 x
lrwxrwxrwx  1 6 Oct 10 22:28 y -> /tmp/x
/tmp> cmd /c dir ?|grep '\s[xy]'
10/10/2015  10:32 PM                 0 x
10/10/2015  10:40 PM    <SYMLINK>      y [C:\tmp\x]
/tmp> rm y
/tmp> mklink x y
symbolic link created for y <<===>> x
tmp> cmd /c dir ?|grep '\s[xy]'
10/10/2015  10:32 PM                 0 x
10/10/2015  10:43 PM    <SYMLINK>      y [x]

Normally cygwin can create relative symlinks but for some reason 
using these names -- in /tmp, it did not.

(if I used a name other than 'y' for the symlink like 'winlink' or 'cyglink'
then they both were relative links)

Go figger...


Also, FWIW Cygwin 'hardlinks' are Windows 'hardlinks'.  
No significant difference.

So you could use a windows symlink or hardlink created in cygwin
to the location of your 'dll' and it "should" work (but I haven't
tested it)

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

Re: Running a program using a DLL under Cygwin

[Andrey Repin]

Greetings, Linda Walsh!

>>> I think symlink is a cygwin thing.  Windows won't find that DLL (just
>>> like you won't find it using windows explorer.)
>> 
>> Unless he have created a Windows symlink, that is correct.
>> Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.
> ----
> Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native export'
> in your 'CYGWIN' env var at startup -- preferably in your Win profile.

> However, cygwin occasionally has some bugs in how it creates links:
> /tmp> touch x
> /tmp> ln -s x y    
> /tmp> ll x y
> -rw-rw-r--+ 1 0 Oct 10 22:27 x
> lrwxrwxrwx  1 6 Oct 10 22:28 y -> /tmp/x
> /tmp> cmd /c dir ?|grep '\s[xy]'
> 10/10/2015  10:32 PM                 0 x
> 10/10/2015  10:40 PM    <SYMLINK>      y [C:\tmp\x]
> /tmp> rm y
> /tmp> mklink x y

Do note that native mklink has arguments in the opposite order. (Microsoft...)

> symbolic link created for y <<===>> x
> tmp> cmd /c dir ?|grep '\s[xy]'
> 10/10/2015  10:32 PM                 0 x
> 10/10/2015  10:43 PM    <SYMLINK>      y [x]

> Normally cygwin can create relative symlinks but for some reason 
> using these names -- in /tmp, it did not.

> (if I used a name other than 'y' for the symlink like 'winlink' or 'cyglink'
> then they both were relative links)

> Go figger...

> Also, FWIW Cygwin 'hardlinks' are Windows 'hardlinks'.  
> No significant difference.

Well, it is a difference.
If target of a symlink is deleted and recreated, the symlink will still work.
If a hardlinked file is deleted and recreated, it'll lose the link between the
two.

> So you could use a windows symlink or hardlink created in cygwin
> to the location of your 'dll' and it "should" work (but I haven't
> tested it)

For the purposes of DLL loading, hardlink is probably a good choice.


-- 
With best regards,
Andrey Repin
Sunday, October 11, 2015 17:17:03

Sorry for my terrible english...


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

Problems w/cygsym links vs. winsymlnks: (was Re: Running a program using a DLL under Cygwin)

[Linda Walsh]

Andrey Repin wrote:
> Greetings, Linda Walsh!
> 
>>>> I think symlink is a cygwin thing.  Windows won't find that DLL (just
>>>> like you won't find it using windows explorer.)
>>> Unless he have created a Windows symlink, that is correct.
>>> Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.
>> ----
>> Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native export'
>> in your 'CYGWIN' env var at startup -- preferably in your Win profile.
> 
>> However, cygwin occasionally has some bugs in how it creates links:
>> /tmp> touch x
>> /tmp> ln -s x y    
>> /tmp> ll x y
>> -rw-rw-r--+ 1 0 Oct 10 22:27 x
>> lrwxrwxrwx  1 6 Oct 10 22:28 y -> /tmp/x
>> /tmp> cmd /c dir ?|grep '\s[xy]'
>> 10/10/2015  10:32 PM                 0 x
>> 10/10/2015  10:40 PM    <SYMLINK>      y [C:\tmp\x]
>> /tmp> rm y
>> /tmp> mklink x y
> 
> Do note that native mklink has arguments in the opposite order. (Microsoft...)
---
	Yes... but notice I typed that at a bash prompt and that 
it did the same thing as 'ln -s' and worked with the same order
(mklink = bash-script that wraps around native mklink to make
it same order).  This also has mklink working but 'ln -s'
changing a relative link to a absolute link


	Another example of cygwin's 'ln -s' chainging the link:
---
/tmp> mkdir foo
/tmp> ln -s foo cygfoo
/tmp> mklink foo winfoo
symbolic link created for winfoo <<===>> foo
/tmp> cmd /c dir|grep  foo
10/11/2015  11:23 AM    <SYMLINKD>     cygfoo [C:\tmp\foo]
10/11/2015  11:22 AM    <DIR>          foo
10/11/2015  11:24 AM    <SYMLINKD>     winfoo [foo]
---
looks innocent enough until I mv them:
/tmp> mkdir links
/tmp> mv foo cygfoo winfoo links
/tmp> cd links
/tmp/links> ls
cygfoo@  foo/  winfoo@
/tmp/links> ll
total 0
lrwxrwxrwx  1 8 Oct 11 11:23 cygfoo -> /tmp/foo
drwxrwxr-x+ 1 0 Oct 11 11:22 foo/
lrwxrwxrwx  1 3 Oct 11 11:24 winfoo -> foo/
-----
Notice the cygwin created symlink points to a
non-existing file /tmp/foo. 
 
A 3rd problem is trying to create the links 
before creating the dir.

Not a problem on linux, but on windows, notice above, the
symlinks to directories are a different type
than the ones to regular files.

So, currently the shell wrapper complains, but cygwin
creates a cygwin-only symlink: a hidden 'System' file that
windows can't use and normally doesn't see:

/tmp/links> ln -s foo2 cygfoo2
/tmp/links> mklink foo2 winfoo2
Source, "foo2", does not exist.
  ### uhoh, "forgot" to create foo2 1st, better create it now:
/tmp/links> mkdir foo2
/tmp/links> mklink foo2 winfoo2

/tmp/links> ls *?foo2
cygfoo2@  winfoo2@
/tmp/links> ll *?foo2
lrwxrwxrwx 1 4 Oct 11 12:31 cygfoo2 -> foo2/
lrwxrwxrwx 1 4 Oct 11 12:37 winfoo2 -> foo2/

  ### create files in cygfoo2 and winfoo2 from cygwin:
/tmp/links> touch {cyg,win}foo2/child_file
/tmp/links> ll {cyg,win}foo2/child_file   
-rw-rw-r-- 1 0 Oct 11 13:22 cygfoo2/child_file
-rw-rw-r-- 1 0 Oct 11 13:22 winfoo2/child_file

  ## so cygwin can create a child_file in each, but
  ## win's dir /a?



  ### looks like cygfoo2 is there, as seen on cygwin, above, but a 
  ### dir cmd from win doesn't see it:


/tmp/links> cmd /c dir|grep ' [AP]M'
10/11/2015  12:37 PM    <DIR>          .
10/11/2015  12:37 PM    <DIR>          ..
10/11/2015  11:23 AM    <SYMLINKD>     cygfoo [C:\tmp\foo]
10/11/2015  11:22 AM    <DIR>          foo
10/11/2015  12:35 PM    <DIR>          foo2
10/11/2015  11:24 AM    <SYMLINKD>     winfoo [foo]
10/11/2015  12:37 PM    <SYMLINKD>     winfoo2 [foo2]


  ### attrib/no args shows files with attrs set:

/tmp/links> attrib                     
   S         C:\tmp\links\cygfoo2

  ### dir /a will show also reveal hidden and system files:
  ### this shows diff of cygwin ln -s foo2 cygfoo2
  ###                 and the bash-shell wrapper calling mklink
  ###	              (after 'mkdir foo2')

/tmp/links> cmd /c dir /a *?foo2|grep ' [AP]M'
10/11/2015  12:31 PM                22 cygfoo2
10/11/2015  12:37 PM    <SYMLINKD>     winfoo2 [foo2]

 ## creating files in 'cygfoo2 and winfoo2


> For the purposes of DLL loading, hardlink is probably a good choice.
---
There is one drawback to hardlink usage (if softlink usage doesn't
matter, of course, that's irrelevant).  All copies of a hardlinked
file will be locked if any of them are.

Vs. if you use softlinks, -- the file they point to will
likely be locked, by the symlinks might not be... if that's
the case, symlinks could be repointed at new "dll"'s for
fixes without requiring requiring the current dll's not
be in use.


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