Failed to open dylib file, I am trying it since 3 days now, please help me fix it

[Sulman012]

I followed all steps mentioned in read me at https://github.com/storj-thirdparty/uplink-swift
verified them multiple times,

When building the app it throws back with exception "999" message "Failed to open dylib file"

to find what is happening I get some deep in code.
when I run it on Simulator it throws at this part of code in uplink_swift.swift
let dynammicFileHandle = dlopen(storjSwiftPathString, RTLD_LOCAL|RTLD_NOW)
if dynammicFileHandle == nil {
throw storjException(code: 9999, message: "Failed to open dylib file")
}

and when I run it on real iPhone device iPhoneX, it throw from this part
if !fileManger.fileExists(atPath: storjSwiftPathString) {
throw storjException(code: 9999, message: "Failed to open dylib file")
}

with some more deep-dive I have seen the path it is trying to check the file existence and trying to read from, the file exists right there in both cases, Simulator as well as iPhone X, but not able to open the file in either case.

Xcode Version: 12.4
iPhone X:
macVersion: macOS Catalina 10.15.7

do let me know where I am missing...

[kmozurkewich]

Hi @Sulman012 -

Can you share what the value of storjSwiftPathString is for both the sim and real device?

[Sulman012]

on iPhone
"/Users/apple/Library/Developer/Xcode/DerivedData/Runner-gdvsbtyquigwibbalenyxtvfrvgu/SourcePackages/checkouts/uplink-swift/Sources/libuplink/include/libuplinkc.dylib"

On Simulator:
"/Users/apple/Library/Developer/Xcode/DerivedData/Runner-gdvsbtyquigwibbalenyxtvfrvgu/SourcePackages/checkouts/uplink-swift/Sources/libuplink/include/libuplinkc.dylib"

• sorry for being late launching the simulator took time.
• both the paths seem to be the same.

[Sulman012]

Hi @kmozurkewich, any help?

[kmozurkewich]

Hi @Sulman012 -

If the dylib file is at the correct location, the issue may be with the permissions of the file. Can you verify the code you are executing has access to another file at that path?

[Sulman012]

Hi @Sulman012 -

If the dylib file is at the correct location, the issue may be with the permissions of the file. Can you verify the code you are executing has access to another file at that path?

let me look into that right now

[Sulman012]

Yes, it can read files from that path, I put a txt file there and tried to load it.

Simulator can read this file but for iPhone it says no such files exists.
But for dylib file even simulator is not able to load the dylib file, simulator pass the check of file exists but not able to load it.

is it give you some clue of its fix,
or can you confirm that this thing is tested and working with iOS?

[rmichelberger]

Hi @Sulman012
I've the same issue.
Could you solve it somehow?

[Sulman012]

@rmichelberger
I can try, how would you like to collaborate around.
I can give you a hint, the Issue was related to file path relevancy.
I did attempt many things over it and somehow fixed it.
it goes by months now, not remembered the fix exactly, but you can try around.

[buildgreatthings]

I also have the same issue. @rmichelberger have you had any luck?

[kmozurkewich]

@awcchungster - we did not test in iOS, however, dylibs should work. Based on:

https://developer.apple.com/forums/thread/125796
https://stackoverflow.com/questions/45542928/load-custom-dynamic-library-dylib-in-ios-application

the dylib this binding generates needs to be packaged as a framework within your iOS project. Can you try that approach?

[buildgreatthings]

Could you walk me through package the dylib to Frameworks?

From the Stackoverflow, I already have this setting applied "Adjust the Runpath Search Paths in your build settings to include @executable_path/Frameworks." My app has cocoapods for an unrelated dependency.

On the other option, my embed framework is managed by Cocoapods and doesn't include any mention of frameworks or executables

[buildgreatthings]

I tried adding the dylib file as a file to copy over during the build time, but the compiler returns a "libuplinkc.dylib was built for macOS" error.

https://stackoverflow.com/questions/31199010/how-to-use-a-c-dylib-from-a-swift-file-in-a-framework

[kmozurkewich]

@awcchungster - I'm not an iOS dev, but that may be related to the target architecture the dylib is built for. (Desktop silicon instead of iOS). How did you include this binding project? Swift Package Manager?

