在AWS Lambda上使用System.Drawing.Common NuGet包时无法加载DLL“libdl”

我们有一个缩略图生成器lambda函数，我正在尝试更新到.NET Core 2.0，但是在使用Microsoft的System.Drawing.Common NuGet包时遇到以下错误：

TypeInitializationException

‘Gdip’的类型初始化程序引发了exception。 在TestFailExample的System.Drawing.SafeNativeMethods.Gdip.GdipCreateBitmapFromScan0（Int32宽度，Int32高度，Int32步长，Int32格式，HandleRef scan0，IntPtr和位图）处于System.Drawing.Bitmap..ctor（Int32宽度，Int32高度，PixelFormat格式） .Function.FunctionHandler（String输入，ILambdaContext上下文）在C：\ work \ graphics \ TestFailExample \ Function.cs中：第25行在lambda_method（Closure，Stream，Stream，LambdaContextInternal）

引起的

DllNotFoundException

无法加载DLL’libdl’：找不到指定的模块或其中一个依赖项。在System.Drawing.SafeNativeMethods的Interop.Libdl.dlopen（String fileName，Int32标志）处找不到指定的模块或其中一个依赖项。\ n（HRESULT的exception：0x8007007E）。 System.Drawing.SafeNativeMethods.Gdip..cctor（）中的Gdip.LoadNativeLibrary（）

我已经看到了这个问题，但没有解决方案。

重现问题的最小代码是：

 public string FunctionHandler(string input, ILambdaContext context) { using (var bmp = new Bitmap(100, 100)) { return bmp.Width.ToString(); } } 

只需创建一个.NET Core 2.0 Lambda函数项目，添加对System.Drawing.Common NuGet包的引用，并用上面的代码替换函数处理程序。 将它放在AWS上并运行它以获取错误。 我已经注意到，在尝试实际使用它之前引用该包不会引起问题，但这可能归结为编译器优化。

我已经将MCVE打包成一个项目并将其上传到GitHub ，以简化人们重现问题所需的步骤。

我可以看到/lib64/libdl.so.2存在，但/lib64/libdl.so没有。 由于符号链接似乎不可能（只读文件系统），我不知道如何解决这个问题。 我已经尝试使用LD_LIBRARY_PATH环境变量，在/tmp创建一个文件夹，并将该文件符号化为该函数所做的第一件事。 不幸的是，它似乎在这里查找所有库，因此该函数根本不运行。 我也尝试将LD_LIBRARY_PATH设置为/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/tmp and虽然我现在可以再次运行该function，但这仍然没有帮助，我只是得到相同的Gdip错误。

我注意到/ var / task / lib已经包含在LD_LIBRARY_PATH中，所以我尝试用我的函数打包libdl.so和libgdiplus.so，但这也失败了，这次说明在libdgiplus.so找不到入口点GdiplusStartup libdgiplus.so 。 这些文件不是来自Amazon Linux实例，所以我现在尝试安装Mono并从Amazon Linux实例获取它们。 这没有帮助。

我已经尝试过使用CoreCompat 绘图库，但这也报告了与libgdiplus.so有关的问题，即使我尝试将其与函数捆绑在一起。

我已经尝试过自己的Linux实例，并且可以确认System.Drawing.Common有效。

是否有一些聪明的解决方案可以让我在AWS Lambda上使用System.Drawing.Common ？ 还有另一种方法可以捏造我的lambda函数来拥有libdl并且工作吗？