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
From: Steve Jorgensen <steve AT khoral DOT com>
Message-Id: <199911022027.NAA23973@benson>
Subject: Re: More DLL and global var problems
To: khan AT thor DOT xraylith DOT wisc DOT edu (Mumit Khan)
Date: Tue, 2 Nov 1999 13:27:55 -0700 (MST)
Cc: cygwin AT sourceware DOT cygnus DOT com
In-Reply-To: <199911021622.KAA06965@mercury.xraylith.wisc.edu> from "Mumit Khan" at Nov 2, 99 10:22:10 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Mumit Khan wrote
>> 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).


	Does anybody remember what the fix was for the X11 port?  I know
	it must have been fixed, because our base Manager widgets subclasses
	off an Xt Constraint widget, and the compiler doesn't have
	any problem with using the global variable from the Xt dll.

	If I have to, we'll leave our compiled X libraries static.

	Also, I'm using the GNU pro 2.9-cygwin-990830 gcc compiler
	that comes with the 1.0 CD, because it's supposed to produce
	better binaries.  Would it make any difference to use the gcc 2.95
	compiler available off the net?  I'd be willing to switch if it
	fixes this problem.

						Steve

-- 
-----------------------------------------------------------
Steven Jorgensen      steve AT khoral DOT com	    steve AT haunt DOT com
------------------------------+----------------------------
Khoral Research Inc.          | PHONE: (505) 837-6500
6200 Uptown Blvd, Suite 200   | FAX:   (505) 881-3842
Albuquerque, NM 87110         | URL: http://www.khoral.com/
-----------------------------------------------------------

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