Closed stephensheehy closed 3 years ago
I believe this is due to a limitation with us trying to embed the native library inside the binding library.
Can you try adding this to your binding project:
<PropertyGroup>
<NoBindingEmbedding>true</NoBindingEmbedding>
</PropertyGroup>
and rebuilding?
That will stop embedding the binary, and create an additional binding resource folder you will need to distribute next to your binding library, but will significantly speed up your builds and very likely fix this issue.
Hi, thanks for the reply :)
I added <NoBindingEmbedding>true</NoBindingEmbedding>
and encountered the error:
error MT7068: Can't create a binding resource package unless there are native references in the binding project.
Which sounded like it was related to how the native libraries are referenced. This is how I have been doing it:
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<ObjcBindingNativeLibrary Include="..\..\..\..\install\iOS_fat_10.2\lib\libmMap.a">
<TargetPath>libmMap.a</TargetPath>
</ObjcBindingNativeLibrary>
</ItemGroup>
I tried removing the above and adding the libraries as 'NativeReference' since the error seem to imply this may be expected:
<ItemGroup>
<NativeReference Include="Native References/libmMap.a">
<Kind>Static</Kind>
</NativeReference>
</ItemGroup>
While this did result in the expected <project>.resources
folder, it contained only a zero byte file called manifest
and no copies of the static libraries.
If you have any thoughts on what prevents the external resource folder from being properly formed I'd really appreciate it.
Meanwhile I'll just see if I can find any more different ways to reference the native libraries.
Change this:
<NativeReference Include="Native References/libmMap.a">
to be
<NativeReference Include="..\..\..\..\install\iOS_fat_10.2\lib\libmMap.a">
The Include needs to be a path to your native library in question.
Since I had added the native library reference through the IDE it had copied the file into Native References/libmMap.a
(project relative) so the path was valid... In any case changing it gave the same result, an empty .resources folder and zero byte manifest file.
It occurred to me to see if Visual Studio on mac would behave differently and indeed it does. There the resource file and manifest are created as expected, so this last issue seems to be a bug particular to Visual Studio on Windows using a mac build agent.
As long as the command line msbuild invocation works equally well on the mac (I haven't tested this yet) our continuous integration system will be happy and I can work around the issue for local builds.
Thanks for all the help. Would love to see the Windows issue fixed though, I'm more at home there :)
That is very helpful information. Unfortunately the team that handles iOS remote builds from Windows VS is not available via github.
Could you please file an issue using the instructions here to let them know.
If you run into more trouble unrelated to that, please reopen this issue.
Thanks!
Just a note for any who come later looking to do this sidecar deployment thing:
when the library is embedded the assembly linker properties can be set in code eg.
[assembly: LinkWith("myLib.a", Frameworks = "Metal MetalKit CoreGraphics CoreVideo MetalPerformanceShaders", ForceLoad = true, SmartLink = true, IsCxx = true)]
But when we deploy the native libs in an external resource folder the the assembly linker properties must be set in the .csproj file so they will be correctly copied to the output manifest file, eg.
<NativeReference Include="..\..\..\..\install\iOS_fat_10.2\lib\myLib.a">
<Kind>Static</Kind>
<SmartLink>true</SmartLink>
<ForceLoad>true</ForceLoad>
<IsCxx>true</IsCxx>
<Frameworks>Metal MetalKit CoreGraphics CoreVideo MetalPerformanceShaders</Frameworks>
</NativeReference>
Took me a while to figure this out. And as of writing neither building libraries with side-by-side resource folders, nor building applications which link to such libraries works in Visual Studio on Windows, it has to be Visual Studio Mac.
Objective C binding library fails to build when attempting to wrap large (>2GB) native libraries. Libraries of this size are not so unusual when compiling with debug info for multiple architectures.
The portable executable builder seems to have an internal bottleneck, as shown by the callstack in the build log below.
I would imagine this is the same PE builder issue discussed in these stack overflow posts (one of which is more than 10 years old!) https://stackoverflow.com/questions/67407062/visual-studio-embed-large-resource-file-almost-4gb https://stackoverflow.com/questions/6976693/what-is-the-maximum-size-of-a-pe-file-on-64-bit-windows
Steps to Reproduce
Expected Behavior
Compilation success
Actual Behavior
Compilation failure
Environment
Build Logs