This is the mail archive of the
mailing list for the binutils project.
Re: [RFA] [pei-386] prevent ld (auto-import) from generating broken code
DJ Delorie wrote:
> I guess there's no easy way to get people to get it right. I would
> still argue for the dllimport path, though, if for no other reason
> than [I'm guessing] it's what MS developers do.
Yeah, but they do it because they don't have any other choice. <g> MS's
link.exe doesn't have anything like your own function-auto-import
capability (virtual on-the-fly import lib), either. But we still use it.
> And the volatile imposes a performance penalty on non-dll cases too,
> trivial though it may be.
Okay, this may be flamebait, but at what point do you balance the
tradeoff between ease-of-porting and performance? In the case of
cygwin, it's solidly on the side of ease-of-porting: a native port of
"foo.exe" would definitely be faster than a cygwin version, but it's
MUCH easier to port "foo" from unix to cygwin than to native-MS.
Since we're talking about libraries, there is a ripple effect.
Requiring strange "extra" defines, coordinating compile-time options
with link-time options....all of these things are possible, but
extremely painful, both for developers and maintainers of these ported
I know, because I maintain about 12 or so "dll-ized" libraries for
cygwin. I've made these kinds of ugly changes to the headers, with only
1) many users are often confused by these interlinked requirements; a
good number of the "bug reports" that I get are due to a
misunderstanding of these issues. (Yes, the requirements are all
fully-documented in cygwin-port-specific README files, but...)
2) most of the package development teams are reluctant to accept the
necessary patches. E.g. the readline patch to enable combined
DLL/static building on cygwin, while maintaining original behavior on
other platforms, is over 200k. The ncurses patch is over 450k. This
has met with understandable resistance. :-)
3) Because of (1) and (2), there are significant problems when packages
include local copies of the source for dependent libraries
(bash-readline, "anything"-gettext, etc.) Since the installed versions
of the libraries' header files differ from these included-source-code
versions, you end up with all kinds of "cross-pollination" problems.
Anything that makes sharedlib/staticlib behavior more "unix-like" is
good -- because the MS model just plain stinks. Anything that
eliminates the need for ugly header file hacks is good, IMO, even at the
expense of a "trivial" performance penalty.