Mail Archives: cygwin/2005/02/01/13:16:10
> -----Original Message-----
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 01 February 2005 17:27
> Has it been established that the cygwin version of libtool is *supposed*
> to handle mingw? I'd be rather surprised if that was a goal.
Nope, I just assumed that it could be made to do so, and possibly quite
easily. After all, the cygwin version of gcc is supposed to handle the
-mno-cygwin switch. Yes, I understand it's not responsible for implementing it,
that it's just a flag that tells it to hand off to another compiler, but at the
same time it (IIUIC) shouldn't pass "-lcygwin" to the mingw compiler and it
would be a bug in the cygwin gcc (to be precise in the specs file) if it did.
So I figured by the same reasoning as the cygwin-gcc compiler should still
process command-line options intelligently even when it's only passing them on
to mingw-cc1 and getting out of the way, there's no reason why cygwin-libtool
can't try to DTRT too. It's perhaps mildly inconsistent/anomalous if gcc is the
only part of the toolchain that's cygming-special and the rest is completely
ming-agnostic.
> OTOH, I never have understood why tools insist on including such things as
> "-lcygwin" or "-lc" on a linker command line.
NIH syndrome I would have thought - the old "well, if we control it *all*,
it'll be easier to get right" fallacy.
[Offtopic sidenote on software engineering 'best practice'] Of course, it's
_actually_ a whole lot easier to get things right when you let the tools (that
understand what flags they need) set those same flags. Don't second-guess your
compiler! Don't duplicate knowledge in more than one place! Delegate authority
and *trust* your delegates to get it right!
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -