Fails to load on Azure Web App (Linux) - Missing GLIBC 2.29

[AdamTibi]

Azure Web App (Linux) is failing with LinuxRuntime NuGet v3.6.1.110, v3.6.0.110 and v3.6.0.100 with the error GLIBC 2.29 not found.
But worked with NuGet v3.3.3.120.
Azure Web App has this:
ASP .NETCore Version: 7.0.0
ldd (Debian GLIBC 2.28-10+deb10u2) 2.28

I am assuming this is the problem as v3.3 might be using the older GLIBC. Do you have a work around this?

[MaxRev-Dev]

That's right. The latest version was compiled in Debian 11 with GLIBC 2.31 (2020).
But I tried this sample, and it works as expected.
Please, have it a try. If there are any additional usages of AF you can attach some code samples so I can repro them.

[AdamTibi]

Thank you for the quick response, this is not an Azure Function, this is an Azure Web App. To reproduce:

• Create ASP.NET Core 7 Api App and reference the three packages (latest version, 3.6.1.110)
• Add a call to GdalBase.ConfigureAll(); in an API
• Deploy to Azure Web App Linux

You will get an error stating that the call failed because of missing GLIBC 2.29

[MaxRev-Dev]

If I understood correctly, it's an ASP.NET WebApp deployed to Azure. So formally, it's related to the Azure environment.
The real issue is the Glibc version. The main problem with the older versions is that they depend on a lot of packages (like here) to configure for compiling.
This requires more time to set up everything. I'm not able to recompile these by now. Also, have no experience with Azure, so this will require a reasonable amount of time to solve the problem independently. I won't work on this because it will only be used occasionally by a community.
So, there're two options - you can dockerize your app using Debian 11. Or another option is to investigate the issue and rebuild packages on your own using an older libc.

[AdamTibi]

I understand and thank you for maintaining this.

[MaxRev-Dev]

More on this. One of the main reasons I used Debian 11 is GDAL which updated SWIG to version 4.0. I have not tried to install 4.0 on 'stretch' or 'buster', but it can turn out overwhelming to negotiate that version. Also, this list of package dependencies for Ubuntu18.04 looks no good. Why is this important? GDAL has a lot of dependencies that are prerequisites to the build itself. For example, LibVips uses CentOS7, but it has a few deps which are relatively easy to setup.

If anyone finds a better, less painful solution to fix this, we can bring it to life. By now, I'll update the docs with cautions/specifics for the runtime environment.