[gdal-dev] C# bindings compilation

Paul Harwood runette at gmail.com
Sun Apr 11 08:47:54 PDT 2021


This going to be a relatively long email probably only of interest to a few
people .. so

TL;DR

- I want to create a Conda Forge package for the C# bindings. Should I
create an RFC for that?
- Can anyone help with the error running the C# bindings on Mac and Linux
(see RUNTIME ERROR about halfway down)
- Can anyone help with the compilation issues - particularly around
libgdal.la (See COMPILE TIME PROBLEMS at the bottom)

BACKGROUND

I needed to get more experience of the C# bindings and particularly need to
work out a way to get them built correctly for Linux and OSX. I decided to
do the experimentation in Conda-Build because it is the preferred solution
for GDAL and for my project and I know it.

This was partly motivated by HoBu's previous comments about separating out
the bindings from the main package - this was a sort of investigation of
the concept.

I would actually like to take this and create a Conda-Forge package for the
C# bindings. Does this make sense? Should I push that through an RFC? The
build scripts I have at the moment are no more than proof of concept. There
is a lot of work to do to productize them (including the issues listed at
the bottom).

It is also true that while Conda is a natural choice for doing GDAL based
compilation (i.e. creating the DLLs) it is not the natural choice for .NET
or Mono distribution. I think that a little work will get around that.

*WINDOWS *
I repurposed the GDAL conda build scripts as follows  based on the docs:
<https://trac.osgeo.org/gdal/wiki/GdalOgrCsharpCompile>
meta.yml
<https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/meta.yaml>
build.bat
<https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/bld.bat>

This *works well* for Windows and I am getting DLLs that work.

*MAC / LINUX*
I used the same approach for mac/ linux although there is no docs onthe
Gdal side on these platforms.
meta.yml
<https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/meta.yaml>
(same
as above)
build.sh
<https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/build.sh>

After some fiddling (see below) I have this working on both platforms  and
it *produces all of the files that it is supposed* ... BUT

*RUNTIME PROBLEM :*

I can create and successfully compile a mono app using GDAL classes and the
GDAL DLL wrapper initializes but fails with errors like

Unhandled Exception:

System.EntryPointNotFoundException: CSharp_OSGeofGDAL_UseExceptions___
assembly:<unknown assembly> type:<unknown type> member:(null)

  at (wrapper managed-to-native) OSGeo.GDAL.GdalPINVOKE.UseExceptions()

  at OSGeo.GDAL.Gdal.UseExceptions () [0x00001] in
<032df0f4cffc4438b8ab5d2bc8d96a7e>:0

  at testapp.Program.Main (System.String[] args) [0x0000a] in
<2cfd8628af524a47a3df8aa28348af7f>:0

[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException:
CSharp_OSGeofGDAL_UseExceptions___ assembly:<unknown assembly>
type:<unknown type> member:(null)

  at (wrapper managed-to-native) OSGeo.GDAL.GdalPINVOKE.UseExceptions()

  at OSGeo.GDAL.Gdal.UseExceptions () [0x00001] in
<032df0f4cffc4438b8ab5d2bc8d96a7e>:0

  at testapp.Program.Main (System.String[] args) [0x0000a] in
<2cfd8628af524a47a3df8aa28348af7f>:0

This is actually not surprising - since if I run dependency Walker on Mac I
get something like this (look at the EntryPOint highlighted)

[image: Screenshot 2021-04-10 at 16.38.44-min.png]

But on Windows I get this (which matches the request listed in the error
message

[image: Screenshot (52)-min.png]

It looks like SWIG on Mac / Linix is building the library without the
namespace? Does anyone have any ideas where I should be looking to solve
this problem.

*COMPILE TIME PROBLEMS*

There are also a couple of compile-time problems that I could do with some
help with :

- At the moment the csharp makefiles seem to be hardcoded about where to
look for the gdal include files so in each case I have to copy the Conda
distributables to the place where the makefile expects them to be. Is there
a way to put the makefile directly at the Conda env. Is there a way to do
this? I could not find anything.

- More seriously, on mac & Linux the compile script needs the libgdal.la file
and this is not distributed in the Conda package. To make this work - I had
to run a complete GDAl compile on each platform to get a copy of the
libgdal.la file and manually add that to the csharp build package. That is
not a production-ready approach! Does anyone know a way around this?

If you got this far - thanks for your time

P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210411/83f7177b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2021-04-10 at 16.38.44-min.png
Type: image/png
Size: 20594 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210411/83f7177b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot (52)-min.png
Type: image/png
Size: 23009 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210411/83f7177b/attachment-0003.png>


More information about the gdal-dev mailing list