Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
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 18:02:13 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Mailer: The Bat! (v1.32) S/N 34D3AC61
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Priority: 3 (Normal)
Message-ID: <13751.990826@is.lg.ua>
To: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>,
        Anders Norlander <anorland AT hem2 DOT passagen DOT se>,
        James Stern <jsternitg AT yahoo DOT com>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re[4]: Importing a variable from a DLL
In-reply-To: <199908261340.IAA16633@mercury.xraylith.wisc.edu>
References: <199908261340 DOT IAA16633 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 <khan AT xraylith DOT wisc DOT EDU> wrote:

MK> Paul Sokolovsky <paul-ml AT is DOT lg DOT ua> 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_<symbol> and not <symbol>, 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> Sure, but it doesn't solve James' problem. If James could create the
MK> import libraries with all the data marked DATA, it would imply he
MK> already *knows* which these data items are!

    I am still feeling misunderstood. Let me go with it once again,
with examples.

    So, dlltool has ability to create implib from def - it's all nice
with it, it supports DATA, sure.

    But it has ability to dump all defined symbols into def file -
about this operation I am talking. So, suppose we have library of

---a.h
extern int data;
int code();
----
---a.c

int data;

int code()
{
  return 0;
}
----

    We compile a:
gcc -c a.c

    And now creating def of it:

dlltool a.o --export-all --output-def a.def

    What we now get is:
---a.def
; G:\GCC-2.95\BIN\DLLTOOL.EXE --export-all --output-def a.def a.o
EXPORTS
        data @ 1 ;
        code @ 2 ;
----
and it's bad! Suppose we'd get instead
---a.def
; G:\GCC-2.95\BIN\DLLTOOL.EXE --export-all --output-def a.def a.o
EXPORTS
        data @ 1 DATA;
        code @ 2 ;
----

    We create implib from that:

dlltool --def a.def --ouput-lib liba.a

And then compile client application:
---client.c
#include "a.h"

int main()
{
  data=1;
}
----
When we link it

gcc client.o -la

What we get? Of course, "client.c: undefined reference to `data'"!
We now grepping, finding out that 'a.h' declares that 'data' and tag
it __declspec(dllimport). Repeat while needed.

   So, it doesn't solve problem we're talking about automagically, but
it defines clean procedure, which, while being incremental, will
converge fast. Much faster than having to catch segfaults for hours
and then having users complain of occasional ones for months, as we
have now.



MK> Regards,
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