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
Message-Id: <199911021622.KAA06965@mercury.xraylith.wisc.edu>
To: Steve Jorgensen <steve AT khoral DOT com>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: More DLL and global var problems 
In-Reply-To: Your message of "Mon, 01 Nov 1999 17:17:04 MST."
             <199911020017 DOT RAA23148 AT benson> 
Date: Tue, 02 Nov 1999 10:22:10 -0600
From: Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>

Steve Jorgensen <steve AT khoral DOT com> writes:
> 
> 	I managed to get DLL's working on our non-X based
> 	libraries, but I'm having a problem with our X libraries.
> 	Khoros has a large number of it's own widgets, defined in
> 	several different libraries, and though it's in C, 
> 	it's possible to do support basic inheritance via
> 	Xt.
> 
> 	Each widget has a class initializer which is a global
> 	variable.  This initializer is used by subclasses to initialize
> 	the "superclass" part of the variable.  Anyway, the problem
> 	I'm seeing is this.  If the superclass initializer variable
> 	is in a different DLL than the current DLL I'm compiling, I
> 	get the following while compiling:
> 
> Browser.c:174: Internal compiler error, output_operand_lossage `invalid expre
> ssion on as operand'
> {standard input}: Assembler messages:
> {standard input}:1150: Warning: Partial line at end of file ignored
> 
> 	and then it just hangs.
> 
> 	The relevant part of the code is as follows:
> 
> 171:XvwBrowserWidgetClassRec xvwBrowserWidgetClassRec =
> 172:{
> 173:  {
> 174:    (WidgetClass) &xvwManagerWidgetClassRec,
> 	....
> 
> 	The xvwManagerWidgetClassRec is the global variable from the
> 	other DLL, and it is declared with __declspec(dllexport) when
> 	I compile the library containing it, and __declspec(dllimport) when
> 	it is being used by other libraries/applications.  


Due to the design of DLLs, the address of dll imported variable is not
a "constant" pointer, and thus you cannot take the address of it in 
global scope (talking about C, and not C++, here obviously).

I haven't looked at Xt code in years, so may be way off.

I believe Sergey Okhapkin ran into these issues when he was first working 
on X11R6 port, but unfortunately I don't remember what the outcome was.

You can of course always compile these bits with C++, but that may not be
an option for you. The other choice is to use a "constructor function"
(GCC extension), that provides some of the C++ global constructor style
benefit in C.

Or, it could just be a bug in the dllimport/export implementation (there
are one or two outstanding ones that I'll probably never fix simply because 
those require ugly kludges that MS put in their compiler to match their
often kludgy requirements for the whole import/export stuff).

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com