Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Thu, 26 Aug 1999 13:30:13 +0400 From: Paul Sokolovsky X-Mailer: The Bat! (v1.32) UNREG / CD5BF9353B3B7091 Reply-To: Paul Sokolovsky X-Priority: 3 (Normal) Message-ID: <12562.990826@is.lg.ua> To: Mumit Khan , James Stern CC: cygwin AT sourceware DOT cygnus DOT com Subject: Re[2]: Importing a variable from a DLL In-reply-To: <199908260629.BAA15928@mercury.xraylith.wisc.edu> References: <199908260629 DOT BAA15928 AT mercury DOT xraylith DOT wisc DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Mumit, Mumit Khan wrote: MK> There is no silver bullet, sorry. [] MK> Functions are trivial to handle via thunks (via import MK> libraries created by dlltool or implib or some such tool); MK> it's the variables that you have to worry about, which have MK> no traditional way to "fix up" in the DLL model. But at least there might be achieved proper diagnostics of such issues, if dlltool would correctly mark data symbols in def, that implib would only contain __imp_ and not , and we'd get link error when linking with object which doesn't have __declspec(dllimport) on that symbol, and not runtime segfaults, as we have now. MK> You'll just have to deal with it. MK> I know of one case where the developers talked about writing MK> a custom PE loader to deal with this (at the expense of MK> compatibility of existing tools), but that project never saw MK> daylight outside of the South Bay cafes. It would be better just use ELF and forget about all the gore. But rules defined by others. MK> Bearer of bad news, MK> Mumit Best regards, Paul mailto:paul-ml AT is DOT lg DOT ua -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com