Enable GDAL C API for Delphi

[arturr]

Finally I managed to solve a problem with binding GDAL C API in Delphi. I attach a DEF file that must be used as a link option to make C API visible under Delphi. To build a Delphi friendly GDAL DLL file, please:

1. in nmake.opt file add param :

LINKER_FLAGS_GDAL = /def: gdal14.def

2. in makefile.vc change :

$(GDAL_DLL): staticlib

link /dll /debug $(OGR_INCLUDE) $(BASE_INCLUDE) $(LIBOBJ) \

$(EXTERNAL_LIBS) gcore\Version.res \

/out:$(GDAL_DLL) /implib:gdal_i.lib $(LINKER_FLAGS_GDAL)

I changed linker flag name in point 1, because LINKER_FLAGS is used in GDAL and OGR. If I leave this flag name unchanged, OGR won’t link properly looking for GDAL functions. Maybe the solution for this is to make two separate def files for GDAL and OGR. My trick works as a temporary solution.

After successful compilation I can bind all GDAL and OGR functions in Delphi. I tested almost all GDAL functions with different raster formats.

I hope that dev team will make use of this and import it gracefully into GDAL sources for further tests.

see ​http://article.gmane.org/gmane.comp.gis.gdal.devel/11174 for details.

[arturr]

DEF file for GDAL C API to link and build Delphi friendly DLL

[warmerdam]

A brief review of the .def file seems to suggest all it does it rename all the stdcall names (ie. _OSRClone@4) to cdecl style names (ie. OSRClone). As far as I can tell the Delphi bindings would work just find if they referenced the actual stdcall names.

At this time I have no desire to incorporate this as a change to the baseline GDAL, and I would suggest delphi users simple use the stdcall versions of the names as is done by the VB6 bindings.

eg.

http://trac.osgeo.org/gdal/browser/trunk/gdal/vb6/GDALCore.bas

I think elsewhere I have seen a suggestion that something changed in this regard between 1.4.0 and 1.4.1, but I don't see anything describing that here. If there was a chance I'd like to know about it. Please append additional notes, or reopen this bug if I have missed the point.

[ilucena]

I can do the changes on nmake.opt (as optional) and add the gdal14.def to the trunk.

[warmerdam]

Ivan,

Please don't. I think this is the wrong solution.

[warmerdam]

Ivan Lucena wrote:
...
> Well, That is my story, but what about yours?
> 
> Why did you thing this is the wrong solution?

Ivan,

I am familiar with .def files, and have used them in the past in various projects. To me the only rationale for the change being proposed is to make the names easier to guess when creating the .PAS external statements. This seems like a particular weak reason to change the win32 ABI.

I already used the mangled stdcall names in VB6 without any great problem. Just a wee bit of looking around in the symbol list.

The downsides include:

• Having to maintain the .def file.
• Changing the ABI.
• losing the function naming that makes it clear that the calling convensions are stdcall, not cdecl.

None of these downsides are overwhelming, and I'd consider the proposal if it made it possible to use GDAL with Delphi. But it isn't about making it possible, just altering naming conventions for the convenience of the one person who makes delphi wrappers (and incidentally disrupts the work done by the person who prepared the VB6 wrappers).

Best regards,

Frank

[warmerdam]

Ivan,

All the above said, if you feel this would be a good idea, you can go ahead and commit it as long as it isn't the default configuration.

[ilucena]

Frank,

I analyzed and tested those three alternatives for accessing to GDAL C API function in object pascal, Delphi programming environment:

#1 - Add the gdal14.def to the trunk and add a optional "/def:" to the

linker as Artur proposed.

#2 - Suggest pascal programmers to enter the symbols names as they appears

in the DLL in the pascal interface unit:

Function GDALOpen(...): PGDALDataset; stdcall;

Function GDALOpen; external 'gdal14.dll' name '_GDALOpen@8';

That eliminates the need of module definition file (.def).

#3 - Suggest pascal programmers to comment the STDCALL line on nmake.opt

and follow the related instruction. In this case the interface unit will be much simpler:

Function GDALOpen(...): PGDALDataset; cdecl;

Function GDALOpen; external 'gdal14.dll' name 'GDALOpen';

Since there are alternatives (2,3) that can be adopted without having to change the compilation process in GDAL and without having to deal with maintaining the gdal14.def through the versions, I would rather not make those changes proposed by Artur. Notice that the Delphi-Help also suggest that stdcall is more efficient than cdecl.

I also think that as a SDK developer Artur, or any other pascal programmer, will be well served by option 2 since he already managed to get the symbol names in the gdal14.def file:

GDALOpen = _GDALOpen@8 GDALOpenShared = _GDALOpenShared@8 GDALGetRasterXSize = _GDALGetRasterXSize@4 GDALGetRasterYSize = _GDALGetRasterYSize@4

^{Best regards,}

Best regards,

Ivan