I read that the symbols list of an IOS app are in the .dSYM. I would like to view the entire list of symbols, do you guys know what tool do I need to use to extract this information from this package?
thanks
-Malena
You can use dwarfdump.
For example to see all public types in a dSYM-file for ARM64 architecture run:
dwarfdump --arch arm64 --debug-pubtypes YourFramework.framework.dSYM/
For more information check the man-page of dwarfdump. Using this command you can also extract strings, filter by name and address and more.
Related
I am attempting to write a kernel extension (kext) that uses some parts of the Kernel framework.
I added Kernel.framework to the list of Frameworks and Libraries in the target settings.
However, when I try to build my kext and link against it, Xcode refuses to do this and claims to not be able to find the framework, even though it had shown up in the list of available frameworks.
Am I doing this wrong? Is it not possible to use this framework even for kexts?
Edit: I am aware of the user space alternatives to kexts but these don't fulfill my needs.
The Kernel.framework is a header-only "framework". Kext linking is fundamentally different from user space executable linking, as there's no dyld. You don't need to link against any libraries at build time, but you must specify the KPIs to link against in the Info.plist file's OSBundleLibraries dictionary.
You can generate a draft of this dictionary using the following command:
kextlibs -xml -c path/to/your.kext
If using any unsupported KPIs, you'll also want to specify -unsupported. If it's complaining about symbols not being found, adding the -undef-symbols option will help with debugging.
Is there a way to specify iOS libraries to be linked while building an app from command line using xcodebuild command?
I know we can specify third party frameworks using OTHER_LDFLAGS="..path/to/framework" but since the built in framework paths may vary based on the machine/sdk etc, I'm assuming there could be some better way than that.
Thanks
xcodebuild builds project files, so typically you configure everything in the project rather than passing many configuration parameters. To link built-in frameworks, you just use the Link with Libraries build step and add the frameworks you want. Built-in frameworks should automatically be stored as SDK-relative. (Note that you should basically never use this to link relative-path libraries in your package; it is usually better to use OTHER_LIBTOOLFLAGS for those.)
The linker flag you want if you need it is -framework <name>. But you shouldn't need that very often when using xcodebuild. It's mostly used when calling clang or ld directly.
I'm working on an OS X application using a third-party framework. This framework is distributed both as shared objects and static objects. For my purposes, I want to use the static objects because I can't rely on the presence of the library on other systems.
However, when I build the application with Xcode, something decides it needs the shared objects, and when I run it, dyld tells me off before I even get to my program:
dyld: Library not loaded: /usr/local/lib/libshared.dylib
Referenced from: /Users/me/Library/Developer/Xcode/snip/Application.app/Contents/MacOS/Application
Reason: image not found
I ran otool -L on the executable, and sure enough, it tried to link against the shared objects (which aren't even installed on my system). However, when I ran it on the thirty-some .a files that I link against, none of them indicated any dependency on them.
Apple's ld -v is just a tad verbose: it displays the library search paths but doesn't produce any other kind of useful output.
How can I find what tried to link against the shared objects?
otool -L does list the libraries against which any object links.
This specific instance was caused by an Xcode bug (known as rdar://2725744 to the ones blessed with Apple bug database access, and not fixed as of Xcode 6.1.1) where if you try to link against a .a static library with Xcode but there's a .dylib (or .so) dynamic library with the same name in the same directory, the linker will pick the dynamic one.
When you instruct Xcode to link against a static library (say /some/path/to/my/libFooBar.a), it adds -L/some/path/to/my -lFooBar to the linker invocation. However, with it, ld first searches for a dynamic library called libFooBar.dylib, and it will fall back to the static library only if it can't find the dynamic one.
If you added the framework is listed in the "Build Phases" of "Link Binary with Libraries" and it has the setting of "Required" that could explain why the launch fails.
Try changing the setting to "Optional". Then if nothing uses the framework, it should launch fine. (If something tries to use the framework, but fails to check for it first, it might crash.)
Why is it that some static libraries (lib*.a) can be linked in the same way that shared libraries (lib*.so) are linked (ld -l switch), but some can not?
I had always been taught that all libraries, static or not, can be linked with -l..., however I've run into one library so far (GLFW), which does nothing but spew "undefined reference" link errors if I attempt to link it this way.
According to the response on this question, the "proper" way to link static libraries is to include them directly, along with my own object files, rather than using -l. And, in the case of the GLFW library, this certainly solves the issue. But every other static library I'm using works just fine when linked with -l.
So:
What could cause this one library to not work when linked rather than included directly? If I knew the cause, maybe I could edit and recompile the library to fix the issue.
Is it true that you're not supposed to link static libraries the same way you link shared libraries? (And if not, why not?)
Is the linker still able to eliminate unused library functions from the output executable when the library is directly included in this way?
Thanks for the replies! Turns out the problem was due to link order. Apparently, if you use a library which in turn has other library dependencies, those other dependencies must be listed after the library, not before as I had been doing. Learned something new!
Have you cared to indicate to GCC the path of your library (using -L) ? By using -l solely, GCC will only be able to link libraries available in standard directories.
-L[path] -l[lib]
The correct way to link a static library is using -l, but that only works if the library can be found on the search path. If it's not then you can add the directory to the list using -L or name the file by name, as you say.
The same is true for shared libraries, actually, although they're more likely to be found, perhaps.
The reason is historical. The "ar" tool was original the file archive tool on PDP11 unix, though it was later replaced entirely by "tar" for that purpose. It stores files (object files, in this case) in a package. And there's a separate extension containing the symbol table for the linker to use. It's possible if you are manually managing files in the archive that the symbol table can get out of date.
The short answer is that you can use the "ranlib" tool on any archive to recreate the symbol table. Try that. More broadly, try to figure out where the corrupt libraries are coming from and fix that.
On Mac OS X, binary executables in the DYLD format contain "loader commands" that instruct the library loading system how to handle the contents of the file. In particular, the loader command instruct the system where dependent libraries should be searched for, etc.
You can see the complete list of loader commands for any binary on your system by running "otool -l /path/to/your/app".
Generally speaking these loader commands are set by the "ld" tool during the link phase of a project's compilation.
My question is, what do I need to do to add loader commands for publicized types that are not supported (apparently) by ld?
In particular, I would like to take advantage of the LC_DYLD_ENVIRONMENT loader commmand, which can be used to specify a string in the loader commands table of a binary that should be loaded and evaluated as environment variable settings in the context of the executable.
I don't see any argument to ld that would facilitate this. Something like "-sectcreate" but for specifically adding to the content of the loader commands, is what I'm after.
I know this is possible because at least one standard app on Mac OS X uses it: Safari. But I don't know whether they achieve this by some kind of post-link massage of the binary, if they're using a custom version of ld that knows how to build and chain the custom loader command in, or if they are exploiting a general-purpopse feature of the ld command that I haven't been able to figure out.
It looks like you can use -dyld_env, like so: "-dyld_env DYLD_FRAMEWORK_PATH=/". This isn't documented in the man page, but can be found in ld64's Options.cpp and mentioned in the Changelog file. If you're trying to do it from Xcode, you'll probably have to do it like this: "-Xlinker -dyld_env -Xlinker DYLD_FRAMEWORK_PATH=/".
One thing to note: if you look at dyld's dyld.cpp, you'll see that it only allows environment variables that start with DYLD_ and ends with _PATH.
If your executable is structured as part of a standard OS X application bundle (i.e. a .app that can be launched by a user), the conventional way to specify application specific environment variables is through its plist file using the LSEnvironment key. See here for more information.