From: roger AT isp DOT uni-kassel DOT de (=?iso-8859-1?Q?Roger_Ren=E9_Kommer?=) Subject: Troubles with DLL's 16 Feb 1998 10:30:07 -0800 Message-ID: <01bd3b03$4cbdf4e0$60040d8d.cygnus.gnu-win32@ROGKOMUN> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Hi, I’m playing around with dll’s, but received several troubles with static and global data defined in the dll. In a little less complex situation (only one dll or without the static data), the binaries works like expected. If I build a dll with several static data in multiple o files, the linker produce garbage. Simple static char *text = “hello static text”; points to nirvana (not exactly to nirvana, but somewhere before or below the correct offset in the data segment, where I can find the string “hello static text”. Dllfile.c: static char *text = “hello static text”; /* or without static, same situation*/ void foo() { /* produces in some cases a SIGSEGV */ printf(“text inside dll: %s\n”, text); } I’m not sure, but I guess, this only happens if a dll must be relocated. In some simple situation it works, but in more complex situation, especially, if one dll links to another dll, and both using static/global data, there is something went wrong. Another problem is, that I haven’t found any way to export data (like function entries). In VC it works like this: Dllfile.c: __declspec(dllexport) char *dll_data = “Hello”; __declspec(dllexport) int afunc() { printf(“dll_data inside dll: %s\n”, dll_data); /* this may produces a SIGSEGV */ } __declspec(dllexport) char *get_dll_data() { return dll_data; } exefile: __declspec(dllimport) char *dll_data; __declspec(dllimport) int afunc(); __declspec(dllimport) char *get_dll_data(); int main() { /* this is OK in simple constellations */ printf(“data from dll via get_dll_data(): %s\n”, get_dll_data()); /* following do not work with gnuwin32! */ printf(“data from dll: %s\n”, dll_data); return 0; } I can add the symbol dll_data to the EXPORT section of the dll.def (Makefile.Dll does it by default) and it will also appears as an exported symbol (I’, used quickview looking what symbols are really exported), but gdb claims, that the address of pointer used in the exe is ‘out of bounds’. Same situation, if I use Makefile.Dll and/or the linker/dll from B18-patched-link-compat-ld.tgz. I’ve also had a look into the sources of dlltool, where another possibility to export symbols is mentioned: Copied from dlltool.c: Example: file1.c: asm (".section .drectve"); asm (".ascii \"-export:adef\""); adef(char *s) { printf("hello from the dll %s\n",s); } This neither works for exported data nor for function entry points. (there is following note in the dlltool.c: /* FIXME: The 5th arg is for the `constant' field. What should it be? Not that it matters since it's not currently useful. */ What this means?) Actually what I’m miss is a documentation of ld and dlltool. There is a manpage for ld, but the specific details for building a dll are missing. I’ve also tried to use LINK.EXE from VC5.0 to create a dll, but there are unresolved symbols (__bss_start__, __bss_end__, __data_start__, __data_end__). I’ve also tried to use the VC5.0 compiler, but although it links the stuff, the executable doesn’t run properly. Actually I’ve tried to follow all suggestions, I found here in the mailing list and WWW, but none of them (patched, ld, dlltool, etc. from B18-patched-link-compat-ld.tgz; Makefile.Dll, different versions of coolview, cygwin) works. The background: I’ve tried to compile the lesstif library dynamically. First I have to figure out, that it will not work with a static linked Xt, because the some basic data structure will be duplicated in the Xm library and the exe (i.e. mwm.exe). I have successfully compiled the Xt library as shared dll (needs some modifications, exporting data Structures (Window classes) via functions, but in a correct environment it should also work without this modifications), but the resulting executable crashes, if it tries to read some structures defined in the Xt library. I think it is important to make dll/shared library working correctly, because it is necessary to make an binary distribution for some X11 related libraries with a reasonable size. The best solution would be to integrate the dlltool stuff into gcc/ld (recognizing the –shared option), which should make all the things that the several dlltool and ld calls do. If I’m a compiler-, assembler-, linker-, PE-expert, I would put some work on this, but I’m even not sure, that I correctly understand the problem theoretically. Roger - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".