This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]