This is the mail archive of the
mailing list for the Cygwin project.
gcc -mno-cygwin still wants to link with cygwin libs
- From: Peter Amstutz <tetron at interreality dot org>
- To: cygwin at cygwin dot com
- Date: Fri, 9 Jun 2006 00:32:55 -0400 (EDT)
- Subject: gcc -mno-cygwin still wants to link with cygwin libs
-----BEGIN PGP SIGNED MESSAGE-----
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
-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
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
[ Peter Amstutz ][ firstname.lastname@example.org ][ email@example.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)
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html