LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.09.15 15:25 "Re: Calltype support", by Frank Warmerdam
Bob Friesenhahn wrote: > The only other means available appears to be to maintain a separate > ".def" file to tell the linker which functions should be exported. This > is very easy to implement but it adds another file to the build. I think > that the user of the header files still needs to know which functions > are imported from a DLL so that they use the right calling convention. > This is painful for the library user. > > I notice that for GraphicsMagick we have hacked our libtiff headers to > declare functions like: > > extern TIFFEXPORT tsize_t TIFFReadTile(TIFF*, > tdata_t, uint32, uint32, uint32, tsample_t); > > so that explicitly exporting functions is possible. > > I therefore support adding the hooks to export functions under Windows, > but don't think that obfuscating all function declaractions with macros > is a necessary approach. Bob, But we do maintain a libtiff.def already to keep the list of functions to be exported. The issue in question is calling conventions which is in addition to the issue of controlling what gets exported. I have used macros like your TIFFEXPORT (which presumably evaluates to __declspec(dllexport) on win32) before, but I don't know that it is sufficient to handle calling convention issues. It seems to me I have run into issues with where the __cdecl parameter goes in the declaration of a function and it wasn't always sufficient to just put it in where the __declspec(dllexport) would go, and that for this reason a more complex function macro mechanism was required. Looking throught he MITAB library, the following was done: const char MITAB_DLL * MITAB_STDCALL mitab_c_getlasterrormsg(); The MITAB_DLL macro expands to __declspec(dllexport) on windows, and the MITAB_STDCALL expands to ___stdcall but they apparently have to go in different places in the declaration. Boy, it really irritates me that we can't just put all special function attributes just before the function name itself. Anyways, my point is that if we want to control calling conventions we may need a more complex setup than just what is needed to control DLL exporting. Martin ... if you make up a bug report, please append the various discussion to it. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent