I tried to use LibEtPan as a backend for a mail client. I downloaded the source code from https://github.com/dinhviethoa/libetpan and additional libs from https://github.com/bindle/iOSPorts too. I ran the LibEtPan build-mac/update.sh and added the libetpan.xcodeproj to my project as well as openldap.xcodeproj, openssl.xcodeproj, Cyrus SASL.xcodeproj.
I set the following Target Dependencies: libetpan ios (libetpan), lber (openldap), ldap (openldap), crypto (openssl), ssl (openssl), sasl2 (Cyrus SASL) and I Linked Binary With Libraries: libetpan-ios.a, libiconv.dylib, liblber.a, libldap.a, libcrypto.a, libsasl2, libssl.a
But as soon as I call something like mailimap_new i get the error message:
Undefined symbols for architecture i386:
"_mailimap_extension_xgmmsgid", referenced from:
_internal_extension_list in libetpan-ios.a(mailimap_extension.o)
(same with armv7 or other architectures)
I have no idea which lib i have to include additionally.
Related
I’m trying to build a Swift Package that wraps a fat static library written in C: libndi_advanced_ios.a from NewTek's Apple Advanced NDI SDK.
I am having trouble linking the pre-compiled library (only headers files and .a binary package is available) to my Swift Package. I have done a lot of research and tried different solutions, but none of them worked. Here is a quick list:
Cannot bundle in an XCFramework because libndi_advanced_ios.a supports multiple platforms (arm_v7, i386, x86_64, arm64) and xcodebuild -create-xcframework return the error binaries with multiple platforms are not supported (this solution is discussed on Swift Forums too);
Using .linkedLibrary in targets as suggested on SPM Documentation (that is outdated) gives the warning system packages are deprecated; use system library targets instead, and I don’t even remember if it builds successfully;
Playing around with different flags and settings (like linkerSettings) has not been successful. Maybe I just missed the right combination.
I can link dozens of Stackoverflow's questions and other posts that didn’t help, but it will be useless (a, b, c).
At the moment I have this configuration:
With Package.swift that contains the following code:
let package = Package(
name: "swift-ndi",
platforms: [.iOS(.v12)],
products: [
.library(
name: "swift-ndi",
targets: ["swift-ndi"])
],
dependencies: [],
targets: [
.target(name: "CiOSNDI", path: "Libraries"),
.target(
name: "swift-ndi",
dependencies: ["CiOSNDI"]),
.testTarget(
name: "swift-ndiTests",
dependencies: ["swift-ndi"]),
]
)
You can find the whole project at alessionossa/swift-ndi.
The only result at the moment are some warnings and the module CiOSNDI do not build:
I tried also .systemLibrary(name: "CiOSNDI", path: "Libraries/"), with this configuration: alessionossa/swift-ndi/tree/systemLibrary; but I get these errors:
NOTE
NDI_include is actually an alias/symbolic link to /Library/NDI Advanced SDK for Apple/include, while NDI_iOS_lib points to /Library/NDI Advanced SDK for Apple/lib/iOS.
I always cleaned build folder after changes to Package.swift.
UPDATE 10/01/2022: libndi_advanced_ios.a requires libc++.tbd. That can be easy linked in an app in Build Phases -> Link Binary With Libraries, but I don’t know how to link in a Swift Package.
Binary targets need to specified with .binary_target. See the docs and example here.
An example of a static library wrapped in an .xcframework looks like this from the file command:
$ file GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement
GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement: Mach-O universal binary with 2 architectures: [arm_v7:current ar archive] [arm64]
GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement (for architecture armv7): current ar archive
GoogleAppMeasurement.xcframework/ios-arm64_armv7/GoogleAppMeasurement.framework/GoogleAppMeasurement (for architecture arm64): current ar archive
One way to create the .xcframework file is to use Firebase's ZipBuilder that creates a .xcframework files from static libraries that are specified with a CocoaPods podspec file.
I also needed to add the NDI SDK as a Swift package dependency in my app.
I found a couple of approaches that worked:
You can create an XCFramework bundle by extracting a thin arm64 library from the universal library:
lipo "/Library/NDI SDK for Apple/lib/iOS/libndi_ios.a" -thin arm64 -output "$STAGING_DIRECTORY/libndi.a"
Then create an XCFramework bundle:
xcodebuild -create-xcframework -library "$STAGING_DIRECTORY/libndi.a" -headers "/Library/NDI SDK for Apple/include" -output "$STAGING_DIRECTORY/Clibndi.xcframework"
I ended up not using this approach because hosting the XCFramework as a downloadable binary release on GitHub required me to make my repo public (see this issue).
Instead I am using a system library target, in my Package.swift:
targets: [
.target(
name: "WrapperLibrary",
dependencies: ["Clibndi"],
linkerSettings: [
.linkedFramework("Accelerate"),
.linkedFramework("VideoToolbox"),
.linkedLibrary("c++")
]),
.systemLibrary(name: "Clibndi")
]
Then, I have WrapperLibrary/Sources/Clibndi/module.modulemap that looks like:
module Clibndi {
header "/Library/NDI SDK for Apple/include/Processing.NDI.Lib.h"
link "ndi_ios"
export *
}
Finally, my application target (part of an Xcode project, not a Swift package) depends on WrapperLibrary, and I had to add "/Library/NDI SDK for Apple/lib/iOS" (including the quotation marks) to "Library Search Paths" in the "Build Settings" tab.
As an alternative to modifying the application target build settings, you could add a pkg-config file to a directory in your pkg-config search paths. For example, /usr/local/lib/pkgconfig/libndi_ios.pc:
NDI_SDK_ROOT=/Library/NDI\ SDK\ for\ Apple
Name: NDI SDK for iOS
Description: The NDI SDK for iOS
Version: 5.1.1
Cflags: -I${NDI_SDK_ROOT}/include
Libs: -L${NDI_SDK_ROOT}/lib/iOS -lndi_ios
Then use .systemLibrary(name: "Clibndi", pkgconfig: "libndi_ios") in your package manifest. I found this less convenient for users than just adding the setting to my application target, however.
Ideally you could add the NDI SDK's dependency library and frameworks to the pkg-config file as well (Libs: -L${NDI_SDK_ROOT}/lib/iOS -lndi_ios -lc++ -framework Accelerate -framework VideoToolbox), but it appears there is a bug in Swift's pkg-config parsing of -framework arguments, so I filed a bug: SR-15933.
I'm trying to build a driver with Microsoft Dmf Framework https://github.com/microsoft/DMF
I builded Dmf from the provided sln file in this repository. It results in DmfK.lib (I build a kernel mode driver), then I add this lib to my driver project.
But I have 27 times the same linker error "unresolved external symbol WppAutoLogTrace" from different functions of this lib, ie:
Error LNK2019 unresolved external symbol WppAutoLogTrace referenced in function "long __cdecl HashTable_ContextInitialize(struct DMFMODULE__ *)" (?HashTable_ContextInitialize##YAJPEAUDMFMODULE__###Z) Main (Main\Main) C:\Data\Development\MyDriver\Source\Main\DmfK.lib(Dmf_HashTable.obj)
I found no relevant information about this function over the internet, I can't figure out which other lib to include. Is this a problem with a missing lib or an issue with the DmfK.lib build ?
I finally found the solution:
WppAutoLogTrace is implemented in WppRecorder.lib
We are unable to distribute our sample app which uses our framework as well as our users can't.
While archiving and distributing to AppStore, the app is rejected with the following message:
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path. If your app contains bitcode, bitcode processing may have failed. Because of these errors, this build of your app will not be able to be submitted for review or placed on the App Store.
The framework contain the bitcode, or at least there's a BITCODE_GENERATION_MODE = bitcode build setting in our .xcconfig, which basically means, the Xcode will add -fembed-bitcode build flag to any clang invocation.
From here, we've started testing using Ad-Hoc builds, to speed up our trial and error attempts, which also fails while Rebuild from bitcode option is selected. Organiser shows the popup with the following contents:
ipatool failed with an exception: #<CmdSpec::NonZeroExitException: $ /Applications/Xcode.app/Contents/Developer/usr/bin/python3 /Applications/Xcode.app/Contents/Developer/usr/bin/bitcode-build-tool -v -t /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin --sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.2.sdk -o /var/folders/vz/b0jj0dms4014y5htfv93svfc0000gn/T/ipatool20201130-52097-13rj9hy/thinned-out/arm64/Payload/iosTest.app/Frameworks/SciChart.framework/SciChart --generate-dsym /var/folders/vz/b0jj0dms4014y5htfv93svfc0000gn/T/ipatool20201130-52097-13rj9hy/thinned-out/arm64/Payload/iosTest.app/Frameworks/SciChart.framework/SciChart.dSYM --strip-swift-symbols /var/folders/vz/b0jj0dms4014y5htfv93svfc0000gn/T/ipatool20201130-52097-13rj9hy/thinned-in/arm64/Payload/iosTest.app/Frameworks/SciChart.framework/SciChart
Status: pid 52150 exit 1
Stdout:
SDK path: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/
Logs provided isn't very informative, here is the snippet from IDEDistributionPipeline.log
-= Output =-
ld: warning: -sdk_version and -platform_version are not compatible, ignoring -sdk_version
Undefined symbols for architecture arm64:
"___llvm_profile_runtime", referenced from:
__hidden#25821_ in 0832.o
__hidden#25821_ in 0833.o
__hidden#25821_ in 0834.o
__hidden#25821_ in 0835.o
__hid
2020-11-30 16:19:17 +0000 den#25821_ in 0836.o
__hidden#25821_ in 0837.o
__hidden#25821_ in 0838.o
...
ld: symbol(s) not found for architecture arm64
Exited with 1z
Failed to compile bundle: /var/folders/vz/b0jj0dms4014y5htfv93svfc0000gn/T/SciChart6aun_sfs/SciChart.arm64.xar
Stderr:
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:2808:in `block in CompileOrStripBitcodeInBundle'
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:2747:in `each'
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:2747:in `CompileOrStripBitcodeInBundle'
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:3016:in `block in ProcessIPA'
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:2978:in `each'
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:2978:in `ProcessIPA'
from /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool:3928:in `<main>'
2020-11-30 16:19:17 +0000 /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool exited with 1
which after bunch of warnings shows the actual error at the end of file (I can't include full log, since it's too much of a raw text):
code = 1061;
description = "ipatool failed with an exception: #<CmdSpec::NonZeroExitException: ...
info = {
};
level = ERROR;
type = exception;
Not sure what to to do with this, I've tried different build settings options, nothing helped... Already contacted apple, but no feedback yet, and knowing them, we can wait far too long...
The strange part here, is if we include our .framework directly as a source code and then archive the app - everything works as expected. If we include it as XCFramework or just .framework, which is pre-built - it fails as described above.
I might miss something simple or obvious here, so please let me know if somebody have some insights on that matter.
Some system info:
macOS BigSur 11.0.1
XCode Version 12.2 (12B45b)
We've tried different combinations of macOS and Xcode, e.g.:
Catalina with Xcode 12
BigSur with Xcode 11
etc.
Any help is greatly appreciated.
Thanks.
Long story short, there were LLVM instrumentation included, which prevents AppStore processing. I've written a whole blog post about it here - https://blog.scichart.com/xcframework-xcode-12-and-bigsur-issues/
To sum up, here is a few required steps to make sure while creating XCFramework for distribution:
Using archive builds is a MUST, release build isn't enough
BUILD_LIBRARY_FOR_DISTRIBUTION must be set to YES
SKIP_INSTALL must be set to NO
GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO to turn off GCC instrumentation and remove them from the binary
CLANG_ENABLE_CODE_COVERAGE = NO to turn off code coverage tools from the binary
Having all of the above helped to solve our preparing and distribution problem and hopefully save you some time if you happened to face same issues as we did.
I am a new user of tensorflow. I wish to integrate a specific graph.pb file into an ios device, and have followed all the compilation instructions carefully as described in tensorflow git.
yet when I try to run the camera example app I get the error:
E /tensorflow/tensorflow/examples/ios/camera_copy/tensorflow_utils.mm:140] Could not create TensorFlow Graph: Invalid argument: No OpKernel was registered to support Op 'Conv2D' with these attrs. Registered devices: [CPU], Registered kernels:
<no registered kernels>
[[{{node pyramid_regression_0/convolution}} = Conv2D[T=DT_FLOAT, data_format="NHWC", dilations=[1, 1, 1, 1], padding="SAME", strides=[1, 1, 1, 1], use_cudnn_on_gpu=true](input_2, pyramid_regression_0/kernel/read)]]
2018-08-22 16:54:00.303760: F tensorflow/examples/ios/camera_copy/tensorflowUtil.mm:68] Couldn't load model: Invalid argument: No OpKernel was registered to support Op 'Conv2D' with these attrs. Registered devices: [CPU], Registered kernels:
<no registered kernels>
[[{{node pyramid_regression_0/convolution}} = Conv2D[T=DT_FLOAT, data_format="NHWC", dilations=[1, 1, 1, 1], padding="SAME", strides=[1, 1, 1, 1], use_cudnn_on_gpu=true](input_2, pyramid_regression_0/kernel/read)]]
I also followed the instructions according to the solution offered in here, but I got there are some differences (probably due to the versions diffs between a year ago and now (Aug 2018))
bazel build --copt="-DUSE_GEMM_FOR_CONV" tensorflow/python/tools/print_selective_registration_header compiled without errors
then created the ops_to_register.h file:
when used the bazel-bin command, it adds a strange print of tf.estimator package not installed to the first line.
In addition, during the file creation this warning appears multiple times:
RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
when I create the ops_to_register.h file using python3 , it creates the file without strange prints
in both cases there are no occurrences of strcmp or strcmpc at all, and got Conv2DUsingGemmOp op in the bazel created file instead of Conv2DOp by python3
I tried to use the ops_to_register.h file for the tensorflow/contrib/makefile/compile_ios_tensorflow.sh compilation, but it fails during the compilation:
Undefined symbols for architecture arm64:
"nsync::nsync_cv_signal(nsync::nsync_cv_s_)", referenced from:
tensorflow::condition_variable::notify_one() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_cv_wait_with_deadline(nsync::nsync_cv_s_, nsync::nsync_mu_s_, timespec, nsync::nsync_note_s_)", referenced from:
tensorflow::condition_variable::wait_until_system_clock(tensorflow::mutex_lock&, std::__1::chrono::time_point > >) in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_cv_init(nsync::nsync_cv_s_)", referenced from:
tensorflow::condition_variable::condition_variable() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_from_time_point_(std::__1::chrono::time_point > >)", referenced from:
tensorflow::condition_variable::wait_until_system_clock(tensorflow::mutex_lock&, std::__1::chrono::time_point > >) in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_cv_wait(nsync::nsync_cv_s_, nsync::nsync_mu_s_)", referenced from:
tensorflow::condition_variable::wait(tensorflow::mutex_lock&) in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_mu_runlock(nsync::nsync_mu_s_)", referenced from:
tensorflow::mutex::unlock_shared() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_mu_rlock(nsync::nsync_mu_s_)", referenced from:
tensorflow::mutex::lock_shared() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_mu_unlock(nsync::nsync_mu_s_)", referenced from:
tensorflow::mutex::unlock() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_mu_lock(nsync::nsync_mu_s_)", referenced from:
tensorflow::mutex::lock() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_cv_broadcast(nsync::nsync_cv_s_)", referenced from:
tensorflow::condition_variable::notify_all() in libtensorflow-core-arm64.a(mutex.o)
"nsync::nsync_mu_init(nsync::nsync_mu_s_*)", referenced from:
tensorflow::mutex::mutex() in libtensorflow-core-arm64.a(mutex.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make:
[/tensorflow/tensorflow/contrib/makefile/gen/bin/ios_ARM64/benchmark] Error 1
'[' 2 -ne 0 ']'
echo 'arm64 compilation failed.'
arm64 compilation failed.
exit 1
environment details:
tensorflow 1.9.0 (there is tensorflow 1.10.0, but is currently not supported for the ios compilations)
python 3.6.6
all the compilations are done with -a arm64 only
does anyone have an idea what went wrong here?
thanks a lot
I once had a similar error when compiling for the raspberry pi, I had to manually export the environment variables HOST_NSYNC_LIB and TARGET_NSYNC_LIB
First check if you have them already exported: echo $HOST_NSYNC_LIB
if that is empty you should look where your nsync library is compiled (just look for libnsync.a)
Then export both paths:
export HOST_NSYNC_LIB='your/path/to/libnsync.a'
export TARGET_NSYNC_LIB="$HOST_NSYNC_LIB"
Hope this works for you!
Following this link. I am stuck in the last two steps during setting up my workstation.
As a compiler I use Code:Block MinGW; I have already generated the compiled opencv files, now I need to build the sln file in Windows. I use Code Block to build this OpenCV Project File in the path D:\OpenCV\Build\Opencv, where I put the generated bin file after using Cmake.
During the building, it stopped at 40%, saying;
Linking CXX executable ....\bin\opencv_perf_core.exe
c:/codeblock/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe:
warning: auto-importing has been activated without
--enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from
auto-imported DLLs. Cannot export _ZN12_GLOBAL__N_13ROp3allEv: symbol
not found Cannot export _ZN12_GLOBAL__N_17CmpType3allEv: symbol not
found collect2: ld returned 1 exit status mingw32-make.exe[2]: *
[bin/opencv_perf_core.exe] Error 1 mingw32-make.exe1: *
[modules/core/CMakeFiles/opencv_perf_core.dir/all] Error 2
mingw32-make.exe: * [all] Error 2 Info: resolving vtable for
cv::_OutputArray by linking to imp_ZTVN2cv12_OutputArrayE
(auto-import) Info: resolving vtable for cv::_InputArray by linking to
imp_ZTVN2cv11_InputArrayE (auto-import) Info: resolving vtable for cv::Exception by linking to imp_ZTVN2cv9ExceptionE (auto-import)
Creating library file: ....\bin\libopencv_perf_core.dll.a Process
terminated with status 2 (14 minutes, 29 seconds) 0 errors, 3 warnings
How can I solve this problem?
Unfortunately, there's not much you can do, according to http://code.opencv.org/issues/2523.
You will have to use a recent version of MinGW. It builds fine using the latest MinGW shipping with GCC 4.7.2.
This issue seems to have been introduced in OpenCV 2.4.3 as it is said version 2.4.2 builds fine.