From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mumit Khan To: Paul Sokoilovsky Cc: cygwin@sourceware.cygnus.com Subject: Re: Re[2]: ld, dlls, and windows libraries Date: Sat, 13 Feb 1999 09:52:00 -0000 Message-id: <199902131751.LAA20089@modi.xraylith.wisc.edu> In-reply-to: Your message of "Sat, 13 Feb 1999 19:25:34 +0200." < 1809.990213@is.lg.ua > References: <1809.990213@is.lg.ua> X-SW-Source: 1999-02/msg00424.html Paul Sokolovsky writes: > > MK> When DJ's excellent work on ld is released, you'll be able to do: > > MK> $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o > > Wow! How long to wait for this? DJ is the person to ask. > MK> The --export-all exports all the non-static symbols as done on most > MK> Unix systems. If you want to restrict the exports, you have two choices: > > And what about implibs? Is there a chance that they will be produced > with gcc too, so procedure and data exports will be properly > distinguished? That's the thing which causes most pain with gnu-win32 > tools now, imho, - suffering an access violation when, due to automatically > produced def, which treats all exports as code, some fucnction fetches jump > instruction instead of data. I'm not exactly sure what you're asking, but I'll take a stab at it. Currently you can create implib with dllwrap directly when building the DLL: $ dllwrap --implib libfoo.a [rest of command line] DJ's new ld has the same option: $ ld --shared --implib libfoo.a [rest of command line] As for data vs code, that's a fundamental limitation of Windows32 DLLs; you have to optionally tag data as exportable in the DLL and access it via __declspec(dllimport) to get the correct code, otherwise you get garbage. eg., when building a DLL: int __declspec(dllexport) globalvar; and when using the the DLL: int __declspec(dllimport) globalvar; The DEF file entry is however the same for code and data. You can also add the DATA keyword in DEF file, but I forget exactly what the implications are. The examples I distribute as part of dllhelpers package show how to do data just as you would do for MSVC or other commercial compilers. The thing to remember is that creating true shared libraries as one would expect on most modern variants of Unix (eg., ELF) is just not possible on windows32; Interix does it, but it is a very different beast. If this is not what you're asking, please let me know. Regards, Mumit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mumit Khan To: Paul Sokoilovsky Cc: cygwin@sourceware.cygnus.com Subject: Re: Re[2]: ld, dlls, and windows libraries Date: Sun, 28 Feb 1999 23:02:00 -0000 Message-ID: <199902131751.LAA20089@modi.xraylith.wisc.edu> References: <1809.990213@is.lg.ua> X-SW-Source: 1999-02n/msg00416.html Message-ID: <19990228230200.BhFh5SfkzvD7uAyQdPpfe4Q6wgS4adinGxw9GAo2aZU@z> Paul Sokolovsky writes: > > MK> When DJ's excellent work on ld is released, you'll be able to do: > > MK> $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o > > Wow! How long to wait for this? DJ is the person to ask. > MK> The --export-all exports all the non-static symbols as done on most > MK> Unix systems. If you want to restrict the exports, you have two choices: > > And what about implibs? Is there a chance that they will be produced > with gcc too, so procedure and data exports will be properly > distinguished? That's the thing which causes most pain with gnu-win32 > tools now, imho, - suffering an access violation when, due to automatically > produced def, which treats all exports as code, some fucnction fetches jump > instruction instead of data. I'm not exactly sure what you're asking, but I'll take a stab at it. Currently you can create implib with dllwrap directly when building the DLL: $ dllwrap --implib libfoo.a [rest of command line] DJ's new ld has the same option: $ ld --shared --implib libfoo.a [rest of command line] As for data vs code, that's a fundamental limitation of Windows32 DLLs; you have to optionally tag data as exportable in the DLL and access it via __declspec(dllimport) to get the correct code, otherwise you get garbage. eg., when building a DLL: int __declspec(dllexport) globalvar; and when using the the DLL: int __declspec(dllimport) globalvar; The DEF file entry is however the same for code and data. You can also add the DATA keyword in DEF file, but I forget exactly what the implications are. The examples I distribute as part of dllhelpers package show how to do data just as you would do for MSVC or other commercial compilers. The thing to remember is that creating true shared libraries as one would expect on most modern variants of Unix (eg., ELF) is just not possible on windows32; Interix does it, but it is a very different beast. If this is not what you're asking, please let me know. Regards, Mumit