Re: cyg*.dll, linking

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 13/12/2011 20:32, Warren Young wrote:
> On 12/13/2011 12:18 PM, Brian Craft wrote:
>> On Tue, Dec 13, 2011 at 11:16 AM, Csaba Raduly  wrote:
>>> On Tue, Dec 13, 2011 at 7:45 PM, Brian Craft  wrote:
>>>
>>>> And why don't I see cyg*.dll files, for example, in /usr/lib?
>>>
>>> They are all hiding under /usr/bin :)
>>
>> Ah! I see. So the install is working fine, I was just adding the wrong
>> directory to PATH, having no idea that libraries would be installed
>> under ${prefix}/bin. :)

  Well, /usr/bin should be on your PATH at all times anyway...

> ...and that is on purpose, because of Windows' DLL search path rules:
> 
>     http://msdn.microsoft.com/en-us/library/7d83bc18.aspx
> 
> If autotools generated Makefiles that installed DLLs in /usr/lib, you'd
> have to add c:\cygwin\lib (or whatever) to the PATH, and then risk being
> sent to DLL Hell by having another DLLs with the same name elsewhere in
> the PATH.

  What he said.  It's a difference between Linux and Windows that we don't try
to hide: on Windows, executables don't contain an rpath (a path pointing to
where the needed shared libraries can be found at runtime) and there is no
equivalent of LD_LIBRARY_PATH for the Windows kernel file loader, so since
DLLs have to go on the PATH we install them to /usr/bin alongside the
executables that need them.  /usr/lib still contains all the static libraries,
import libraries and associated libtool control files as normal though.

  Also, from your original post:

> building. Most of them build via autotools. Doing "make install"
> installs files *.a, *.la, *.dll.a. Linking the executable succeeds
> without error, however when running it, the loader complains that it
> can't find cyg*.dll files. E.g. if it was libfoo.a that was installed,
> the executable wants cygfoo-6.dll to run.
> 
> These cyg-*.dll files exist in the build directories, generally in
> src/.libs . The program will run if I add all of these to the PATH.

  Windows can only find DLLs if they are on the PATH (or in the same directory
as the executable being launched).  Libtool is aware of this: if you look in
your build directory, in the src/ dir just above src/.libs, you'll find
something that looks like your executable but in fact isn't.  The real
executable lives in the .libs subdir too, and the one by the same name in the
main build dir is a wrapper that sets the PATH to include any required .libs
directories and then invokes the real executable in the .libs subdir.

  When you run "make install", libtool copies the real executable into your
/usr/bin dir, the wrapper is no longer required at that point.  (You can
control where the DLLs get installed by passing libtool the -bindir option,
should the default not suit you for any reason; the default is that DLLs go
into ../bin/ relative to the lib/ subdir where the .a and .la files go.)

    cheers,
      DaveK


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