I have an OSX desktop Xcode project which includes another Xcode project (a framework) as a dependency. When I build an archive of the app, it generates two dSYM packages - one for the app and one for the framework.
When I symbolicate crashes received from the app, symbols from the app package show up correctly (with file names and line numbers). However, symbols from the framework don't symbolicate at all - they just show the Framework name and memory address. Is there a way to symbolicate the parts of the stack trace involving the framework code?
Looking at the archive that I generated the.app package from, the UUID of the framework's dSYM doesn't match the one that gets copied into the "Frameworks" folder in the .app:
The HCCommon framework inside the .app package in the archive file:
/path/to/HipChat.xcarchive $ dwarfdump --uuid Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon
UUID: 84891A9C-19DB-3E16-BE7E-9D4056FFFB97 (x86_64) Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon
vs the dSYM of the HCCommon framework (in the dSYMs directory in the archive file):
/path/to/HipChat.xcarchive $ dwarfdump --uuid dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon
UUID: 767F2D97-9E0B-3C4D-8337-FDF5A9CA2D81 (x86_64) dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon
I'm not sure why your build is resulting in inconsistent dSYM UUIDs. When we do these kinds of builds (having spot-checked a few now), we have consistent UUIDs.
However, in answer to your question about how you can symbolicate the crash reports you've already received given the .dSYMs you already have (assuming for the moment that although the UUIDs match, they refer to identical code, and thus would work).
I have found the following to work well if you have to force the specific dsym:
atos -arch x86_64 -o <path_to_dsym_within_package> -l <offset_of_framework>
It's certainly not as pretty and generally I run the individual addresses through atos manually, but the result is a valid routine/line combination (assuming that you match the correct versions, etc.)
The <path_to_dsym_within_package> refers to foo.framework.dSYM/Contents/Resources/DWARF/foo followed by your binary name, where foo is the name of the framework. For us this works for any kind of plugin as well.
The <offset_of_framework> is from offset column in the crash log, where:
0 libsystem_kernel.dylib 0x7fff8e785ce2 0x7fff8e76f000 + 93410
1 libsystem_c.dylib 0x7fff871afa7a 0x7fff8716e000 + 268922
2 CTUtils 0x104e26c62 0x104e17000 + 64610
In this case, the first hex number is the address, the second hex number is the starting offset for the particular framework, and the + value is the decimal offset within the framework.
You'll need the second number (hex offset) for the command line above, and the first number to find the specific routine/line number.
In a worst-case scenario, there's always using dwarfdump directly, by using:
dwarfdump <path_to_dSYM> --arch x86_64 --lookup <offset>
<path_to_dSYM> is the path to the top level ".dSYM" folder (unlike the atos command above), and <offset> is the offset within the module, which isn't as convenient as atos.
P.S. atos should be installed in /usr/bin/atos if you have the dev tools installed.
I encountered this problem too. After some investigation, it turned out that Xcode was copying debug framework builds into release builds, but, apparently, creating dSYMs from the correct release binaries.
This was despite using Xcode to add the framework dependencies from the workspace. Eventually I found out why: the frameworks were included the project with their location "Relative to Group" for some reason. After I made sure all were "Relative to Build Product", it solved the problem for me. Not saying it is the only possible cause, but it's worth double-checking all the paths in the build log, because Xcode won't warn about anything in this case.
Related
We're adding a QuickLook plug-in to our project.
Everything is fine until macOS trying to invoke our plug-in, at which point we're getting the beloved The bundle couldn’t be loaded because it is damaged or missing necessary resources error.
We've checked with otool -L on the plug-in's binary that all dependencies are in place, however as soon as the OS is asking our plug-in for a preview for the file type supported by us we get:
22/04/17 12:03:05,716 quicklookd[55323]:
[QL] Can't load plug-in at file:///Users/myname/Library/Developer/Xcode/DerivedData/The_Project-gpihzjouhxvifqcslmywktktizer/Build/Products/Debug/MyApp.app/Contents/Library/QuickLook/SomeQuickLookPlugIn.qlgenerator/:
The bundle “SomeQuickLookPlugIn” couldn’t be loaded because it is damaged or missing necessary resources.
The one thing we're not quite sure about is the dependency to our internal frameworks.
We've set up the plug-in similar to our main app, i.e. the private framework dependency resolves to:
#executable_path/../Frameworks/MyFW.framework/Versions/A/MyFW (compatibility version 1.0.0, current version 1.0.0)
..which would work OK if #executable_path were either the main app's binary or the plug-in's main binary as we copied the frameworks in both places in the bundle.
Any thoughts?
Ideally we would like the OS to tell us which dependency it failed to resolve -
is there any debug flag that can be set..?
As per https://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html and http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/ you should
set the Installation Directory for your referenced framework(s) to #rpath
in the app set Runtime Search Paths to #loader_path/../Frameworks
and in the QuickLook plug-in set Runtime Search Paths to #loader_path/../../../../../Frameworks as suggested by catlan -
that way you don't need to duplicate referenced frameworks inside the QuickLook plug-in
Compile, run, and everything should just work if everything else is set up correctly.
In addition you might want to check the code-signing settings in your plug-in to make sure there's no problems there.
One thing you can do is remove (or turn-off) code signing from your app and then see if it will load the plug-in…
To check if code-signing is the problem you can turn it off temporarily for your app using the Terminal to codesign --remove-signature YourApp.app and see if it works..
Run Search Paths should be #loader_path/../../../../../Frameworks because it is installed into Main.app/Contents/Library/QuickLook/QuickLookPlugin.qlgenerator/Contents/Mac/QuickLookPlugin, so we need to go five folders down from the #loader_path to find the frameworks folder.
Below is my scenario,
In my Application i had to make use of libopus library , i downloaded and install, compile --> install procedure is normal as its for any other open source library,
I linked libopus.a with my application, the way i did is , by default it will get installed in /usr/local/lib, so i drag from there and add it to my application,
Worked fine and no error on my machine,
On Another machine, i was expecting it to be run smoothly as i included this library statically, but its throwing error as
dyld: Library not loaded: /usr/local/lib/libopus.0.dylib
so i concluded, libopus.a somehow including libopus.0.dylib also dynamically,
Now i am able ot add a copy phase in my build setting , so it will get copied in ../Framework folder
if i do otool -L libpus.a then it shows following result
otool -L /usr/local/lib/libopus.a
Archive : /usr/local/lib/libopus.a
/usr/local/lib/libopus.a(bands.o):
/usr/local/lib/libopus.a(celt.o):
/usr/local/lib/libopus.a(cwrs.o):
/usr/local/lib/libopus.a(entcode.o):
/usr/local/lib/libopus.a(entdec.o):
/usr/local/lib/libopus.a(entenc.o):
/usr/local/lib/libopus.a(repacketizer.o):
It doesn't show as its depend upon the dylib library
Now my Question is
How to tell Application to look into this path first
I tried following option,
install_name_tool but it seems it will work on other machine , so the user need to run this script NOT DEVELOPER,
trying to set the some option in the xcode to set the RUNTIME Search path to locate that particular dylib but not getting succeed so far
install_name_tool is run by the developer during the build process, not by the user.
If you're building the library, you should use libtool(1) with the option -install_name #rpath; otherwise, you can use install_name_tool(1) with -id #rpath to do the same thing on the dylib. Then, when you're building your application, set the "Runpath search paths" to the path where you will install the library.
Apple has some good documentation on this in their Mach-O Programming Topics and Dynamic Library Programming Topics.
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.
I have created a Command Line Utility C++ tool in XCode using Objective-C. I want the version number to be displayed in the Info of the created executable. So I have added the version number 1.0.0.0 in the Current Project Version field in the Build settings. However, when I build it, the version number does not get added to the created 'Unix Executable File'.
Am I missing something?
Thanks for the help.
Unfortunately, Xcode will not embed the current project version into the executable by itself, as of version 3. I'm not sure if this has changed in Xcode 4.
I ran into this problem a couple of years ago. It turns out that:
Version numbers displayed in the Finder come from applications’ Info.plists. In the case of an application bundle, Info.plist is a file. In the case of an executable, it must be embedded in a __TEXT section. The format of the Info.plist is the same either way.
Xcode does not have one-click support for embedding Info.plists into executables, but it is possible.
Xcode doesn’t preprocess Info.plist files unless they’re going into an application bundle (e.g. to insert the value of CURRENT_PROJECT_VERSION).
I hacked up a solution, but it’s unpolished and probably doesn’t represent best practices.
First, I created a new, stock Info.plist file called Info_template.plist. I set CFBundleVersion to ${CURRENT_PROJECT_VERSION}, and CFBundleShortVersionString to ${CURRENT_MARKETING_VERSION}.
Then, I added a Run Script phase called “Preprocess Info.plist” at the beginning of the build, using /bin/sh as the shell, with this script:
set -u
if ! [[ ${CURRENT_PROJECT_VERSION:-""} && ${CURRENT_MARKETING_VERSION:-""} ]]; then
echo "Version numbers are not set" >&2
exit 1
fi
# Ghetto environment variable expansion, since Xcode does not appear to have built-in expansion for arbitrary files
{ echo "cat <<EOF"
cat ${SRCROOT}/Info_template.plist
echo "EOF"
} | sh > ${DERIVED_FILES_DIR}/Info.plist
I added $(DERIVED_FILE_DIR)/Info.plist to its output files.
Then, I opened the target’s build settings, and added this to Other Linker Flags:
-sectcreate __TEXT __info_plist ${DERIVED_FILE_DIR}/Info.plist
This asks the linker to roll the generated Info.plist file into the executable.
Let me know how this works for you, or if I left anything out!
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
using frameworks in a command line tool
Hey,
I've written a command line 'foundation tool' that uses the RegexKit.framework extensively. Everything works when run in Xcode but if I compile the release build and try to run it in Terminal I get the following error:
dyld: Library not loaded: #executable_path/../Frameworks/RegexKit.framework/Versions/A/RegexKit
Closer inspection reveals that the RegexKit.framework bundle is sat in the same directory as my executable file... I've done some research and I'm thinking that as command line tools don't use application bundles there's no where for Xcode to copy the framework to. So I'm guessing that I need to compile the framework as a static library and include it in my code... am I right? If so, how do I go about doing this? Is there anything I can do in Terminal to point to the framework externally?
Any help would be very greatly received, I've been banging my head against this for a few days now!
Thanks in advance,
Tom
So... What I did in the end was to recompile the framework with a different Installation Directory (in the Deployment section, under the Build tab in the Target's Info) - I set it to just #executable_path.
I then compiled the framework and replaced the one in my Utilitie's project, I also changed the Copy Files build phase to copy the framework to "Executables" rather than Frameworks.
The good news is that this fixes my original problem - but obviously the framework has to be in the same directory as the executable.
So this got me unstuck but I'd still love to know how to compile RegexKit.framework statically!
You shouldn't be installing the framework in the Executable folder of your bundle. It should be in the Frameworks folder. You need a Copy Files phase in your project that copies the framework and you need to set the Destination to "Frameworks". "Copy only when installing" should be unchecked.
When testing this, you should make sure you perform a clean build. I typically delete the build folder rather than using Xcode's Clean menu option since it's quicker and more comprehensive.
Also: you cannot statically link to a framework. If you want to statically link to something, it needs to be a static library so in this case, you'd need to hack about with RegexKit. Bear in mind that static libraries cannot contain resources, whereas Frameworks, being bundles, can.