Compiled iOS apps have localized strings files compiled into binary PList files and they are converted by Xcode.
Is there any way to compile them from command line from the original strings files?
I think I found what I was looking for:
plutil -convert binary1 Localizable.strings
plutil it is.
The build task is here /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/CopyStringsFile.xcspec
It runs copystrings ruby script, which is based on iconv and plutil
Related
I use Eclipse + ARM plugin to build my projects. When I needed to use in my project the StemWin library, I configured my IDE to use external library.
I set
Preferences -> C/C++ General -> Paths and Symbols
I added in "Library Paths" the link to my folder includes library.
I also added the name of my library in tab "Library".
I checked the settings in the compiler tab and I ascertained all should be good.
When I tried to build my project I got an error from linker:
cannot find -lMyLib.a Hello C/C++ Problem
I double checked the name of my library and link, all are correct. This is the output of my linker:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib"
-T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,
-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" -lMyLib.a
What should I do from here?
I faced the same problem before.
-l:STemWin526_CM4_GCC.a
-L"C:\Edu_Workspace\STM32F4\stm32f4_bsp_template\Drivers\Middlewares\ST\STemWin\Lib"
Above are my working settings.
With -l:<archive file name> the colon : is important for archive file linking.
And -L will contain library path.
Also for stemwin make sure to compile with hardware floating point
-mfloat-abi=hard -mfpu=fpv4-sp-d16
the convention for the -l option of the linker (say you give -lMyLib.a as a linker option) is to search for a library file with "lib" prepended to the given name and .a (or .so) appended, i.e. your command line searches for a file libMyLib.a.{a,so} which is probably not how it's named.
Either you rename your library according to this convention or give it to the linker command line omitting -l (provided your IDE allows you to do so).
Looks like the problem is in -lMyLib.a which means you're trying to link a static library as a dynamic one.
To link a static lib you have to use its path as with ordinary .o files: ... /path/to/MyLib.a
and the resulting command line should look something like
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib" -T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" /path/to/MyLib.a
UPDATE:
Although it might fix the issue, turns out it's not true:
-llibrary
-l library
...
Normally the files found this way are library files—archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
(https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html)
During the build and archive of my application the .strings files are copied into the application bundle, e.g.
CopyStringsFile
/Users/Systems/Library/Developer/Xcode/DerivedData/MyProject-dqtbpsfqkwnliuflrsytopqbuvpr/Build/Intermediates/ArchiveIntermediates/Evolve/InstallationBuildProductsLocation/Applications/Evolve.app/en.lproj/InfoPlist.strings
MyProject/en.lproj/InfoPlist.strings
cd /Users/Systems/luke/repos/MyProject/MyProject
setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
builtin-copyStrings --validate --inputencoding utf-8 --outputencoding binary --outdir /Users/Systems/Library/Developer/Xcode/DerivedData/MyProject-dqtbpsfqkwnliuflrsytopqbuvpr/Build/Intermediates/ArchiveIntermediates/Evolve/InstallationBuildProductsLocation/Applications/Evolve.app/en.lproj
-- MyProject/en.lproj/InfoPlist.strings
Unzipping the ipa and loading the string file into a text editor shows the binary content.
I would like to use bash to read the content of the strings file in ASCII UTF-8, find and replace some strings and encode it into binary again.
Specifically, how should I decode the contents of the file into ASCI?
It turned out it was a super simple bash command:
plutil -convert xml1 <PATH_TO_STRINGS_FILE>
And to convert it back again:
plutil -convert binary1 <PATH_TO_STRINGS_FILE>
MacOS version: 10.7.2 (Lion)
Doxygen version: 1.7.5.1
Graphviz version: 2.29
Doxygen configuration:
DOT_PATH = ../../../../Applications/Contents/MacOS/Graphviz
HAVE_DOT = YES
SHORT_NAMES = YES
From the log console, first line it gives a warning:
warning: the dot tool could not be found at ../../../../Applications/Contents/MacOS/Graphviz
I have tried various combinations but the warning does not go away, although it does generate the images.
Generating dot graphs using 9 parallel threads...
Running dot for graph 1/68
sh: dot: command not found
Problems running dot: exit code=127, command='dot', arguments='"/Users/salilk/Documents/project/DoxygenDocs/html/a00033.dot" -Tpng -o "/Users/salilk/Documents/project/DoxygenDocs/html/a00033.png"'
In the html directory the .dot files have been generated but no .png.
Now if I execute the same command from the Terminal the .png file gets generated and is displayed in its .html file.
Another error from the console is:
error: problems opening map file /Users/salilk/Documents/A2O Collaborate/DoxygenDocs/html/a00032.map for inclusion in the docs!
If you installed Graphviz/dot after a previous failing run, try deleting the output directory and rerun doxygen.
Is this related to the above problem ?
I have used Doxygen before on a Windows machine and didn't have these errors, do we need to do any configurations specific for Mac?
Set the DOT_PATH to: /usr/local/bin
set DOT_PATH in your doxygen.conf to blank. That works because doxygen will look in your path for.
I installed doxygen with macports, so dot is at /opt/local/bin/dot
For those who call CMake's configure_file() on their Doxfile, an alternative is:
DOT_PATH = ${DOXYGEN_DOT_PATH}
For me, even though dot's path was in $PATH, the above is the only way I could make it work. Go figure.
The DOT_PATH must be set withing quotes else the paths with whitespaces won't work
DOT_PATH = "#DOXYGEN_DOT_PATH#"
I have a FAT .a archive on my Mac (a library) and I just wanted to know how I could extract the files from it?
lipo input_file -extract architecture -output output_file
This is for extracting a single architecture of a Universal Binary archive. Not sure if this helps, though.
I've been working on an iPhone application had an issue where dSYM file generation was seg faulting on me.
GenerateDSYMFile /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app.dSYM /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app/NodeAppGen
cd /Users/kaom/Projects/Apps/NodeAppGen
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/usr/bin/dsymutil /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app/NodeAppGen -o /Users/kaom/Projects/build/Release-iphoneos/NodeAppGen.app.dSYM
Command /Developer/usr/bin/dsymutil failed with exit code 11
I tracked this bug down to an error in the application's Info.plist file.
Instead of
<key>CFBundleVersion</key>
<string>1.0</string>
I had
<key>CFBundleVersion</key>
<real>1.0</real>
To my knowledge, dSYM file generation is only dependent on the executable and the plist file should not affect the executable. So my question is why did this break dSYM file generation?
Look for an error earlier in the build log, possibly one that didn't actually get parsed out as an explicit error by Xcode.
More likely than not, something was chomping on the Info.plist and was mighty confused to find a <real/> instead of a <string/> value.
In any case, file a bug via http://bugreport.applec.om, as having the dev tools produce a useful error message is always desirable.