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: <199911021622.KAA06965@mercury.xraylith.wisc.edu> To: Steve Jorgensen 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 Steve Jorgensen 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