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/
