Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <002e01c2d624$36c6cc40$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: <cygwin AT cygwin DOT com>
References: <000001c2d13b$d5c30a40$5c1306d5 AT BRAMSCHE> <02ee01c2d13f$506fbc40$78d96f83 AT pomello> <3E488E18 DOT 1060100 AT ece DOT gatech DOT edu> <3E502A5B DOT 7060408 AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] libtool-devel-20030121-1
Date: Mon, 17 Feb 2003 01:30:54 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Charles Wilson wrote:
> Charles Wilson wrote:
>
>>> I think that in some cases, libtool tries to do too much. I've run
>>> into a number of cases which would have just worked if libtool had
>>> passed the arguments to gcc without modification, but it insists on
>>> filtering
>>> stuff in
>>> complex ways. For example, gcc -print-search-dirs doesn't admit to
>>> searching
>>> /usr/lib/w32api, so any attempt to link with a w32api library when
>>> cross-compiling with -mno-cygwin (which means the Cygwin-specific
>>> hack in libtool.m4 doesn't get activated) fails. Now, admittedly,
>>> gcc is probably wrong in not showing all its search dirs correctly,
>>> but sometimes I wish libtool trusted the compiler more.
>>
>>
>> mebbe. But that's another discussion.
>
> Your larger point is still subject for a (different) discussion, but
> one small issue: a *very* recent patch to libtool CVS allows passing
> arguments to gcc.  so, CC='gcc -mno-cygwin -L/usr/lib/w32api' is okay
> now.  [there was an earlier patch that specifically allowed -mXXXXX
> options; the newer one lets anything go]
>
> However, I tend to just add -L/usr/lib/w32api directly to my spec file
> anyway (although a cross compiler would be subtly different, I know).

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.

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.

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/