From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: paul-ml@is.lg.ua Cc: khan@xraylith.wisc.EDU, cygwin@sourceware.cygnus.com Subject: Re: ld, dlls, and windows libraries Date: Sat, 13 Feb 1999 10:48:00 -0000 Message-id: <199902131848.NAA26824@envy.delorie.com> In-reply-to: < 13857.990213@is.lg.ua > (message from Paul Sokolovsky on Sat, 13Feb 1999 20:35:21 +0200) References: <199902131802.MAA20124@modi.xraylith.wisc.edu> <13857.990213@is.lg.ua> <13857.990213@is.lg.ua> X-SW-Source: 1999-02/msg00430.html > >> It's *supposed* to only export non-static functions, not non-static > >> data. > > But what about data? There's really LOT of libraries which use data > interface in API (most GNU libs do that too - just count: readline, > bfd...). It would be very nice if they can be seamlessly (without > changing source, adding defs, etc.) compiled as dll (and has correct > implib, too). You just can't use the --export-all function for those. *All* data exported by the dll *must* be tagged as __attribute__((dllimport)) or gcc will not produce the correct code for it. If you're tagging it anyway, ld will notice that and export it - even without the --export-all option. The only time --export-all would make a difference with data is when it turns an undefined reference into an incorrect reference. You'd be better off without it! Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS. The linker can't get it right without gcc's help, and if it has gcc's help, it doesn't need --export-all to finish the job. > But what I argue is that it's possible on object file level to > distinguish data and code and to produce correct implibs > automatically - just because COFF symbol has code/data attribute (not > counting that it may be inferred from the section symbol in). True, but gcc will not use the implib correctly. You don't understand what gcc has to go through to access data in a dll - IT'S NOT A LINKER PROBLEM. Gcc has to produce *different* code depending on whether data is local or imported - it can't use a link-time thunk like it can for functions. GCC MUST KNOW ABOUT IMPORTED DATA. When it does, it will tell the linker how to deal with it. There is nothing the linker can do about it, so there is no reason to provide linker-specific options to automatically handle data. From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: paul-ml@is.lg.ua Cc: khan@xraylith.wisc.EDU, cygwin@sourceware.cygnus.com Subject: Re: ld, dlls, and windows libraries Date: Sun, 28 Feb 1999 23:02:00 -0000 Message-ID: <199902131848.NAA26824@envy.delorie.com> References: <199902131802.MAA20124@modi.xraylith.wisc.edu> <13857.990213@is.lg.ua> X-SW-Source: 1999-02n/msg00422.html Message-ID: <19990228230200.GWANBcz3psCOpiqRNKp_5tnE0VB--Lg1jafVTI2yvwI@z> > >> It's *supposed* to only export non-static functions, not non-static > >> data. > > But what about data? There's really LOT of libraries which use data > interface in API (most GNU libs do that too - just count: readline, > bfd...). It would be very nice if they can be seamlessly (without > changing source, adding defs, etc.) compiled as dll (and has correct > implib, too). You just can't use the --export-all function for those. *All* data exported by the dll *must* be tagged as __attribute__((dllimport)) or gcc will not produce the correct code for it. If you're tagging it anyway, ld will notice that and export it - even without the --export-all option. The only time --export-all would make a difference with data is when it turns an undefined reference into an incorrect reference. You'd be better off without it! Once again: YOU MUST TELL GCC ABOUT DATA IMPORTS. The linker can't get it right without gcc's help, and if it has gcc's help, it doesn't need --export-all to finish the job. > But what I argue is that it's possible on object file level to > distinguish data and code and to produce correct implibs > automatically - just because COFF symbol has code/data attribute (not > counting that it may be inferred from the section symbol in). True, but gcc will not use the implib correctly. You don't understand what gcc has to go through to access data in a dll - IT'S NOT A LINKER PROBLEM. Gcc has to produce *different* code depending on whether data is local or imported - it can't use a link-time thunk like it can for functions. GCC MUST KNOW ABOUT IMPORTED DATA. When it does, it will tell the linker how to deal with it. There is nothing the linker can do about it, so there is no reason to provide linker-specific options to automatically handle data.