X-Spam-Check-By: sourceware.org Date: Fri, 9 Jun 2006 11:02:06 -0400 (EDT) From: Peter Amstutz To: cygwin AT cygwin DOT com Subject: Re: gcc -mno-cygwin still wants to link with cygwin libs In-Reply-To: <4488FFB5.6D34649@dessent.net> Message-ID: References: <4488FFB5 DOT 6D34649 AT dessent DOT net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 8 Jun 2006, Brian Dessent wrote: > The search order is documented: > -to-a-dll-527>. I think the only thing it says about search order that is relevant here is that it searches for shared libraries before static ones. > My advice is just specify the filename of the library directly, without > flags, e.g. "/path/to/file.lib" and don't try to use -L or -l. There > should be zero ambiguity if you do this. The real problem is that I'm trying to fit this into someone else's established cross-platform build system, so changing it is inconvenient without a very good reason. > Frankly I'm surprised that ld ever finds a file named foo.lib when you > specify -lfoo. Cygwin's gcc is a part of the gnu toolchain and tries to > follow the same file naming conventions that the gnu toolchain uses on > all platforms. And in that convention libraries end in .a. It is most > certainly not "just being special". You're trying to put a square peg > in a round hole mixing -lfoo and files named .lib, and I'm not surprised > that it doesn't work in ways that make sense. > > You might as well ask Microsoft why their linker's default search rules > won't ever find an import library named ".dll.a" and see what their > response is. The problem is not so much that it allows files named ".lib" or not, but that it is being a little bit inconsistant -- it *is* an import library for a DLL, and by all rights it should be matched on the first pass where it is looking for DLLs. Instead, the ".lib" is only matched on the second pass, when it is looking for static libraries. I would be just as happy if it didn't match files named with ".lib" because that would at least force the issue. What's tripping me up here is simply that it isn't doing what I would expect it to do. And I suppose short of patching the linker, there isn't really anything that can be done about it. But to reiterate, it is quirks like this -- not major problems, just quirks -- that make compiling native apps -mno-cygwin harder than it should be. (The requirement that you pass --target i386-mingw32 to "dllwrap" was another one that I got stuck on, shouldn't that be implied by -mno-cygwin on the command line?) Ultimately I think I have solved my problem with the workaround of creating a symbolic link from "foo.lib" to "foo.dll.a" -- this works very nicely. I had not realized that cygwin could emulate symlinks on Windows until now. [ Peter Amstutz ][ tetron AT interreality DOT org ][ piamstutz AT anteon DOT com ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEiY1yaeHUyhjCHfcRAtCJAJ9bgqOPt0RAdeJyISyjmiIJyyJMaACeLm4Y 7pxOOyFqG0RMZgWgy9HyUWk= =Eeyh -----END PGP SIGNATURE----- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/