This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
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
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?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html