[gdal-dev] C# bindings compilation

Sun Apr 11 11:17:25 PDT 2021

Paul,

RFCs are only required for substantial changes that affect the 
OSGeo/GDAL repository. People who contribute to Conda Forge are free to 
do so (hopefully in good faith, that is not defacing too much the GDAL 
"brand"). If we decided to retire the C# bindings from OSGeo/GDAL this 
should probably go through some motion

Regarding build issues on Linux, I could reproduce that, but was like 
"worked half time". I finally realized that you had to run "make" twice 
because of oddities in the Makefile dependency rules. And there was the 
base swig/SWIGmake.base file generating .cpp files in swig/csharp 
whereas swig/csharp/GNUmakefile generated them in 
swig/csharp/gdal|const|ogr|osr. I've hopefully addressed and 
rationalized that in https://github.com/OSGeo/gdal/pull/3670. At least 
now on my local machine (ubuntu 20.04), one a clean swig/csharp, "cd 
swig/csharp && make && make test" works. The error you got was similar 
to the one I got

Regarding your compilation issues with your current recipee, I'd expect 
you to have to rather copy most of the content of swig/include, 
swig/include/csharp and swig/csharp in your own repository and adapt 
them to a standalone build where you include and link against an 
installed prefix of the native libgdal.

Even

Le 11/04/2021 à 17:47, Paul Harwood a écrit :
> 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 <http://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)
>
> 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
>
> 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 <http://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 
> <http://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
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210411/9f2f5a84/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/9f2f5a84/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/9f2f5a84/attachment-0003.png>