[gdal-dev] Build of gdal fails on missing OSGeo.GDAL.Core

[Paul Harwood]

BTW - I am fairly certain that the error messages are because the .NET SDK
release default is still set as .NET 5  and reading your email - you don't
have .NET 5. Since you did not set the .NET release - it is trying to use
the default.

I think the error messages could be a lot better! I can have a look at that.

I guess that defaulting to .NET 5 is no longer ideal. I can have a look at
that as well.

On Fri, 2 Dec 2022 at 12:58, Paul Harwood <runette at gmail.com> wrote:

> sorry - cut and paste error. That should have been
>
> -DBUILD_CSHARP_BINDINGS=OFF
>
> On Fri, 2 Dec 2022 at 12:53, Paul Harwood <runette at gmail.com> wrote:
>
>> I can have a think about what is causing the problem - but the simplest
>> fix if you don't want the c# bindings is to build with
>> -DBUILD_CSHARP_BINDINGS:BOOLOFF
>>
>> More on the compile switches here
>> https://gdal.org/development/building_from_source.html#cmdoption-arg-BUILD_CSHARP_BINDINGS-BOOL
>>
>> On Fri, 2 Dec 2022 at 12:45, Rob Stevens <phlebas at cantab.net> wrote:
>>
>>> I am very new to building out GIS tools on the MacOS platform,
>>> so I apologize for my rather turgid description below.
>>>
>>> I am trying to build gdal 3.6.0 (git cloned)
>>> on macos catalina 10.15.7 on a macbook pro 2017
>>> On this machine I have various versions of Msoft dotnet core sdks
>>> installed
>>> (7.0.100, 6.0.403, 6.0.401, 2.1.500)
>>> All goes well until the build gets 88% done.
>>> Then I see:
>>>
>>> ======= Building .NET project OSGeo.OSR [Release ]
>>>    Determining projects to restore...
>>> /usr/local/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.EolTargetFrameworks.targets(28,5):
>>>
>>> warning NETSDK1138: The target framework 'net5.0' is out of support and
>>> will not receive security updates in the future. Please refer to
>>> https://aka.ms/dotnet-core-support for more information about the
>>> support policy.
>>>
>>> [/Users/rob/tmp/git_checkouts/gdal/build/swig/csharp/osr/osr_csharp.csproj]
>>>    Writing /var/folders/15/nt94jgd930z_z6zr5gc081y00000gr/T/tmpUJ1Fvw.tmp
>>> info : X.509 certificate chain validation will use the fallback
>>> certificate bundle at
>>> '/usr/local/share/dotnet/sdk/7.0.100/trustedroots/codesignctl.pem'.
>>> info : X.509 certificate chain validation will use the fallback
>>> certificate bundle at
>>> '/usr/local/share/dotnet/sdk/7.0.100/trustedroots/timestampctl.pem'.
>>> info : Restoring packages for
>>>
>>> /Users/rob/tmp/git_checkouts/gdal/build/swig/csharp/osr/osr_csharp.csproj...
>>> info :   GET
>>> https://api.nuget.org/v3-flatcontainer/osgeo.gdal.core/index.json
>>> info :   NotFound
>>> https://api.nuget.org/v3-flatcontainer/osgeo.gdal.core/index.json 1316ms
>>> error: NU1101: Unable to find package OSGeo.GDAL.Core. No packages exist
>>> with this id in source(s): nuget.org
>>> error: Package 'OSGeo.GDAL.Core' is incompatible with 'all' frameworks
>>> in project
>>>
>>> '/Users/rob/tmp/git_checkouts/gdal/build/swig/csharp/osr/osr_csharp.csproj'
>>>
>>> It is not my intent to build any dotnet components/interfaces
>>> but the cmake build seems to want to do this just by virtue
>>> of my having dotnet SDKs installed. The cmake build files
>>> are very difficult to understand, and I have not yet been
>>> able to figure out how to prevent these unneeded
>>> components being built.
>>>
>>> 1. How do I prevent these dotnet components being built?
>>> 2. It seems as though I am trying to build against all versions of the
>>> dotnet
>>>      SDK installed, but some of those versions do not have nuget packages
>>>      for OSGeo.GDal.Core.
>>>      Regardless of my needs, is this not a larger problem in the build?
>>>
>>> Thanks for any help.
>>>
>>> Rob Stevens
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221202/20655905/attachment.htm>