Using xcode 6 and including files with names like Some$$Class.h and Some$$Class.m leads to problems. Xcode shows to error:
clang: error: no such file or directory: '/Users/test/Some$ClassX.m'
clang: error: no input files
How can I force Xcode to handle files with $$in its name correctly?
There is a very! dirty hack.
If you look to the error message, you can see that the build process of Xcode replaces the $$ of Some$$Class.m with a single $. (Obviously there is no problem with Some$$Class.h) It is an escape sequence.
Some$$Class.m -> Some$Class.m
Therefore you can use Some$$$$Class.m to get Some$$Class.m.
Simply add an (empty) File with the name Some$$$$Class.m to your project to show Xcode that it exists. You have to do this once.
Generate your Some$$Class.m as you did as many times as you want.
When building Xcode will believe that it compiles and links Some$$$$Class.m, but in fact compiles and builds Some$$Class.m.
But you should really, really avoid these names. If the files are generated automatically it should be possible to rename them automatically.
Related
I'm using the nativescript-google-maps-utils plugin in a NativeScript JavaScript project to access GoogleMapsUtils functions (GMSGeometryDistance, GMSGeometryInterpolate, and GMSGeometryHeading) so that I can traverse a polyline. The Android equivalents work fine on Android devices, and the iOS functions listed work on an iOS simulator, but on an iOS device I get the exception,
ReferenceError: Metadata for "GoogleMaps.GMSGeometryDistance" found but symbol not available at runtime.
I've been chasing this for the better part of a day and still don't have any leads; I'd welcome any insight.
[edit]
It's worth mentioning I've done the usual removal of the platforms, hooks, and node-modules folders and rebuilt, with no change in the error.
Here's the first line of code that triggers the error:
let lineDistance = GMSGeometryDistance(latlngs[i], latlngs[i + 1]);
[edit 2]
Still chasing this... I gather from this issue that I need to create a file with a list of exported symbols, and this issue kind of suggests how that could be done, but I'm not understanding how that applies to this situation.
That is, the question at hand now is how can I determine the symbols from the iOS GoogleMapsUtils static library? This is becoming more of an iOS and Xcode question that NativeScript or JavaScript.
[edit 3]
Sigh... I did get this working using the answer I provided below, but now that same approach is no longer working. No idea why :-(
[edit 4]
I re-reviewed the links I referenced above and included the STRIPFLAGS option and now the code works properly. I revised the answer to include this, and to edit build.xcconfig rather than the project file.
After another day's investigation I was able to get this working. Here's what it took.
Navigate to /platforms/iOS/Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.framework/
Run nm --defined-only GoogleMaps | grep " T " | cut -f 3 -d' ' | egrep -v '^$|GoogleMaps'
Notice the names of the symbols. In my case each one I needed was the function name prefixed with an underscore
Create the file exportedSymbols.txt in /app/App_Resources/iOS
Add the symbols to the file. In my case the contents is:
_GMSGeometryDistance
_GMSGeometryHeading
_GMSGeometryInterpolate
Edit the file app/App_Resources/iOS/build.xcconfig and add these two lines
STRIPFLAGS=$(inherited) -s {PROJECT_DIR}/../../app/App_Resources/iOS/exportedSymbols.txt
EXPORTED_SYMBOLS_FILE = ${PROJECT_DIR}/../../app/App_Resources/iOS/exportedSymbols.txt
So far this is working in my tests on both iOS simulators and devices.
:0: error: filename "SurveyViewController.swift" used twice: '/Users/raeessamman/Downloads/fwdsurver/SurveyViewController.swift' and '/Users/raeessamman/Desktop/IOS Development projects/SammanMRA-cobsccomp191p-036/NIBM COVID19/NIBM COVID19/Controller/SurveyViewController.swift'
:0: note: filenames are used to distinguish private declarations with the same name
Command CompileSwiftSources failed with a nonzero exit code
search with this name "SurveyViewController" in your project
you will find that you declare it twice. you must change or delete one of them.
if you didn't find it you must search in "project.pbxproj" file and you will find two paths with the same name.
to open the "project.pbxproj" file you should go to "YourApp.xcodeproj" then you double click in it, menu will open select "show package contents" then you will find 2 files one of them is "project.pbxproj".
Whenever I try to 'Export For Internationalization', the exported file contains a weird hidden character, making it unparsable for XLIFF editors. The problem seemed to be in the original .string files, somehow the weird character was inserted in those files. I have since deleted the weird character but whenever I export it still sneaks into the xliff file. I tried cleaning and rebuilding the project, restarting Xcode... none of that seems to work.
Is Xcode somehow using a cached version of the 'bad' .strings file containing the bad character?
Using Xcode
If I try Editor > Export For Localization
I get:
/usr/bin/xmllint exited with status 1
Using Terminal
When I run it from Terminal like so:
xcodebuild -exportLocalizations -localizationPath
/Users/Kymer/Downloads/Wolf -project Wolf.xcodeproj -exportLanguage fr
I get the following errors:
parser error : attributes construct error
parser error : Couldn't find end of Start Tag trans-unit
parser error : PCDATA invalid Char value 19
parser error : PCDATA invalid Char value 19
parser error : Opening and ending tag mismatch
parser error : invalid character in attribute value
parser error : attributes construct error
parser error : Couldn't find end of Start Tag
parser error : PCDATA invalid Char value
/Uxcodebuild: error: /usr/bin/xmllint exited with status 1
In both cases the exported xliff file contains the weird hidden character upon inspection with Sublime Text:
If I manually remove the bad characters the file is perfectly readable by xliff-editors but that's not a good long-term solution of course.
I found the problem: when exporting to an XLIFF file Xcode doesn't look at your .string files, it is all generated from the project itself (i.e. it looks at all NSLocalizedString calls and your storyboards). Which makes sense. I found the weird hidden character in one of my code files. Removing it from the source file fixed the export issue.
Easiest XLIFF workflow
I'll also mention this for future reference: the easiest way to add a new language to your project is to first use the command line:
cd to the your project and run:
xcodebuild -exportLocalizations -localizationPath <path> -project <projectname>.xcodeproj -exportLanguage <language code>
That creates a new XLIFF file and will correctly set the target language in the file (source language will be your base language). A translator can now easily add all necessary translations. Afterwards you can import the translated XLIFF file back into Xcode (select target and Editor > Import localizations). Xcode will then generate all necessary .string files.
Updating existing language: If you add new UI elements and want to update an existing localization language, you can simply export an existing localization (select target and Editor > Export for localization). That XLIFF file will contain all previous translations together with the new strings. A translator simply has to fill in the 'blank' lines. There's no need to touch the .string files yourself, because managing that manually is a pain (especially with the crazy Storyboard ID's).
I have something like
NSLocalizedString(#"key",
#"comments in "
#"multiple lines")
in one of my files and when I attempt to export the project that contains the file via
xcodebuild -exportLocalizations -localizationPath <dirpath> -project <projectname> [[-exportLanguage <targetlanguage>]]
I get an error message like this:
Bad entry in file <file_name>.m (line = 35): Argument is not a literal string.
In my experiment, this issue goes away when I make the comment a single line literal.
Has anyone experienced a similar problem and knows more about what is going on here? Xcode's other tool for localization, genstrings, seems to handle this fine.
I need to include a binary program in my project. I use objcopy to create an object file from a binary file. The object file can be linked in my program. objcopy creates appropriate symbols to access the binary data.
Example
objcopy -I binary -O elf32-littlearm --binary-architecture arm D:\Src\data.jpg data.o
The generated symbols are:
_binary_D__Src_data_jpg_end
_binary_D__Src_data_jpg_size
_binary_D__Src_data_jpg_start
The problem is that the symbols include the path to the binary file D__Src_. This may help when binary files are included from different location. But it bothers me that the symbols changes when I get the file from a different location. Since this shall run on several build stations, the path can't be stripped with the --redefine-sym option.
How do I get rid of the path in the symbol name?
I solved this problem by using this switch in objcopy:
--prefix-sections=abc
This gives a way to uniquely identify the data in your binary object file (ex. binary.o)
In your linker script you can then define your own labels around where you include the binary.o. Since you are no longer referencing anything in binary.o the binary will be thrown out by the linker if you use -gc-sections switch. The section in binary.o will now be abc.data. Use KEEP in your linker script to tell the linker not to throw out binary.o. Your linker script will contain the following:
__binary_start__ = .;
KEEP(*(abc.data))
binary.o
*(abc.data)
. = ALIGN(4);
__binary_end__ = .;
The switch --localize-symbols works for me.