Mail Archives: cygwin/2011/12/14/09:39:43
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,TW_YG
|
X-Spam-Check-By: | sourceware.org
|
Message-ID: | <4EE8B4F5.8050900@gmail.com>
|
Date: | Wed, 14 Dec 2011 14:38:45 +0000
|
From: | Dave Korn <dave DOT korn DOT cygwin AT gmail DOT com>
|
User-Agent: | Thunderbird 2.0.0.17 (Windows/20080914)
|
MIME-Version: | 1.0
|
To: | cygwin AT cygwin DOT com
|
Subject: | Re: cyg*.dll, linking
|
References: | <CAGVbXL7YGp-WsEx4QooOCX_44GB2gx_C5hNBKkGbXXT_y3zTEg AT mail DOT gmail DOT com> <4EE7987B DOT 8030208 AT cs DOT utoronto DOT ca> <CAGVbXL6772ds2XcDyJuz9PB76h4Crv_S1RmgF3RATcqcvTm_zA AT mail DOT gmail DOT com> <CAEhDDbAdmFF4Ho522q2Y82wiRHzG9BW6uwWbQv7kKLaLf5oFSA AT mail DOT gmail DOT com> <CAGVbXL51st2a++pHpkHRVYuJsJ1n7HyhQNSxta0rA260sAGi6A AT mail DOT gmail DOT com> <4EE7B669 DOT 8030707 AT etr-usa DOT com>
|
In-Reply-To: | <4EE7B669.8030707@etr-usa.com>
|
X-IsSubscribed: | yes
|
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
|
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
- Raw text -