gcc -mno-cygwin still wants to link with cygwin libs

[Peter Amstutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.  I am using the cygwin toolchain with to build a windows native app 
(using -mno-cygwin), but I've run into some library troubles, and I was 
hoping someone could offer some advice.

I have a library, jpeg.lib (and corrisponding dll).  It doesn't depend on 
cygwin and was probably compiled with msvc.

On my gcc link line, I supply -L/path/with/lib which has jpeg.lib.

However, when I look at the dependencies of the resulting binary, I find 
it has linked to cygwin's libjpeg from /usr/lib.  What's going on here?

Having spent an evening groveling over the output of ld --verbose, I have 
determined the cause of my woes, and I'd like to see if anyone has any 
suggestions as for what to do about it.

There are two problems here.

The first problem is that it is looking it /usr/lib at all.  Generally 
speaking, that directory is going to be populated with cygwin libraries, 
not mingw ones.  If you dip into the linker's call to collect2.exe, you'll 
see this:
    -L/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../.. Which, if you disentangle 
that a bit, means it searches in /usr/lib.  Whether this is a bug or not 
is arguable ("broken by design" would seem to be a more accurate 
description), but it is very inconvenient.

However, the real problem is that when ld searches the linker path, it 
seems to do so in several phases, and is the way this search works is 
troublesome.  I should note that it does find files that end it ".lib", 
but only AFTER it has searched the ENTIRE path for files ending in 
".dll.a".  What this means is that "libjpeg.dll.a" from cygwin, although 
at the very end of the search path, is found and matched before 
"jpeg.lib", which is at the very beginning of the search path, but the 
misfortune of having the wrong name and relegated to the second search 
pass.  It is discriminated against.  If I rename "jpeg.lib" to 
"libjpeg.dll.a", it finds the correct link library at the correct 
location.

However, the rub is that this particular link library is intended to be 
used by several different compilers, so I'm trying to avoid having to keep 
multiple copies around to work around this problem just because cygwin 
wants to be special.

On unix this problem would be solved by symlinks.  Which might even work 
here too...  But it is pitfalls like this that drive people to use the 
otherwise horrendous MSYS toolkit, because of the quirks of Cygwin's mingw 
mode.

[   Peter Amstutz   ][ tetron@interreality.org ][ piamstutz@anteon.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)

iD8DBQFEiPn7aeHUyhjCHfcRArmRAJ9TNpgRR4SZ+aSK3mr+ya6WeoG0CQCePvrR
z58GmSpZtUyHyWPPlPot4Ko=
=XUun
-----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/