AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.09.14 11:06 "[Tiff] Calltype support", by Martin Schramm
2004.09.15 13:46 "Re: [Tiff] Calltype support", by Frank Warmerdam
2004.09.15 15:02 "Re: [Tiff] Calltype support", by Bob Friesenhahn
2004.09.15 15:25 "Re: [Tiff] Calltype support", by Frank Warmerdam
2004.09.15 15:38 "Re: [Tiff] Calltype support", by Bob Friesenhahn
2004.09.16 17:54 "[Tiff] versioned symbols [Was: Calltype support]", by Jay Berkenbilt
2004.09.16 18:08 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Thomas J. Kacvinsky
2004.09.16 18:22 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Jay Berkenbilt
2004.09.16 18:27 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Thomas J. Kacvinsky
2004.09.16 21:36 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Andrey Kiselev
2004.09.16 22:36 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Bob Friesenhahn
2004.09.19 15:52 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Jay Berkenbilt
2004.09.19 19:34 "Re: [Tiff] versioned symbols [Was: Calltype support]", by Andrey Kiselev

2004.09.15 15:25 "Re: [Tiff] Calltype support", by Frank Warmerdam

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