The "Build and analyze" option doesn't seem to work for .cpp and .mm files. I tried "clang --analyze" on individual files without any standard #includes and it works well. However I'm not able to run it on my Xcode project. I couldn't figure out a way to make clang find the standard #includes like even UIKit.h. Any clues?
clang's C++ support is not complete yet clang web site
Apple's version is more explicit clang man page
Clang currently does not have C++ support
One way is to create symlinks to the Frameworks present in /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.2.sdk/System/Library/Frameworks/XXX.framework/Headers and point clang to the symlinks using the -I option.
Related
Please help me on the gcc compiler command
gcc -c -ID:\pjtName\lib -c -fprofile-arcs -ftest-coverage D:\pjtName\source\tmp.ada
I am trying to compile the tmp.ada with coverage. adb and ads files are located in D:\pjtName\source folder. and my lib files are located in D:\pjtName\lib folder.
The problem is gcc is not locates tmp.ads file and the library files in the D:\pjtName\lib folder. it show file not found error
after this command i need to run gcov command for the tmp.ada file
GNAT’s build process is complicated. gcc is really too low-level a tool to use easily; instead, use gnatmake and GNAT project files.
You’ve tagged gnat-gps, so I assume you actually have GPS. If that’s so, your best bet would be, when opening GPS, to select Create new project with wizard and go on from there. If you get stuck, use GPS’s included help or come back here.
To get coverage information with GPS, you go to Edit / Edit Project Properties and
in the Ada tab, select Code coverage and Instrument arcs, which includes -ftest-coverage and -fprofile-arcs;
in the Ada Linker tab, select Code coverage, which includes -fprofile-generate (you get link time errors otherwise).
By the way, you mention a file tmp.ada; it’s best to stick with .ads for specs and .adb for bodies. GNAT does its best, but if your other code includes with Tmp; GNAT will look for tmp.ads. You can alter this behaviour, but why bother unless you have to for other reasons!
As was stated above, don't use gcc.
I usually use gnat compile filename.adb then use gnat bind filename.ali, then gnat link filename.ali -Lexternaldirectory -lexternallib
First of all, I am only doing something for fun, not for production.
LLVM's bitcode, to some extents, can works like Java's bytecode that can be cross platform. I think it should works in most situations, unless your code consists of some inline asm or something special. I have successfully compiled a simple hello world program with clang to LLVM bitcode in Linux, and run it properly with lli in Windows.
But, how can I use boost library such as boost_thread in that way? I can pack bitcode files together with llvm-link, and it will still be cross platform. But if I link the bitcode with *.a by some methods (I have not tried to do that, but it seems that I can do so even llvm-ld has been removed), it will probably not be cross platform anymore (and become a native binary executable file). So, I want to compile boost to LLVM bitcode, so that I can link the boost library to my program.
If you think that linking it statically will make the bitcode to large, you can also 'link' them in runtime, by lli <your bitcode> <boost's bitcode>...
I have compiled boost with ./b2 toolset=clang cxxflags="-emit-llvm -c". I am not sure whether I am in the right way. If not, is there any way for me to compile boost to bitcodes?
EDIT:
The above command seems to be partially work. The *.o files produced are LLVM bitcode, but it will then be archived to *.a. Simply decompress the *.a and use llvm-link to link the files in the archive together may work.
BUT, unfortunately, there is inline asm in boost's thread library. So, it cannot run...
I've just compiled GCC 4.7 to work with stdatomic.h, but I can't seem to -I it. stdatomic.h seems to live in /usr/include/c++/4.4.3, but then the linker tells me it needs a bunch of other files in dirs nearby. If I -I all of them, I still get the error undefined reference to atomic_flag_clear_explicit. Any ideas how I'm supposed to link this right?
First, if you are compiling with GCC 4.7 you should not be including or linking anything from a directory from GCC 4.4.
Second, -I only affects the search path for header files. "undefined reference" is a linker error and usually means it hasn't found the right library. You change the library search path with -L. The linker didn't say it didn't find a library with the right name, it says it didn't find a symbol, so clearly the library it did find didn't have that symbol. I'd suggest you have a versioning problem, perhaps caused by a installation problem.
The <stdatomic.h> header in GCC 4.4 and 4.5 was from an early draft of C++0x atomics, but is not part of the final standard, so it was removed from libstdc++.
The C++ compiler supports C++11 atomics via the C++11 <atomic> header, so you should use that header in C++ code.
When the C compiler supports C11 atomics, the <stdatomic.h> header will be provided again.
Using this command solved the problem for me:
$ scl enable devtoolset-7 bash
I got the same error as you when entering sudo make altinstall for installing Python 3.8.5 on CentOS 7.
I have an Objective-C/Cocoa project that incorporates a static library. That static library has some object files that have C++ in them.
I've found that if the project that I'm using the library in contains no other C++ in it, the link fails (can't link new/delete/etc). But simply adding a single (empty) .cpp file to the project causes the link to succeed.
In practice, what happens is that the build will invoke g++ instead of gcc when there is any cpp, which succeeds. No other difference in the build is apparent to me.
Is there an explicit switch I can use to link in this library without using the dummy cpp file in the project?
(This is mostly a curiosity question-- it's not the end of the world to put in one empty file. :) )
Thanks.
try to link libstdc++
gcc main.c -lstdc++
or in Xcode:
Project->Edit Project Settings
To the config section "Other Linker Flags", add -lstdc++.
I have been trying to produce a statically linked "single binary" version of my game for windows. I want to link with sdl, sdl_image and sdl_mixer which in turn pull in a few support libraries. Unfortunately I haven't found a way to get them all to compile and link using cygwin/mingw/gcc. As far as I can tell all existing public versions are only shared libraries / dlls.
Please note that I'm not talking about licencing here. The source will be open thus the GPL/LGPLness of sdl is not relevant.
When compiling your project, you need to make just a couple changes to your makefile.
Instead of sdl-config --libs, use sdl-config --static-libs
Surround the use of the above-mentioned sdl-config --static-libs with -Wl,-Bstatic and -Wl,-Bdynamic. This tells GCC to force static linking, but only for the libraries specified between them.
If your makefile currently looks like:
SDLLIBS=`sdl-config --libs`
Change it to:
SDLLIBS=-Wl,-Bstatic `sdl-config --static-libs` -Wl,-Bdynamic
These are actually the same things you should do on Unix-like systems, but it usually doesn't cause as many errors on Unix-likes if you use the simpler -static flag to GCC, like it does on Windows.
Via this SDL mailing list post it seems that the sdl development tools ship with a sdl-config script that you can use with the --static-libs flag to determine what linker flags you need to use.
Environment: VMWare Virtual Machine with Windows 7 x64 and Equipment we Dev c + + build 7.4.2.569, complilador g+ + (tdm-1) 4.6.1
Once, SDL2-2.0.3 API installed as configuration Dev c ++ is not very clear what I've done as tradition requires command line.
The first problem is that Windows 7 appears to have changed the methodology and they go to his ball. Inventory. Ref. https://stackoverflow.com/users/464581/cheers-and-hth-alf
After the first hurdle, SDL_platform.h is that bad, it's down another, I do not remember where I downloaded, but the next does not work in the indicated version.
We must put SDL2.h ls in the directory of the executable.
D:\prg_desa\zsdl2>g++ bar.cpp main.cpp -o pepe1 -ID:\SDL2-2.0.3\i686-w64-mingw32\include\SDL2 -LD:\SDL2-2.0.3\i686-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2 -mwindow
I've finally compiled and works SDL2 testing.
That's because the SDL libs are under the LGPL-license.
If you want to static link the libs (you can do that if your recompile them. It needs some hacking into the makefiles though) you have to place your game under some compatible open source license as well.
The SDL-libs come as shared libraries because most programs that use them are closed source. The binary distribution comes in a form that most people need.
On my system (Ubuntu) I have to use the following flags:
-Wl,Bstatic -lSDL_image `sdl-config --libs` -lpng12 -lz -ltiff -ljpeg -lasound -laudio -lesd -Wl,-Bdynamic `directfb-config --libs` -lpulse-simple -lcaca -laa -ldl
That links SDL, SDL_image, and many of their dependencies as static. libdl you never want static, so making a fully-static binary that uses SDL_image is a poor idea. pulse,caca,aa, and directfb can probably be made static. I haven't got far enough to figure them out yet.