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

["Max Bowsher" <maxb at ukf dot net>]

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/