On Mon, 17 Feb 2003, Charles Wilson wrote: > Max Bowsher wrote: > > > > > 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. > > -mno-cygwin, in other words. So "native" (e.g. MSYS) mingw builds are > not affected by this?
I wouldn't know. I'm too happy with the Cygwin environment to bother trying! > > 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. > > 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. > > I believe there are a few checks for -mno-cygwin already sprinkled > around in the code. Wanna submit a patch as outlined above? Why not? As soon as I have some free time :-) (Maybe in a couple of weeks or so) Max. -- 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/
