www.delorie.com/archives/browse.cgi | search |
O.K. Looks like I finally got by this. The culprit looks to be gcc-2.95.2-2 (release 2) One last time, here's the situation: Assume that there exists a module called MY.c that contains an eclectic mixture of C & ObjC source. I then attempt to create both a relocatable DLL and a static library around this module. The DLL to be used by non-cygwin Apps, the .a to be used by cygwin Apps. To further clarify: the static (.a) library here is NOT an import library for the DLL, its a separate & wholly individual FULL STATIC binary representation of the same source module MY.c ... And here's the final scorecard: 1st scenario: gcc-2.95.2-2 + latest/binutils = good MY.dll BUT X.exe -lMY.a link fails . 2nd scenario: gcc-2.95.2-2 + release/binutils = bad MY.dll BUT X.exe -lMY.a links O.K. . 3rd scenario: (USABLE ONE) gcc-2.95.2 + latest/binutils = good MY.dll AND X.exe -lMY.a links O.K. This seems somewhat of an aberration because it only seems to happen with 1 of my half a dozen or so libary modules. But I'm fairly certain that since gcc-2.95.2-2 is the future, we haven't seen the last of it. When I get more time, I will try to drill down deeper to unearth the exact cause, but I'd bet even money that my skillset in this area is such that I could easily burn a week - so for now I need to get back to "direct-paying" work. later, bisk -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |