This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
- From: Max Bowsher <maxb at ukf dot net>
- To: Charles Wilson <cwilson at ece dot gatech dot edu>
- Cc: cygwin at cygwin dot com
- Date: Mon, 17 Feb 2003 10:09:24 +0000 (GMT Standard Time)
- Subject: Re: [avail for test] libtool-devel-20030121-1
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
> > 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)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html