Problems creating "-mno-cygwin" DLLs with libtool.

Dave Korn
Tue Feb 1 18:15:00 GMT 2005

> -----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

> 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!

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list