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 Message-Id: <199908261340.IAA16633@mercury.xraylith.wisc.edu> To: Paul Sokolovsky , James Stern , cygwin AT sourceware DOT cygnus DOT com Subject: Re: Re[2]: Importing a variable from a DLL In-Reply-To: Your message of "Thu, 26 Aug 1999 13:30:13 +0400." <12562 DOT 990826 AT is DOT lg DOT ua> Date: Thu, 26 Aug 1999 08:40:42 -0500 From: Mumit Khan Paul Sokolovsky writes: > > 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. Sure, but it doesn't solve James' problem. If James could create the import libraries with all the data marked DATA, it would imply he already *knows* which these data items are! Once you know, one tricky part of porting a legacy application over -- after this, it's a matter of searching for the symbol names and attaching dllimport attribute in user code. However, your point is well taken that we should go and fix dlltool. I believe I did fix it locally at one point, but definitely didn't submit the changes (don't remember why, perhaps it didn't work). Contributions welcome of course. > It would be better just use ELF and forget about all the gore. > But rules defined by others. Welcome to real life. Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com