Re: [RFA] [pei-386] prevent ld (auto-import) from generating broken code

[Charles Wilson <cwilson at ece dot gatech dot edu>]

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

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 
limited success:

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.

--Chuck