I'm new to programming in Objective-C, though I do have some experience in Python. I wrote this (what I thought would be simple) program:
#include <stdio.h>
int main(){
printf("hello world\n");
return 0;
}
But when I click run in Xcode it gives me this error:
Command /Developer/usr/bin/clang failed with exit code 1
I don't know what I did wrong and was hoping someone could help. It executes from the command line but not from Xcode.
Like other commenters here, I can't see any direct problem with your code, so maybe you could get it to work if you start from a clean project template.
In Xcode, choose New Project, type Command line tool
You can select either straight C or Objective-C. The latter will give you an autorelease pool that you don't need for a Hello World program, but it doesn't harm, either.
Then type your code (printf("Your text\n")) into the main function and compile.
It should work.
Related
New version of cppcheck found two major code smells named "syntax error" in following old lines of code:
System::Reflection::Assembly^ Foo(Object^ /* obj */, System::ResolveEventArgs^ args)
{...}
and
catch (System::Exception^ /*e*/)
Errortext:
Cppcheck cannot tokenize the code correctly.
Any idea how to fix them? Is something wrong with the C++/CLI syntax?
It looks like a false positive for me, as the code compiles and works for a long time.
Any idea how to fix them?
There is nothing you can do. C++/CLI is a dialect of C++, it is not standard C++. cppcheck works only with standard C or C++, so it will fail to understand C++/CLI code and thus give you the diagnostic you see. You'll need to exclude the source files that use C++/CLI code from your cppcheck check to avoid these errors.
I have the following stupidly simple test case (defined in a .mm file with correspong .h file). It uses boost to try to read in a ptree from a stringstream to simulate the text that would be in a file.
-(void)setUp {
printf("setup\n");
::std::stringstream ss;
ss << "bad format text";
_configuration = new ptree();
::boost::property_tree::read_json(ss, *_configuration);
}
The tearDown function does nothing, and there is one test case, which also does nothing. If I comment out the read_json line, everything works fine. But if I run it as is, I get:
Test Case '-[TestPlanner testPlanner]' started.
libc++abi.dylib: terminate called throwing an exception
/Applications/Xcode.app/Contents/Developer/Tools/RunPlatformUnitTests.include: line 415: 3320 Abort trap: 6 "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}"
/Applications/Xcode.app/Contents/Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/Developer/usr/bin/otest' exited abnormally with code 134 (it may have crashed).
The really crazy thing is that if I set a breakpoint in the SetUp function, it doesn't even run! And this is the only test enabled, so without even running a single line of a single test, something crashes. I know the test is set up correctly, because if I comment out the read_json line and set a breakpoint, it does get reached, and I can include some asserts in the test case and they work as expected.
It's not just a boost problem either. I originally encountered this when calling a different library from my own project, but to simplify everything I went down to just this boost call. This exact same call is happening in other parts of the code, so I'm pretty sure I have boost linked in correctly. I was super verbose with namespaces, so I don't think I'm linking the wrong version of a function or something.
I'm running XCode 4.5 (but have the same problem on 4.4.1) and trying to write Unit tests using OCUnit. The project I am working on already has a few unit tests written in this framework and everything with those tests seems to work fine.
I'm new to Objective C and XCode but the guy who set this project up definitely isn't and he couldn't see any problem with what I was doing and we were both totally stumped.
Thanks for reading! Let me know if you need any more info.
It turns out OCUnit barfs if it gets a C++ exception, and for some reason, XCode (or maybe lldb) doesn't properly trigger the breakpoint. The SetUp code is running, the debugger just isn't working. Adding a try/catch block or changing the code to:
-(void)setUp {
printf("setup\n");
::std::stringstream ss;
ss << "{}";
_configuration = new ptree();
::boost::property_tree::read_json(ss, *_configuration);
}
Doesn't cause an exception and makes everything work.
So the workaround if you are seeing this problem is to make sure you try/catch everything in your test cases. Hopefully someone will come up with a better answer because this seems like a pretty big bug in OCunit.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
I'm trying to do ioctl command through Mono framework, but I cant find what I'm looking for.
I'm trying to send command to a DVB card that has a kernel module. I hope someone can link or explain clearly how this can be done. Any example with Mono using kernel modules would be useful I guess.
Mono does not contain a wrapper for ioctl in Mono.Unix, because ioctl call parameters vary greatly and such a wrapper would be almost useless. You should declare a DllImport for each ioctl you need.
You probably don't need a helper library written in C, however, you may need it during development to extract actual values hidden behind different C preprocessor macros. For example, to expand C header:
#define FE_GET_INFO _IOR('o', 61, struct dvb_frontend_info)
compile and execute this helper:
#include <linux/dvb/frontend.h>
#include <stdio.h>
int main()
{
printf("const int FE_GET_INFO = %d;\n", FE_GET_INFO);
return 0;
}
A short mono mailing list discussion on the topic.
ioctl isn't supported by Mono AFAIK. Too OS-specific and parameter list depends on actual request. You could try DLLImport
Interop with Native Libraries
You should write a wrapper library for your exact calls. Look at how Mono.Unix wraps syscalls (google codesearch for Mono.Unix Syscall.cs) to get the idea. Then create a wrapper for each specific ioctl command, which uses your own representation of the data.
As jitter said - you'll need to DLLImport the ioctl itself.
Check for my similar question, and later question on the subject. In this case I'm trying to wrap the Videl4Linux interface, that could be of interest for you.
I really suggest those readings.
when i was trying to build my project in MPLAB,i got this Build error message..
Clean: Deleting intermediary and output files.
Clean: Deleted file "M:\12 CCP PWM\12 CCP PWM.o".
Clean: Done.
Executing: "C:\MCC18\bin\mcc18.exe" -p=18F46K20 "12 CCP PWM.c" -fo="12 CCP PWM.o" -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
MPLAB C18 v3.20 (feature limited)
Copyright 1999-2005 Microchip Technology Inc.
This version of MPLAB C18 does not support the extended mode
and will not perform all optimizations. To purchase a full
copy of MPLAB C18, please contact your local distributor or
visit buy.microchip.com.
Executing: "C:\MCC18\bin\mplink.exe" /l"C:\MCC18\lib" "C:\MCC18\lkr\18f46k20i.lkr" "12 CCP PWM.o" /u_CRUNTIME /o"12 CCP PWM.cof" /M"12 CCP PWM.map" /W
MPLINK 4.20, Linker
Copyright (c) 2008 Microchip Technology Inc.
Error - could not find definition of symbol 'main' in file 'C:\MCC18\lib/c018i.o'.
Errors : 1
Link step failed.
----------------------------------------------------------------------
Release build of project `M:\12 CCP PWM\12 CCP PWM.mcp' failed.
Thu Apr 16 14:34:41 2009
----------------------------------------------------------------------
BUILD FAILED
I have checked that the path to the linker library was correct.I suspect it has something to do with my source code...Any helps are very much appreciated.
Here is my source code.. http://cl1p.net/mplabc18
The compiler may be looking for a different definition of main. I have seen this in some PIC code:
// Main application entry point.
#ifdef __C30__
int main(void)
#else
void main(void)
#endif
{ ... }
It is a good idea to add the specific linker file to your project. If you are using MPLAB, under the workspace, right click on linker files and add the linker file from mcc16\lkr folder for the specific processor.
Clean and Re-compile the solution
The only thing that stood out to me in your source file is this part of the ISR declaration:
#pragma code InterruptVectorLow = 0x18
The user guide of the compiler you're using states this should be:
#pragma code low_vector=0x18
Since this declaration is just before your main function it might be giving you trouble.
Edit:
None of the presented solutions seem to work so I have just copy-pasted your code into a new MPLAB project, set up for the PIC18F46K20 device. It compiles just fine with the MCC18 compiler. The only thing that's missing from the project is the "12 CCP PWM.h" header file (which I do not have). So either there's something wrong with your header file, there's something wrong with your project setup, or the fact that I'm using MCC18 3.30 instead of 3.20 is the problem.
code compiles fine for me (C18 3.30 full)
i've had MPLAB flake out a bit on me especially on large source trees, many times a reboot has solved it, absolutely no idea why, tried everything else and it was the only way to get mplab to reset.
Personally I would not strain the corners of the implementation by having source file names with several spaces in, particularly with an embedded toolchain!
But it seems like they're making a reasonable effort to add all the double-quotes, so maybe that's not a real problem.
Do you actually have a 'main' function in your code, and if so, exactly how is it defined?
I use a third-party compiler, so I can't offer any specific experience on that. But one thing I may suspect is that something in the code is causing the compilation to stop partway through. This can be an unterminated comment, or a function with a closing brace missing. Consider especially the #included files, because you can't see the effects in your editor when you look at the main file, and particularly check any #includes that you have written yourself. And at the top of the list is, "what did you change last"?
What I do at this point is make a branch copy, and start mercilessly hacking out huge blocks of code, just to see when the error goes away. Divide and conquer. Of course, this can be time consuming, so I'd probably ask on StackOverflow, first :)
It's been a while, but I saw that you used a pragma to define the location of the interrupt handler before you created the function, might you need to do the same thing with main()?
It might be handled in the .h file - I'm not sure. I only ever used ASM on the PICs and I explicitly handled everything (ie, at 0x000 jump to main; at the interrupt vector address jump to this memory address; at main address do these things, etc). 'main' for me was defined to be an available address in the code section (which I see you've done, started the code section then defined main) but I believe I had to explicitly define that 'main' was to start at a memory address in the code section. Again, it was ASM, but I wouldn't doubt that you need to do something similar - a pragma to define main as main.
If c018i.o contains the reset vector, and it refers to the function main by name, then the issue could be that main needs a prototype - even in the same file as the function itself, so the linker can pick this up and put main in its list of functions.
So, try inserting:
void main (void);
immediately above the main function.