I have been having this issue for a number of days now, and have been unable to make any headway on it.
I have a native Obj-C library that i am trying to bind using a MonoTouch binding project. The binding Dll is created, but when i import it to an app and try to compile I get a MT5202 Native linking failed error.
Reading the build output shows that the symbols for the iOS version i am compiling for are missing.
Undefined symbols for architecture armv7:
with the build output showing a number of linking issues (only a few shown)
"_CVPixelBufferGetPixelFormatType", referenced from:
-[DecodePickerController captureOutput:didOutputSampleBuffer:fromConnection:] in libQuickMarkSDK.a(DecodePickerController.o)
-[QMImageUtil saveToAlbum:] in libQuickMarkSDK.a(QMImageUtil.o)
"_CVPixelBufferGetPlaneCount", referenced from:
+[QMImageUtil imageBufferSave:f:] in libQuickMarkSDK.a(QMImageUtil.o)
+[QMImageUtil imageBuffer:zoom:w:h:f:] in libQuickMarkSDK.a(QMImageUtil.o)
"_CVPixelBufferGetWidth", referenced from:
-[DecodePickerController captureOutput:didOutputSampleBuffer:fromConnection:] in libQuickMarkSDK.a(DecodePickerController.o)
-[QMImageUtil saveToAlbum:] in libQuickMarkSDK.a(QMImageUtil.o)
"_CVPixelBufferGetWidthOfPlane", referenced from:
+[QMImageUtil imageBufferSave:f:] in libQuickMarkSDK.a(QMImageUtil.o)
"_CVPixelBufferLockBaseAddress", referenced from:
-[DecodePickerController captureOutput:didOutputSampleBuffer:fromConnection:] in libQuickMarkSDK.a(DecodePickerController.o)
"_OBJC_CLASS_$_AVCaptureDevice", referenced from:
objc-class-ref in libQuickMarkSDK.a(QuickMarkCameraUtil.o)
"_OBJC_CLASS_$_AVCaptureDeviceInput", referenced from:
objc-class-ref in libQuickMarkSDK.a(QuickMarkCameraUtil.o)
To begin with I thought it was just an error with the bindings. So I rebuilt the bindings. No joy. So to test a theory I tried to use the RedLaser mono bindings available from github. This also provided the same error. (if -unsafe is removed from the makefile).
the linkwith statement for the library I need to bind is
assembly: LinkWith ("libQuickMarkSDK.a", LinkTarget.ArmV7, ForceLoad = true, Frameworks = "AVFoundation CFNetwork CoreMedia CoreVideo libz.1.2.5.dylib MobileCoreServices QuartzCore Foundation SystemConfiguration")]
and the Monotouch addition flags being used is -cxx
I have read alot of the other issues but nothing has helped to solve the issue, any help would be great.
You did not state any version numbers (iOS, Xcode, MonoTouch...) so it's a bit hard to give a specific/definitive answer.
That situation can happens when you update a project to iOS6 / Xcode 4.5 where support for ARMv6 was removed. If your native libraries only included ARMv6 then they (the native library, not the binding project) will need to be recompiled for ARMv7 (since it's now a requirement).
To check this please try doing (include the full path to your native library):
file libQuickMarkSDK.a
That should tell you the architectures that your native library supports. Those needs to match the LinkTarget you provide in your binding project (otherwise you'll get errors from the native linker).
Did you try poupou's suggestion in his last comment? I had the same error when compiling for iPhone but not for Simulator. I found that it was a number of missing Frameworks in the LinkWith section. To work out which Frameworks were missing, I googled (for example) CVPixelBufferGetWidthOfPlane Framework.
Credit for this answer goes to cheeesus: MonoTouch Build: ld: symbol(s) not found for architecture armv7
Related
I have a project that I'm trying to get updated to the universal CRT, and I'm still seeing a dependency on vcruntime140.dll and msvcp140.dll, which I think should have been replaced with a ucrtbase.dll, as well as api-ms-win-crt* dlls.
I've already checked out this response here, and this blog post, which explain things pretty well, but still no luck. Here's what I've changed:
Platform Toolset: Visual Studio 2019 (v142)
Windows SDK version: 10.0 (latest installed version)
Additional include directories: added $(UniversalCRT_IncludePath)
Additional library directories: added $(UniversalCRT_LibraryPath_x86)
I also updated my linker dependencies to this set:
ucrt.lib
vcruntime.lib
msvcrt.lib
user32.lib
advapi32.lib
Wsock32.lib
Crypt32.lib
ws2_32.lib
But when I run dumpbin /dependents mydll.dll
File Type: DLL
Image has the following dependencies:
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
VCRUNTIME140.dll
USER32.dll
ADVAPI32.dll
WSOCK32.dll
CRYPT32.dll
WS2_32.dll
MSVCP140.dll
bcrypt.dll
KERNEL32.dll
Summary
E000 .data
66000 .rdata
E000 .reloc
1000 .rsrc
14A000 .text
Is there something else I'm missing to be able to drop the dependency on the specific CRT version?
I've done some more digging, and found this page that says the following:
Starting in Visual Studio 2015, the CRT has been refactored into new
binaries. The Universal CRT (UCRT) contains the functions and globals
exported by the standard C99 CRT library. The UCRT is now a Windows
component, and ships as part of Windows 10.
Great, that's what I expected. Just below though is this:
The vcruntime library contains Visual C++ CRT implementation-specific
code, such as exception handling and debugging support, runtime checks
and type information, implementation details and certain extended
library functions. This library is specific to the version of the
compiler used.
Which implies that there is still a non-universal VC++ dependency that gets linked in by VS. To me, this implies that a dependency-free DLL doesn't really exist (at least not something built with VC++), since you'll always have a vcruntime dependency.
There is always the option of static linking (/MT), but in my case, I'm also looking at a DLL that has /clr, and the two options are mutually exclusive. Application local deployment (just copy vcruntime140.dll with the binaries) also seems to work, and may be the best option for something that I want to be a portable/xcopy deployment.
I'm going to mark this as an answer for now, but if there's a way around this, I'd be interested in seeing it.
I currently run into a problem after I updated my xcode to 4.6.
At the beginning, I got lots of linking errors. With the help from other posts, I am be able to solve them. However, new problems always come whenever I solved the previous one.
Right now, I am stuck at "Undefined symbols for architecture armv7" when I try to build the game on devices with release mode (release and debug modes work for simulator, and debug mode works for devices). I have already researched this problem online, but none of the solutions could solve my situation. That's why I want to start a new post.
Let me explain the situation in details:
All the errors are happened at calling methods in libraries.
my libraries works fine with architecture armv7 before (xcode 4.5)
The current value for Architectures in project file is "Standard (armv7, armv7s)
The current value for Current Architecture is "armv7 armv7s armv6"
This is a sample error:
Even though I only showed errors related to libReceiptVerification.multi.a, errors actually happen at other libraries.
//************* From this line **************
Undefined symbols for architecture armv7:
"_OBJC_CLASS_$_NSMutableOrderedSet", referenced from:
objc-class-ref in libarclite_iphoneos.a(arclite.o)
"_CFStringCreateWithBytes", referenced from:
-[JKSerializer serializeObject:options:encodeOption:block:delegate:selector:error:] in libReceiptVerification.multi.a(JSONKit.o)
_jk_cachedObjects in libReceiptVerification.multi.a(JSONKit.o)
"_CFStringCreateWithBytesNoCopy", referenced from:
-[JKSerializer serializeObject:options:encodeOption:block:delegate:selector:error:] in libReceiptVerification.multi.a(JSONKit.o)
"_CFDataSetLength", referenced from:
__NSStringObjectFromJSONString in libReceiptVerification.multi.a(JSONKit.o)
// *************** Ending Here ***********
So, does anyone has any clue on this problem?
Thanks for your help in advance.
I am having the same problem Solved by setting
Implicitly link Objective-C Runtime Support to NO
You can find it under Project->Build Settings->Apple LLVM Compiler 4.2-Language.
Or search for Implicitly link Objective-C Runtime Support in project->Build Settings
Check out the library targets for libarclite, JSONKit and everything else and make sure they also have the identical architecture values set for their Release builds.
Also that "Build Active Architecture Only" is checked to NO for Release targets.
I built a wrapper for twilio iOS library. I am using the following LinkWith
[assembly: LinkWith ("libTwilioClient.a", LinkTarget.ArmV6 | LinkTarget.ArmV7 | LinkTarget.Simulator, ForceLoad = true ,Frameworks="MediaPlayer SystemConfiguration AVFoundation")]
in Monotouch binding project.
When I created an iPad project that uses above wrapper library I am getting the following errors
Undefined symbols for architecture armv7:
"___divmodsi4", referenced from:
_jbuf_update in libTwilioClient.a(jbuf.o)
_pjmedia_jbuf_get_frame2 in libTwilioClient.a(jbuf.o)
_pjmedia_rtcp_rx_rtp2 in libTwilioClient.a(rtcp.o)
_pjmedia_rtcp_rx_rtcp in libTwilioClient.a(rtcp.o)
_rec_cb in libTwilioClient.a(audiotest.o)
_play_cb in libTwilioClient.a(audiotest.o)
"___udivmodsi4", referenced from:
_update_filter in libTwilioClient.a(resample.o)
ld: symbol(s) not found for architecture armv7
At this point I don't know how to resolve that
That function is a helper used by the compiler to implement a math operation that is more complex than a few CPU instructions. Is it possible you build your library with one compiler and are now linking in a different environment and a different compiler? If you built with gcc that function would be provided by libgcc.a.
By default, Visual Studio compiles a project to use the Multi Threaded DLL, found in the Visual Studio runtime. I want to compile my program using only /MT instead of /MD. Granted, that most systems already have this installed, and it's also available as a re-distributable.
When I change /MD to /MT, I get an error:
MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _free already defined in LIBCMT.lib(free.obj)
And four or five similar errors.
To try and fix this I removed LIBCMT.LIB from the default libraries.
I then get the error:
libcpmt.lib(_tolower.obj) : error LNK2019: unresolved external symbol __calloc_crt referenced in function __Getctype
Removing MSVCRTD.lib from the default list leads to similar errors?
It should be noted that:
-This is an OpenGL project, using the glfw library.
-I am using the SOIL image library by lonesock for texture loading.
Without any further precise information, I would say your first problem is that you're somehow mixing release and debug versions of libraries. MSVCRTD.lib is the debug version of MSVCRT.lib.
Either you have some debug settings hanging around in your own projects, or you're linking against debug versions of libraries you're using.
Never ever mix debug and release versions. If you're lucky you get an error like this. In some rare situations all magically seems to work until it doesn't.
I'm trying to build my application with MSVC 2010 instead of GCC. With GCC everything works fine. My app uses boost_system and boost_thread libraries.
I built boost with VC2010 in "system" layout, that means the libraries are named just libboost_system.lib (and not libboost_system_compiler_threading_version_wtf_snafu.lib)
The libs reside in C:\Boost\lib,
the Makefile specifies
LFLAGS = /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:CONSOLE
LIBS = /LIBPATH:C:/Boost/lib libboost_system.lib libboost_thread.lib Ws2_32.lib
when invoking nmake it compiles, but when trying to link it quits with
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-1_43.lib
I mean seriously, WTF? I told it to link libboost_systen.lib and libboost_thread.lib how come it tries to link libboost_data_time and why does it assume I built the libs in "tagged" layout??
How can I stop MSVC trying to be smart and guess what I might have wanted to link?
Thanks,
Philipp
This is a feature of the Boost libs with compatible compilers for automatic linking.
(Those convoluted library names cover the myriad of threading and linking options that are available on the platform; there are good reasons to use that convention on Windows...)
More information here:
http://www.boost.org/doc/libs/1_33_1/more/getting_started.html#auto-link
I can't find a page for a more recent version, but I believe the BOOST_ALL_NO_LIB and related options are all still valid in 1.43.
Assuming you are auto-linking (i.e. you've defined BOOST_ALL_DYN_LINK or library specific equivalents).
For layout 'system' you have to define the preprocessor macro:
BOOST_AUTO_LINK_NOMANGLE
to link to the correct library names.
For layout 'tagged' you have to define the preprocessor macro:
BOOST_AUTO_LINK_TAGGED
to link to the correct library names.
I don't know if you could do this override for some libraries and keep the default for others. That would be a very cumbersome setup I'd imagine.