From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: paul-ml@is.lg.ua Cc: cygwin@sourceware.cygnus.com Subject: Re: ld, dlls, and windows libraries Date: Sat, 13 Feb 1999 09:52:00 -0000 Message-id: <199902131751.MAA26487@envy.delorie.com> In-reply-to: < 1809.990213@is.lg.ua > (message from Paul Sokolovsky on Sat, 13Feb 1999 19:25:34 +0200) References: <1809.990213@is.lg.ua> <1809.990213@is.lg.ua> X-SW-Source: 1999-02/msg00425.html > 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? It's in our master sources, it's all a matter of when we do the next full beta. I'm not sure about the "--export-all" part; you may need to do "-Wl,--export-all" as that's a linker-specific option. Unless someone wants to get it into egcs (hint). > MK> The --export-all exports all the non-static symbols as done on most It's *supposed* to only export non-static functions, not non-static data. > 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. The changes I did to ld allow the following cool new features: * ld can produce a DLL instead of an EXE. * ld can produce the implib at the same time it produces the dll. * You can list .def files on the command lines just like objects when creating dlls, or the IMPORTS section can be used instead of linking against a dll (i.e. a def file's IMPORTS can replace an implib). * You can tell ld to *produce* a .def file (for --export-all and attribute()) when it produces the dll. * You can list a DLL on the command line just like a library (it synthesizes the implib internally). * "ld --help" lists all the nt-specific options. As far as data/code differences, you MUST tag all your imported data as imported (attribute((dllimport))) in your header files for gcc to produce the correct code to access them. Even if ld did this right (I don't think it does), it would only change your error from a segfault to an unresolved external. If anyone wants to test this ld, or submit additions to it, mail me personally. Please include a note about what you're thinking of doing, too. From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: paul-ml@is.lg.ua Cc: cygwin@sourceware.cygnus.com Subject: Re: ld, dlls, and windows libraries Date: Sun, 28 Feb 1999 23:02:00 -0000 Message-ID: <199902131751.MAA26487@envy.delorie.com> References: <1809.990213@is.lg.ua> X-SW-Source: 1999-02n/msg00417.html Message-ID: <19990228230200.HhgK32bsQJJEXPSvuqJVr0b1RZWMCcvnwkg7_b5WT5k@z> > 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? It's in our master sources, it's all a matter of when we do the next full beta. I'm not sure about the "--export-all" part; you may need to do "-Wl,--export-all" as that's a linker-specific option. Unless someone wants to get it into egcs (hint). > MK> The --export-all exports all the non-static symbols as done on most It's *supposed* to only export non-static functions, not non-static data. > 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. The changes I did to ld allow the following cool new features: * ld can produce a DLL instead of an EXE. * ld can produce the implib at the same time it produces the dll. * You can list .def files on the command lines just like objects when creating dlls, or the IMPORTS section can be used instead of linking against a dll (i.e. a def file's IMPORTS can replace an implib). * You can tell ld to *produce* a .def file (for --export-all and attribute()) when it produces the dll. * You can list a DLL on the command line just like a library (it synthesizes the implib internally). * "ld --help" lists all the nt-specific options. As far as data/code differences, you MUST tag all your imported data as imported (attribute((dllimport))) in your header files for gcc to produce the correct code to access them. Even if ld did this right (I don't think it does), it would only change your error from a segfault to an unresolved external. If anyone wants to test this ld, or submit additions to it, mail me personally. Please include a note about what you're thinking of doing, too.