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

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:
Bug reporting:

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