This is the mail archive of the 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]

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

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?


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]