This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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() stuff).

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]