This is the mail archive of the cygwin@cygwin.com 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] |
Max Bowsher wrote:
-mno-cygwin, in other words. So "native" (e.g. MSYS) mingw builds are not affected by this?Neither will work. The compiler is already perfectly happy. libtool decides it knows better, though, and intervenes, breaking the build. I wouldn't worry too much about this now. There's already a hardcoded sys_lib_search_path_spec for cygwin. It only affects building for mingw in a cygwin environment.
That's not so bad. Although, it should NOT use cygwin's sys_lib_search_path_spec -- you'd pull in all of the cygwin-dependent libz's and libncurses's. What you want is to ADD /usr/lib/w32api to the "standard" 'gcc -mno-cygwin' search path. That "standard" path already includes the right gcc runtime directory, and already includes /usr/lib/mingw via some symlinks. You just need to add -L/usr/lib/w32api -- we know that nothing in there is cygwin-dependent.About the only solution I can think of is to test $CC for -mno-cygwin, and use the cygwin sys_lib_search_path_spec if found.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |