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.
I believe there are a few checks for -mno-cygwin already sprinkled around in the code. Wanna submit a patch as outlined above?
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
