finagolfin

@gregjlee, still involved?

I think this is a bug in the Swift ClangImporter that it can't handle opaque structs, been meaning to look into it and file a bug. I hit that nio-ssl...

Never mind, [I guess Swift chooses not to handle this](https://www.objc.io/blog/2018/01/30/opaque-vs-unsafe-pointers/), as Vlad says above, so you will have to change it to `OpaquePointer` as he shows.

I've submitted patches for this in apple/swift-nio-ssl#306 and apple/swift-tools-support-core#243. You may want to do the same for `swift-log`, which I don't use.

It says duplicate symbols in the same file, for C and ARMv7 assembly: maybe you're missing some C define that normally picks one or the other? I [regularly build those...

Hmm, there is only [a single definition in those files](https://github.com/apple/swift-nio-ssl/blob/main/Sources/CNIOBoringSSL/crypto/poly1305/poly1305_arm.c#L190), so C defines are not the issue. You may need to examine those object files and see what's going on:...

I do, [that package is built separately for armv7 on my Android CI that runs on Ubuntu every day](https://github.com/buttaface/swift-android-sdk/actions?query=event%3Aschedule) without a problem. If you can reproduce when building that package...

Oh wait, I see it now, the paths are different. You are linking the same file from `/Users/kmi/ncp-core/.build/armv7-unknown-linux-android/debug/CNIOBoringSSL.build` and `Users/kmi/ncp-core/.build/armv7-unknown-linux-android/debug/CCryptoBoringSSL.build`, which would be an artifact of building swift-crypto twice in...

I added the NDK 22 support upstream, but lately I've had issues with it, so I'm sticking with 21e for now. I suggest you wait till the next LTS release...

I am using the latest LTS NDK 23b without a problem now, submitted my changes at apple/swift#39921.