Asbjørn | 2 Dec 12:06 2004
Picon

Linker problem: Using extern int as "global variable" in DLL

Hi, 
Deeply sorry if this is a stupid newbie question

I'm trying to build some DLLs from unix sources and the following
construction causes the linker to complain:

In the DLL sources, an error flag is defined throughout (i.e. in a
common include file) as "extern int error;" which of course means that
one should assume that this is "somebody elses problem", and the
proper definition, initialization & co of the error flag is in the
code that calls the dll. However - the linker complains that that this
is an undefined reference and borks.

Am I missing something here? If this is a simple RTFM, I'd be happy if
someone could point me in the right direction... :-) Is it as simple
as a parameter? (--relax-a-little-will-you, maybe?)

Thanks in advance for any tips!

Asbjørn

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

(Continue reading)

Luke Dunstan | 2 Dec 13:43 2004
Picon

Re: Linker problem: Using extern int as "global variable" in DLL


Generally speaking, you can't do that, and it's not what DLLs are designed 
for: normally an executable references functions and/or data inside the DLL. 
Usually the error flag would be defined by the DLL. Apparently Unix is 
different.

Luke

----- Original Message ----- 
From: "Asbjørn" <asbjorn.berge@...>
To: <mingw-users@...>
Sent: Thursday, December 02, 2004 7:06 PM
Subject: [Mingw-users] Linker problem: Using extern int as "global variable" 
in DLL

Hi,
Deeply sorry if this is a stupid newbie question

I'm trying to build some DLLs from unix sources and the following
construction causes the linker to complain:

In the DLL sources, an error flag is defined throughout (i.e. in a
common include file) as "extern int error;" which of course means that
one should assume that this is "somebody elses problem", and the
proper definition, initialization & co of the error flag is in the
code that calls the dll. However - the linker complains that that this
is an undefined reference and borks.

Am I missing something here? If this is a simple RTFM, I'd be happy if
someone could point me in the right direction... :-) Is it as simple
(Continue reading)

Asbjørn | 2 Dec 14:21 2004
Picon

Re: Linker problem: Using extern int as "global variable" in DLL

> Generally speaking, you can't do that, and it's not what DLLs are designed
> for: normally an executable references functions and/or data inside the DLL.
> Usually the error flag would be defined by the DLL. Apparently Unix is
> different.

Unix is probably different... :-)  
After some research I found that 'ld' allows by default symbols to be
undefined at link time, and  thus no complaints when building shared
libraries on linux - but my problem still persists, as it seems that
the mingw does not agree with me on the issue of letting undefined
symbols be "somebody elses problem"

Asbjørn

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Jonathan Wilson | 2 Dec 15:06 2004
Picon

Re: Linker problem: Using extern int as "global variable" in DLL

> Unix is probably different... :-)  
> After some research I found that 'ld' allows by default symbols to be
> undefined at link time, and  thus no complaints when building shared
> libraries on linux - but my problem still persists, as it seems that
> the mingw does not agree with me on the issue of letting undefined
> symbols be "somebody elses problem"
Windows doesnt work like that.
Unless you define the symbol somewhere in your code or import it from 
another dll via an import library, the linker will complain.
There is no mechanisim within the windows kernel and executable format to 
allow for these symbols. The only way is to define it somewhere in your dll 
or to define it in another dll and import it.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Tor Lillqvist | 3 Dec 04:53 2004
Picon
Picon

Re: Linker problem: Using extern int as "global variable" in DLL

 > > Unix is probably different... :-)  

You presumably mean ELF is different. (ELF is the most common
executable file format on Unix these days. Used on Linux and Solaris,
for instance.) I am sure there are still Unix variants in use that
would barf at what you described.

 > There is no mechanisim within the windows kernel and executable format to 
 > allow for these symbols. The only way is to define it somewhere in your dll 
 > or to define it in another dll and import it.

Well, there are other ways, but they require heavy wizardry. Something
like:

extern int *get_address_of_variable_at_runtime (const char *name);
#define error (*get_address_of_variable_at_runtime ("error"))

and then define that function (in your DLL):
int *
get_address_of_variable_at_runtime (const char *name)
{
  /* Look up the entry point in all modules (the .exe and all
   * currently loaded DLLs). To properly support all Windows versions
   * need to use either the toolhelp API or psapi API. For sample
   * code, look at glib's gmodule/gmodule-win32.c. And yes, you
   * probably want to cache the lookup results here.
   */
}

Even this still requires that the variable in question is marked for
(Continue reading)


Gmane