Mail Archives: cygwin/1999/11/02/11:22:57
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
- Raw text -