I try to use openSSL on a app but I get a parse issue on the following line (in the rsa.h header file)
int (*rsa_mod_exp)(BIGNUM *r0,const BIGNUM *I,RSA *rsa,BN_CTX *ctx);
error is : parse error expected ')'
Using XCode 5 on OSX 10.9 and openssl-1.0.1e
What can be the issue?
Thanks for your help.
For anyone who sees this in the future, it's an amazingly simple solution: on the line quoted in the question, just change BIGNUM *I to BIGNUM *i. (That is, change the capital "I" to lowercase "i".)
Recompile, and everything should work! I have no idea why that works, but I trusted the interwebs and once again my faith was rewarded.
It could be all sorts of things, either in the header or in the file before the point the header is included. If by looking at the region of source around the point it is not obvious you can try preprocessing the file.
In Xcode select Product -> Perform Action -> Preprocess "file" and you'll get an editor window containing the source the compiler actually sees after file inclusion and macro expansion. In that locate the point of the error, look around, and work backwards if needed, untill you spot the problem.
Related
I'm attempting to import my "-Swift.h" file into one of my Objective-C .h files but xcode keeps telling me that the file doesn't exist
#import "Aesculus-Swift.h"
If I command click on the file name it will take me to the generated header file so I know it exists. Why is xcode not able to find it?
This seems like just another issue with Xcode and it's complex tool chain of static analysers and compilers.
Openradar lists radar://21362856 - Swift to Objective-C bridging is unreliable. I am sure there are more but I stopped looking after finding one for this example.
The author imarcelv notes in the description:
I asked a Swift engineer at WWDC in a lab and even he didn't know how to fix this issue.
Steps to Reproduce:
Add a ramdom Swift class to an Objective-C project
Add the #import "ModuleName-Swift.h" file that Xcode generates automatically
Try to use it or just try to compile the project
From time to time it simply doesn't work
It's probably best to file a radar on this issue as it seems that others are already calling it out.
One other thing you could try...
Historically, it was possible for Xcode to completely lose it's syntax highlighting and you could always find out what files the static analyser was giving up on by increasing log level of clang.
I'm not sure if it's still relevant but if I was in your position I'd be trying this command:
defaults write com.apple.dt.Xcode IDEIndexingClangInvocationLogLevel 3
This generates logs you can search with using Console.app for just xcode to highlight the messages. You'll want to trash the derived data of your project to force it to re-compile things.
Although not the same issue as what you're seeing, I have had this post on the syntax highlighting issue bookmarked for years for the above defaults write command to try in times like these.
I solved this recently by adding the following entry to my .xcconfig (you could add it in Xcode's Build Settings > User Header Search Paths if you prefer).
USER_HEADER_SEARCH_PATHS = $(BUILT_PRODUCTS_DIR)/MyFramework.framework/Headers
This tells the compiler to search for headers in the build output directory, which is where Xcode puts the generated header (at least in the case of this framework).
In my case this is a directory like ~/Library/Developer/Xcode/DerivedData/MyProject-LongCode/Build/Products/Debug-iphonesimulator/MyFramework.framework/Headers/MyFramework. You might find your generated header in there too.
Xcode's header and dependency management is a hot mess, and it's not surprising that it doesn't work for you.
I had trouble with this stuff & found that your -Swift file is the Product name of your Target ( not just the name of your Target ) . I found the details here helpful: http://ericasadun.com/2014/08/21/swift-calling-swift-functions-from-objective-c/
When you encounter such situation, just find your kinda "ProductName-Swift.h" file by just cmnd+click on it (even if xcode shows warning about it is not found, the #import "Aesculus-Swift.h" string is still clickable) and then in opened code editor window choose context menu and "Show in Finder" item, then explicitly add it to your project.
Whenever I try to read the frame of an UIView for example while debugging, I get this error:
error: property 'frame not found on object of type 'UIView *'
error: 1 errors parsing expression
After searching for a solution, I found out that I can use this command to solve this without adding (annoying and in some cases complicated) casts:
expr #import UIKit;
But I still find it annoying to have to do this every time (why doesn't Xcode do this by default?!), so I thought I should be able to do this using the .lldbinit file, but I couldn't get it to work.
I don't know much about that file, I have this in it atm:
command script import /usr/local/opt/chisel/libexec/fblldb.py
so I tried adding the UIKit import command at the end of the file but it didn't look that it worked. I also tried prefixing it with command to no avail. Is this possible or not? (please say yes; it will save my life)
lldb will auto-import modules that the debug info tells us the program imports fairly soon now. All the pieces weren't in place to do that for the first Xcode 7 releases.
Statements in the .lldbinit get run before the main file is read in, it is supposed to help set up the environment to read in your program. But at that point there's nothing into which to import these symbols. You need to do it after the main binary is read in (and you really need to do it after you have run, since I think we need to run some code to do this.)
At present, the simplest way to do this is to make an auto-continue breakpoint at main, and attach the expr #import UIKit statement as a debugger command in that breakpoint. You'll have to do this once per new project you make, but if you're working on the same project for a while, it's not such an inconvenient workaround.
I had a project that was working for almost a week then suddenly all my .h files lost code completion/syntax coloring.The only changes i could think of was i changed my target's name and then when i created a new set of .h and .m files this started.
Okay I have checked everything on this topic which was commonly an issue in xcode 3 and 4, i tried all solutions like
Clean/rebuild/restart Xcode
Remove Derived Data
Precompile Prefix Header to No
Add "$(SRCROOT)/**" to header search path
Nothing has worked, any help would be appreciated.Also my Xcode version is 6.1.1.
Try these Solutions:-
You can able to fix that issue by change build settings like this, PreCompile Prefix Headers :NO
I've been doing this, and it's worked multiple times for me (after trying all of the above previously).
Now I just hit space, backspace (the mac version) and rebuild... works nice. Then, remember to scroll (sometimes the colors don't show up until you scroll somewhere)
Find your prefix file: "ProjectName_prefix.pch".
Comment out some line. (basically change it)
Build your project, doesn't matter if it fails or not.
Uncomment it.
Build again.
I'm betting only step 2 (modify the prefix) is what does it, but these essentially get you back to running. Suddenly everything magically recolors itself and completes functions.
Good luck if that doesn't fix it, perhaps try doing this to your dependency pch files (three20 or FB api's)
Okay I found out what the problem was, in my case i had changed the target name and in the process the project name also.
This resulted in the change of path of the prefix header when actually the file was still at the old path. Changing it to the old path fixed the problem.
The prefix header path can be found in Build settings.
usually something like ProjectName/Prefixfilename.pch
When debugging ExtJS 4 (tried both versions 4.1.0 and 4.1.1), FireBug repeatedly shows the following error: An invalid or illegal string was specified
http://docs.sencha.com/ext-js/4-1/extjs/ext-all.js
Line 18. It does not break on the error, though that option is specified. Additionally, neither my code or ext-debug.js and it's loader seem to actually call ext-all.js.
This error gets logged to Firebug's console about once per minute, which is annoying. What bothers me is that I cannot get the error to go away. Is this a FireBug bug? An ExtJS bug? Aliens? How can I debug the debugger?
I had the same problem before and I've solved it by removing a special character at the end of my JS file! (app.js I think)
It was weird, but the problem came from hidden special characters like: Zero-width non-joiner or Right-to-left mark.
Open another JS file but do not copy/paste your code there. Just write it again and check whether the problem exists or not.
And don't forget to check your data if you have some. As this article explains about the problem: http://www.ashorlivs.fr/javascript-jquery/article/an-invalid-or-illegal-string-was
For general debugging see this link http://www.sencha.com/learn/debugging-ext-js-applications/
You can also use ext-all-dev.js while in development mode.
There is another excellent tool on top of firebug, at this link http://www.illuminations-for-developers.com/
PS: I still didn't figured out how to post a comment. I guess it comes when I have more points/reputation. Hence adding it as an answer. thanks.
I'm using a static lib thats giving me a warning when uploading my binary for review by apple.
The method in the static lib that causes the warning(non-public selectors) is never called by me, its corresponding .h is deleted from my proj, but warning still persists.
Given that I know the method name causing the problem, is there a way for me to open/edit this .a and comment/delete the offending piece of code and then use the modified .a in my project.
I don't have access to the .a source to recompile it, and its very old and the creator of it has no contact details for me to track down.
Many Thanks,
-Cake
Quick and dirty solution: Open the .a file in a hex editor and change all instances of the name. Leave the function name the same length so that offsets in the file don't change, just change a letter or something like that. I did a quick test, adding a dummy function to a subproject we're building as a static library then tweaking the function name in the .a file (there were five instances, for what that's worth) and everything built okay. I don't see any reason it wouldn't pass the App Store check after that.
I'm really surprised the function was still there in the final build, though—I thought Dead Code Stripping was supposed to clean out any unused code. Huh.
http://opensource.apple.com/source/cctools/cctools-809/
I don't presume to get your bounty, because I haven't provided an easy solution. But yes, it in theory is possible. You have your work cut out for you.
There are several solutions, depending on your lib and project.
In your build settings :
Enable "dead code stripping" if possible : If the method is never used (even internally), the symbol will be deleted.
Use "Unexported symbol file" : Simply add the symbol into a file and it will be removed from the binary. This will work even if the symbol is used internally.
Enable "Deployment Postprocessing" and "Strip Linked Product" with "Strip Style" set to "All symbol"
(Not sure) Use "Symbols Hidden by Default". This is related to the code generation and should not affect linking, but just in case everything above failed...
No need to hack the binary files. Just turn off the compiler's "unused selectors" warning: -fno-unused-selectors.