When I used Xcode 4.6 preview verion or xcodebuild command, I had a such error below.
invalid suffix on literal; C++11 requires a space between literal and identifier
However When I used Xcode4, there were no errors.
I don't have much knowledge about C++ and the compiler, so I couldn't find the answer from Internet.
Would you tell me how can I avoid the error with xcodebuild command?
If you invoke xcodebuild from the cmd-line, it should be essentially the same as building the target from within Xcode's IDE.
The only difference that I can think of is that running from the cmd-line will default to Release configuration, whereas inside the IDE will probably use debug. (These can be overridden in both cases).
Could it be that you have a different C++ flags for Debug and Release, and this is making it not work? Try building your project with Release mode inside the IDE, and see what happens.
Related
I'm doing some experiments with an evaluation version of the WindRiver dcc diab compiler. I would like to do some testing on my Windows PC.
However I think I have the wrong target setup.
I've got as far as using the 'dctrl -t' command to get the list of target architectures, but selecting options so far hasn't produced anything i can run on windows.
I'm simply doing:
dcc main.c -o main.exe
Am I missing a step?
do I have the wrong target?
or is it simply not possible to create windows binaries?
I believe that the Diab compiler targets a free-standing environment, so would not produce a Windows executable. Moreover x86 is not a supported target processor in any case; see the product brief.
The compiler is intended for use with VxWorks, though can be separately licensed. The toolchain includes an instruction-set simulator for executing target code in a simulated environment, and if you are using VxWorks, that includes a VxWorks simulator.
If you want to build your code as a native Windows application; you will have to use a Windows targeted compiler. I suggest MinGW/GCC since WindRiver support both their own WindRiver/Diab compiler and GCC for Vxworks development, and they share a great deal of commonality with respect to compiler switches and extension syntax.
I have a C++11 codebase I compile with gcc 4.6 from MacPorts on OS X Lion. I also need to compile and link some OS-specific Objective C/C++ files to make the final executable. I would like to use the same compiler version to compile the whole project, but I cannot get the MacPorts version 4.6 of gcc to recognize Objective-C files; it always attempts to interpret them as C++ code and ignores the .mm file extension. (Compiling these files does work with the Xcode version of gcc, just not the MacPorts one. However that gcc is version 4.2 and I want to compile everything with gcc 4.6 or later.)
Forget IDE's or build tools: I get the same result from a commandline invocation of the compiler. That is, I record a commandline that works for compiling .mm files with the Apple gcc, verify yes it does work from the commandline, then run the identical command with nothing changed but the compiler used and it doesn't work. What am I missing?
It appears maybe the specific problem I'm having might be due to an Apple specific language extension, as the specific error I get is the same as this quote from a blog post:
After adding this, I was good for about 30 seconds until I get to the
portion of my project where some COCOA Objective-C UI stuff was being
compiled.
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:75:24:
error: expected unqualified-id before '^' token
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:75:24:
error: expected ')' before '^' token
Uh oh. I know what this is. This is the Apple "blocks" language
extension. It appears that blocks are used in a bunch of the system
header files. I don't think there is going to be a way to get around
this using MacPorts gcc. The FSF gcc just doesn’t know about blocks.
Fortunately for me, I didn't have anything in the Objective C/C++ code
that needed to be compiled with gcc 4.6 so I just had this target
compile using clang.
I'm running latest TextMate 1.5 (on OSX Lion) and have the latest XCode 4.3 installed.
I'm sort of taking the low road when learning Objective-C by bypassing XCode for start and doing plain samples and exercises using TextMate and command line. When hitting Cmd-R in TextMate the (console) something builds and runs typed Objective-C console program. However, it doesn't compile things that it should (from my POV) compile, since compiling them from command line with clang works fine. When I switch to building from command line I see that those same things fail when I use gcc instead of clang.
My question is - how do I convince TextMate to use clang instead of gcc when I hit Cmd-R for Objective-C (.m) source files?
(I waded through bundle settings but to no avail, googled it, etc. So it must be either something dead simple that I'm missing or nobody ever wanted to go that way. I'm assuming the first.)
P.S. I converted from Windows some weeks ago so don't assume that I'm an expert Mac user.
Here is a way to do this:
Bundles > Bundle Editor > Show Bundle Editor
Expand 'C'
Select 'Run' command
Replace 'GCC' with 'CLANG' in the when "objc" case (it is the g variable)
I have a CI environment which builds my project. So when I compile my project with xcodebuild -target MyTarget and run it on a physical device, I get a visual bug with one of the Three20 libraries as well as a reproducible crash.
However, when I compile and run the project and the same target via Xcode I neither have the crash nor the visual problem.
Since I don't do anything fancy with xcodebuild I would expect the two builds to be identical. Generally I'd rather have the problem in two places than the two builds behave differently.
Has anyone run into similar issues and how can I make sure that the product of Xcode and xcodebuild is identical? Thanks a lot for your help.
Try running xcodebuild -scheme MyScheme, where MyScheme is most likely the name of your target if Xcode auto-generated the scheme for you.
The GUI uses schemes when building and I've found that you can usually get the same behavior by specifying a scheme to xcodebuild.
I have a problem which I have been struggling with for a while.
I have a Cocoa library which acts as a wrapper for a C++ library. C++ library is tested using a set of BOOST unit tests. The tests run normally under both debug and release modes.
In order to test the Cocoa wrapper I am using otest. Here is the strange part, the tests run normally in debug mode but fail in release mode. To make sure its not something in the code I've taken the tests content and compiled them as a separate Cocoa app which uses the wrapper code. This runs normally both under release and debug.
When otest fails I get a stack trace which makes little sense and ends with dyld_misaligned_stack_error.
Another strange thing that I've noticed is that when starting otest from a command line rather than from XCode if I point DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to the Debug version of C++ library the tests pass. I have confirmed though that all my test code is being compiled with Release flags.
Any help would be greatly appreciated!
Thank you
Try adding flag "-mstackrealign" in C flags in the release version.
-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a
4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility.
See GCC's man page for reference.