Mail Archives: cygwin/2003/02/17/10:03:36
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/
- Raw text -