From: <asb...@gm...> - 2004-12-02 11:07:05
|
Hi,=20 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=F8rn |
From: Luke D. <cod...@ho...> - 2004-12-02 12:44:56
|
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" <asb...@gm...> To: <min...@li...> 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 as a parameter? (--relax-a-little-will-you, maybe?) Thanks in advance for any tips! Asbjørn |
From: <asb...@gm...> - 2004-12-02 13:21:53
|
> Generally speaking, you can't do that, and it's not what DLLs are designe= d > for: normally an executable references functions and/or data inside the D= LL. > Usually the error flag would be defined by the DLL. Apparently Unix is > different. Unix is probably different... :-) =20 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=F8rn |
From: Jonathan W. <jo...@tp...> - 2004-12-02 14:04:02
|
> 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. |
From: Tor L. <tm...@ik...> - 2004-12-03 03:24:05
|
> > 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 export where it actually is defined. If that's in a source file that eventually gets linked into an .exe, you have the additional acrobatics that might be needed to export symbols from an .exe. --tml |