mac os 10.13.4
I write the command 'dyldinfo' in shell, but is wroing
-bash: dyldinfo: command not found
hope you help me
On recent versions of macOS you can run the tool with xcrun dyldinfo (as long as you have Xcode installed)
First, make sure you have either Xcode or Command Line Tools installed.
If you have one of those, you can find dyldinfo in /Library/Developer/CommandLineTools/usr/bin.
So, to run it, type this into your bash:
/Library/Developer/CommandLineTools/usr/bin/dyldinfo
You can check the dyldinfo path using following command:
$ xcrun --sdk dyldinfo
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dyldinfo
Showing that the command dyldinfo is under the path:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dyldinfo, which means commands like dyldinfo belong to Toolchains of Xcode. Therefore, 'dyldinfo' cannot be used as a separate shell command. Instead, you must invoke it by using xcrun <sdk>.
$ xcrun dyldinfo
Usage: dyldinfo [-arch <arch>] <options> <mach-o file>
-dylibs print dependent dylibs
-dr print dependent dylibs and show any recorded DR info
-rebase print addresses dyld will adjust if file not loaded at preferred address
-bind print addresses dyld will set based on symbolic lookups
-weak_bind print symbols which dyld must coalesce
-lazy_bind print addresses dyld will lazily set on first use
-export print addresses of all symbols this file exports
-opcodes print opcodes used to generate the rebase and binding information
-function_starts print table of function start addresses
-export_dot print a GraphViz .dot file of the exported symbols trie
-data_in_code print any data-in-code information
Related
I am trying to automate performance testing using Xcode 12 Instruments developer tool and need some help.
I want to parse .trace file into readable format and want to print leaks/CPU usage on console. I am using below xctrace command line to automate leaks/Time Profiling with Xcode 12 Instruments tool:
xcrun xctrace record --device "udid" --template "Leaks" --time-limit 10m --attach "PID" --output "xyz.trace"
xcrun xctrace export --input "xyz.trace" toc --output "xyz.xml"
Is would be really great if someone can help.
Trace file for reference: https://gofile.io/d/EpvOXa
I am not sure if I understood your problem correctly, but if I run your command, I received a an error message. The CLI-tool gave me the following instructions:
usage: xctrace export [<options>] [--toc | --xpath expression]
description:
Export given .trace using supplied query to the XML file format that can be later read and post-processed
options:
--input <file> Export data from the given .trace file
--output <path> Command output is written to the given path, if specified
--toc Present entities to export in the table of contents form
--xpath <expression> Choose elements to export using specified XPath expression
notes:
If output path is not specified, the export operation output will be written to the standard output.
Table of Contents and XPath query are two separate modes and they cannot be specified together.
examples:
xctrace export --input input.trace --toc
xctrace export --input input.trace --toc --output table_of_contents.xml
xctrace export --input input.trace --xpath '/trace-toc/run[#number="1"]/data/table[#schema="my-table-schema"]'
According to this, the parameter toc is missing the two dashes. I hope that will fix it for you.
I have 26 languages successfully localized and tested. I am able to successfully export all 26 localizations with option: "Editor" -> "Export for Localization...", then selecting all of them.
However, when I use the following xcodebuild command, it exports my default language "en", and nothing else.
xcodebuild -exportLocalizations -localizationPath TempLocalizationExport
How do I export all twenty-six Localizations rather than just "en"?
There are no command line errors outputted from the command.
I've seached everywhere for official xcodebuild commandline command documentation on developer.apple.com, and I can't find a verbose and helpful source that addresses additional -exportLocalizations options and standard behavior.
According to the docs:
To export localizations, enter this command in Terminal, replacing the
dirpath and projectname arguments:
xcodebuild -exportLocalizations -localizationPath <dirpath> -project <projectname> [[-exportLanguage <targetlanguage>]]
The exported XLIFF files are placed in dirpath. Optionally, use the
exportLanguage argument to export other localizations.
UPDATE:
The OP discovered that multiple languages can be exported by repeating the -exportLanguage argument. For example, this command exports two languages:
xcodebuild -exportLocalizations -localizationPath TempLocalizationExport -exportLanguage es -exportLanguage ru
Seems xcodebuild doesn't support auto export all localizations at this time.
But we can do it through Xcode interface.
Also it's possible auto select all localizations with a script. Read knownRegions section in project.pbxproj, loop to argument format.
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I'm running through some various programming/debugging tutorials and uses the "otool" command in terminal. An example is to check for shared libraries. The error is always one of two. I'm running it from the directory the file is located. Typing in just otool give the list of otool "-x" switches. I've gone down the list of switches on multiple files and directories and get the same errors.
What am I missing?
$ otool -L DemoApp
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: can't open file: DemoApp (No such file or directory)
or
$ otool -L DemoApp.app
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: can't map file: DemoApp.app (Invalid argument)
you need to point to a final executable file. DemoApp.app is just a directory. Try otool -L ~/Applications/DemoApp.app/Contents/MacOS/DemoApp
Is there a way to instruct C++ Builder's linker to output DWARF debug information (64-bit C++ apps) in standalone file rather than inject it directly into executable? I.e. the option similar to "Place debug information in separate TDS file" (which does not work for DWARF debug format).
If there is no such option - is there a way to strip info from already compiled executable?
To place debug info in separate file follow below steps
// Build
$ clang -O2 -g -o hello.full hello.c
// Package hello.stripped is run as "hello" in production environment
$ strip -o hello.stripped hello.full
// Extract debug info to separate file
$ objcopy --only-keep-debug hello.full hello.debug
// Create a section which contains a reference to debug file
$ objcopy --strip-debug --add-gnu-debuglink=hello.debug hello.full hello
// Debug - GDB automatically reads hello.debug
$ gdb hello
. . .
Reading symbols from ./hello...
Reading symbols from /homes/syrajendra/hello.debug...done.
(gdb)
// Core from hello.stripped
$ gdb --core core-file --exec hello
Assuming you are on a platform with GNU Binutils you can use objcopy to extract the DWARF information to a separate file as a post-compilation step. If you like you can then use strip to remove the debugging information from the executable binary.