[buildgreatthings]

Updates:

Instead of running the makefile, I took the uplinks library and compiled it manually using Xcode's builder (from this stackoverflow):

The first step compiles to .a file from Go. The second step converts it to the dylib
CGO_ENABLED=1 GOOS=darwin GOARCH=arm64 SDK=iphoneos CC=$(go env GOROOT)/misc/ios/clangwrap.sh CGO_CFLAGS="-fembed-bitcode" go build -buildmode=c-archive -tags ios -o arm64.a .

xcrun -sdk iphoneos clang -arch arm64 -shared -Wl,-all_load -o libuplinkc.dylib

After I have that dylib, I drag it into build phase for copy files over and set it as a executable setting. In the uplink_swift file, I changed the storjSwiftPathString to the following code. The copy files over exposes the dylib to the main bundle path.

guard let storjSwiftPathString = Bundle.main.path(forResource: "libuplinkc", ofType: "dylib") else {
            print("Can't find libuplinkc")
            return
        }

Once I have all this done, the Storj library is able to initialize. However at runtime, I encounter a compilation bug.

libuplinkc.dylib`golang.org/x/sys/cpu.getisar0:
->  0x10c867270 <+0>:  mrs    x0, ID_AA64ISAR0_EL1
    0x10c867274 <+4>:  str    x0, [sp, #0x8]
    0x10c867278 <+8>:  ret    
    0x10c86727c <+12>: udf    #0x0

With the highlighted error of: Thread 11: signal SIGILL

Anyone know what's going on?

[Erikvv]

Cgo makes it very easy to produce nonsensical binaries.

TopperDEL's compile commands can be found here, maybe you can see if he is doing something different: https://github.com/TopperDEL/uplink.net/blob/a73bf2af0b962f461b8c7e6ac4aa687b8d8824a4/uplink.NET/pipelines/azure-pipelines-build-apple.yml#L118

[buildgreatthings]

Thank you for pulling that out. I connected with TopperDEL yesterday and I tried his commands verbatim from the CICD pipeline you linked.  The compilation process resulted in identical errors. My build machine is the last gen Intel MacBook Pro. My target device is an iOS iPhone 13 Pro.

…

On Fri, Nov 12, 2021 at 4:26 AM Erik van Velzen < Erik van Velzen ( Erik van Velzen ***@***.***> ) > wrote: Cgo makes it very easy to produce nonsensical binaries. TopperDEL's compile commands can be found here, maybe you can see if he is doing something different: https://github.com/TopperDEL/uplink.net/blob/a73bf2af0b962f461b8c7e6ac4aa687b8d8824a4/uplink.NET/pipelines/azure-pipelines-build-apple.yml#L118 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( #5 (comment) ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAXMY6F32KFO6TMYDGHDIV3ULUBXPANCNFSM46XEGNFA ).

[buildgreatthings]

Next update, I took another approach to testing the Storj C library. I no longer believe the issue is related to the bindings.

This binding converts the C library to dylib in the makefile. Rather than using the more optimized dylib, I convert the original C library to static A C archives (.a files). I moved over the .a and .h files which allowed me to call functions directly from Swift. When I built and ran the app, it crashed with the same error.

With entirely different Swift code and the core C library compiled to different variations of acceptable ARM64 bindings, I believe the issues is with the core C library itself. I opened a separate ticket in the C library repo:

storj/uplink-c#7

[buildgreatthings]

Next update, as a temporary workaround, I am using the AWSS3 Cocoapods SDK and using the Storj (minio) S3 gateway proxy.

[kmozurkewich]

@awcchungster - does your app have a requirement to store the keys outside of the storj platform? storj does have a hosted s3 endpoint that works well.

[Erikvv]

If you compile with GOOS=ios this should now be fixed.

Remaining task for this issue is to improve the documentation because the compilation steps for iOS are not documented.

[joslinm]

@Erikvv When I make with GOOS=ios make, I get the following error:

-buildmode=c-shared not supported on ios/arm64

My go version: go version go1.19.4 darwin/arm64 Do you have any idea how to resolve?

[Erikvv]

I think when I got it working I compiled it as a static library and included it in a mobile app in Xcode.

But let me check my notes when I get home.