[avail for test] libtool-devel-20030121-1

[Charles Wilson]

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?

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

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