<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Paul,</p>
    <p>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</p>
    <p>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 <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/3670">https://github.com/OSGeo/gdal/pull/3670</a>.
      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</p>
    <p>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.<br>
    </p>
    <p>Even<br>
    </p>
    <div class="moz-cite-prefix">Le 11/04/2021 à 17:47, Paul Harwood a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAE8nN5NVNWHu6xm25hu2Wd9_SMp6-BotZ2vZ6kfAmoyhwtChEg@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div id="gmail-m_2149023992514511700gmail-:qfe">
                <div id="gmail-m_2149023992514511700gmail-:qfd">
                  <div dir="ltr">This going to be a relatively long
                    email probably only of interest to a few people ..
                    so <br>
                    <br>
                    TL;DR<br>
                    <br>
                    - I want to create a Conda Forge package for the C#
                    bindings. Should I create an RFC for that?<br>
                    - Can anyone help with the error running the C#
                    bindings on Mac and Linux (see RUNTIME ERROR about
                    halfway down)
                    <div>- Can anyone help with the compilation issues -
                      particularly around <a href="http://libgdal.la/"
                        target="_blank" moz-do-not-send="true">libgdal.la</a> (See
                      COMPILE TIME PROBLEMS at the bottom)</div>
                    <div><br>
                    </div>
                    <div>BACKGROUND</div>
                    <div><br>
                    </div>
                    <div>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.<br>
                       </div>
                    <div>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.<br>
                      <br>
                      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).<br>
                      <br>
                      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.<br>
                      <br>
                      <b>WINDOWS </b></div>
                    <div>I repurposed the GDAL conda build scripts as
                      follows  based on <a
                        href="https://trac.osgeo.org/gdal/wiki/GdalOgrCsharpCompile"
                        target="_blank" moz-do-not-send="true">the docs:</a><br>
                      <a
href="https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/meta.yaml"
                        target="_blank" moz-do-not-send="true">meta.yml</a></div>
                    <div><a
href="https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/bld.bat"
                        target="_blank" moz-do-not-send="true">build.bat</a></div>
                    <div><br>
                    </div>
                    <div>This <b>works well</b> for Windows and I am
                      getting DLLs that work.<br>
                      <br>
                      <b>MAC / LINUX</b><br>
                      I used the same approach for mac/ linux although
                      there is no docs onthe Gdal side on these
                      platforms.<br>
                      <a
href="https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/meta.yaml"
                        target="_blank" moz-do-not-send="true">meta.yml</a> (same
                      as above)<br>
                    </div>
                    <div><a
href="https://github.com/ViRGIS-Team/staged-recipes/blob/master/recipes/Gdal_CSharp/build.sh"
                        target="_blank" moz-do-not-send="true">build.sh</a></div>
                    <div><br>
                    </div>
                    <div>After some fiddling (see below) I have this
                      working on both platforms  and it <b>produces all
                        of the files that it is supposed</b> ... BUT<br>
                      <br>
                      <b>RUNTIME PROBLEM :</b><br>
                      <br>
                      I can create and successfully compile a mono app
                      using GDAL classes and the GDAL DLL wrapper
                      initializes but fails with errors like <br>
                      <br>
                      <p><span>Unhandled Exception:</span></p>
                      <p><span>System.EntryPointNotFoundException:
                          CSharp_OSGeofGDAL_UseExceptions___
                          assembly:<unknown assembly>
                          type:<unknown type> member:(null)</span></p>
                      <p><span><span>  </span>at (wrapper
                          managed-to-native)
                          OSGeo.GDAL.GdalPINVOKE.UseExceptions()</span></p>
                      <p><span><span>  </span>at
                          OSGeo.GDAL.Gdal.UseExceptions () [0x00001] in
                          <032df0f4cffc4438b8ab5d2bc8d96a7e>:0<span> </span></span></p>
                      <p><span><span>  </span>at testapp.Program.Main
                          (System.String[] args) [0x0000a] in
                          <2cfd8628af524a47a3df8aa28348af7f>:0<span> </span></span></p>
                      <p><span>[ERROR] FATAL UNHANDLED EXCEPTION:
                          System.EntryPointNotFoundException:
                          CSharp_OSGeofGDAL_UseExceptions___
                          assembly:<unknown assembly>
                          type:<unknown type> member:(null)</span></p>
                      <p><span><span>  </span>at (wrapper
                          managed-to-native)
                          OSGeo.GDAL.GdalPINVOKE.UseExceptions()</span></p>
                      <p><span><span>  </span>at
                          OSGeo.GDAL.Gdal.UseExceptions () [0x00001] in
                          <032df0f4cffc4438b8ab5d2bc8d96a7e>:0<span> </span></span></p>
                      <p><span><span>  </span>at testapp.Program.Main
                          (System.String[] args) [0x0000a] in
                          <2cfd8628af524a47a3df8aa28348af7f>:0<span> </span></span></p>
                      <br>
                      This is actually not surprising - since if I run
                      dependency Walker on Mac I get something like this
                      (look at the EntryPOint highlighted)</div>
                    <div><br>
                    </div>
                    <div><img
                        src="cid:part7.29235450.7E97637E@spatialys.com"
                        alt="Screenshot 2021-04-10 at 16.38.44-min.png"
                        class="" width="500" height="200"><span></span><br>
                    </div>
                    <div><br>
                    </div>
                    <div><span>But on Windows I get this (which matches
                        the request listed in the error message<br>
                        <br>
                      </span><img
                        src="cid:part8.6C6B7BD2.B4342A8D@spatialys.com"
                        alt="Screenshot (52)-min.png" class=""
                        width="542" height="125"><br>
                      <span><br>
                        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.<br>
                        <br>
                        <b>COMPILE TIME PROBLEMS</b><br>
                        <br>
                        There are also a couple of compile-time problems
                        that I could do with some help with :<br>
                        <br>
                        - 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.<br>
                        <br>
                        - More seriously, on mac & Linux the compile
                        script needs the <a href="http://libgdal.la/"
                          target="_blank" moz-do-not-send="true">libgdal.la</a> 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 <a href="http://libgdal.la/"
                          target="_blank" moz-do-not-send="true">libgdal.la</a> file
                        and manually add that to the csharp build
                        package. That is not a
                        production-ready approach! Does anyone know a
                        way around this?</span></div>
                    <div><span><br>
                      </span></div>
                    <div><span>If you got this far - thanks for your
                        time</span></div>
                    <div><span><br>
                      </span></div>
                    <div><span>P</span></div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
        <div class="gmail-adL">
          <div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>