This is the mail archive of the
mailing list for the Cygwin project.
Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: cygwin-patches at cygwin dot com
- Date: Mon, 02 Dec 2002 11:31:15 -0500
- Subject: Re: --enable-runtime-pseudo-reloc support in cygwin, take 3.
Two issues: (1) the licensing "problem", (2) the advisability of mingw
pseudo-reloc. Item (2) here, item (1) in an earlier message.
One thing that does worry me, though, is the more we rely on special
runtime tricks and hackish pei-x86 "extensions", the more fragile the
whole system becomes. And the easier it is for MS to (deliberately, or
accidentally) wreck the whole house of cards.
Not to mention the fact that mingw DLLs are quickly becoming unusable
with non-gcc. *I* don't care, but I wonder if the mingw folks are
thinking about this problem: is it really advisable to use auto-import
and runtime-pseudo-reloc and link-directly-to-dll(as long as you have
the fancy GNU linker) so much? It ghettoizes mingw. (cygwin is already
ghettoized; we're used to it: cygwin dlls can be linked-against only
when using cygwin tools)
In other words, the more frequently these special GNU linker features
are used by the mingw folks, the more often the resulting libraries will
be unusable by other compilers (MSVC). DLLs will ONLY be linkable by
mingw-ld. Folks will take advantage of the nice mingw-ld, and stop
porting libraries the MSVC way -- no more declspec(__dllimport__) etc --
which means that libraries will gradually be compilable on windows ONLY
if mingw is used, and not if MSVC (which still requires the declspec()
Is this a direction mingw wants to go?
(Except for the fragility argument (Windows ain't done 'til cygwin won't
run) this doesn't affect cygwin; it's a mingw concern only. )