I'm compiling an app for a device where the architecture does not support sse beyond sse2, and was wondering is it possible to disable compiling with sse3 instructions from GNU autoconf generated configure scripts? I know you can turn it off in gcc/g++ with mno-sse3 option, but it would be nice if I could turn it off at the configuration level rather than generating a make file and then manually inserting that compiler flag...
If you are using the more recent versions of gcc, you can simply do -march=native, and the compiler will handle it for you.
Edit: this option was introduced in gcc 4.2.
Sure. Just set the required flags before calling configure:
$ CFLAGS="-mtune i386" ./configure --enable-this --disable-that ...
You might want to try -march if -mtune does the wrong thing, I haven't tested this lately.
Related
In 16.0, the Intel C++ Compiler provided two compilers (one based on EDG, another based on Clang).
From the 16.0 documentation:
Using the Command Line
To invoke the compiler from the command line, use a command similar to
the following:
For C source files: icc my_source_file.c or icl my_source_file.c
For C++ source files: icpc my_source_file.cpp or icl++
my_source_file.cpp
Following successful compilation, the compiler creates an executable
file in the current directory.
icl/icl++ is a Clang-based front-end. You can use Clang options with this compiler. icc/icpc is an EDG-based front-end. You cannot use Clang options with icc/icpc.
But I'm not seeing a similar description now.
If Intel is using icl/icl++ to denote Clang-based front-end and icc/icpc to denote EDG-based front-end in 19.0 as well, then both these are available but on different platforms.
icc/icpc is available in Linux and macOS and icl is available in Windows.
From the documentation of 19.0:
Linux*:
Invoke the compiler using icc/icpc to compile C/C++ source files.
macOS*:
Invoke the compiler using icc/icpc to compile C/C++ source files.
Windows*:
You can invoke the Intel® C++ Compiler on the command line using the
icl command.
In the current version for Linux, which is Intel oneAPI Base Toolkit for Linux 2021.1.8.1970, I could find clang, but neither icc nor icpc. So, just in case, I searched for ~/intel/oneapi/**/ic*(*) with zsh (i.e. executable files starting with ic, recursively), and found icx and icpx. The output of icx --help says "Intel(R) C++ Compiler Help" and still mentions the executables icc and icpc, so the executables have apparently been renamed, but Intel forgot to update the documentation.
One can see both ICC and ICX mentioned on: https://software.intel.com/content/www/us/en/develop/articles/oneapi-c-compiler-system-requirements.html
When using clang v8.0.0 on Windows (from llvm prebuilt binaries) with -g or -gline-tables-only source map tables are not being picked up by gdb or lldb debuggers.
Upon including -g flag file grows in size (which is to be expected) yet neither gdb nor lldb pickes the source up
When compiled with gcc though (with -g flag) source files are detected by debugger.
I have tried running the same command (clang -g <codefile>) on macOS High Sierra (clang -v says it is Apple LLVM version 10.0.0 (clang-1000/10.44.4)) where there source files are being picked up by lldb. So I guessed it is localized to my windows instance or llvm for windows build.
P.S. output of clang -v on windows:
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
On Windows, Clang is not self-sufficient (at least not the official binaries). You need to have either GCC or MSVC installed for it to function.
As Target: x86_64-pc-windows-msvc indicates, by default your Clang is operating in some kind of MSVC-compatible mode. From what I gathered, it means using the standard library and other libraries provided by your MSVC installation, and presumably generating debug info in some MSVC-specific format.
Add --target=x86_64-w64-windows-gnu to build in GCC-compatible mode. (If you're building for 32 bits rather than 64, replace x86_64 with i686). This will make Clang use headers & libraries provided by your GCC installation, and debug info should be generated in a GCC-compatible way. I'm able to debug resulting binaries with MSYS2's GDB (and that's also where my GCC installation comes from).
If you only have GCC installed and not MSVC, you still must use this flag.
How do I know this is the right --target? This is what MSYS2's Clang uses, and I assume they know what they're doing. If you don't want to type this flag every time, you can replace the official Clang with MSYS2's one, but I'm not sure if it's the best idea.
(I think they used to provide some patches to increase compatibility with MinGW, but now the official binaries work equally well, except for the need to specify the target. Also, last time I checked their binary distribution was several GB larger, due to their inability to get dynamic linking to work. Also some of the versions they provided were prone to crashing. All those problems come from them building their Clang with MinGW, which Clang doesn't seem to support very well out of the box. In their defence, they're actively maintaining their distribution, and I think they even ship libc++ for Windows, which the official distribution doesn't do.)
I'm new to C++11. I've tried:
clang++ -std=c++11 -stdlib=libc++ *.cc
It works, but my questions is:
Is there anyway to set these flag as default for clang++?
How to update g++ 4.2 to a version that supports C++11?
Which way do you think it's the best to compile C++11 code on mac?
Thanks.
Brett has described how to install GCC it with MacPorts. Here’s how to do it with Homebrew, which styles itself (rightfully!) as a modern replacement of MacPorts:
brew tap homebrew/versions
brew install --enable-cxx gcc48
As far as I know the easiest way to install the most recent Clang is by downloading the compiled version linked in dsign’s answer – and, as Brett mentioned, since Apple uses clang internally it’s not advised to tinker with that installation – just put yours somewhere else.
Concerning what the “best” compiler is there are two things to consider in addition to what Brett has already said:
GCC is much older and more mature than Clang. Internal compiler errors do happen occasionally in Clang. That said, it’s maturing rapidly because it’s being pushed by several companies.
Clang is feature complete for C++11, GCC 4.8 is not. One very obvious example of this is the fact that GCC 4.8 still has no working <regex> implementation, which is a shame.
Outside of an IDE (e.g., in shell), I normally have the variable CXX set to: "clang -std=c++11 -stdlib=libc++" in .profile / .tcshrc / etc., since this is picked up by most configure scripts too. On the cmd line I might use: $CXX -c foo.cc
MacPorts gcc-4.8.1 works well: "[sudo] port install gcc48 [-universal]"
"[sudo] port select --set gcc gcc48" will make this the default gcc, g++, etc.
Don't attempt to update or modify the system tools, like the old gcc-4.2 / llvm hybrid that comes with Xcode.
I don't know what you mean by 'best' way in the 3rd part of your question, but with Apple's support (they employ the primary author of LLVM), and other projects like FreeBSD behind it, clang will only continue to improve. It's already much faster than gcc, has far better error messages / diagnostics (especially for C++ and templates), and a modular architecture. For OS X, it's the clear choice.
Answers:
I don't think so
You install another g++ version alongside 4.2, it is bad karma to remove the one that comes with the system. To install a new one, check this
Same goes for clang. You can download it here.
In general, I totally recommend that you get better g++ compilers, 4.2 is quite old and its code quality is not as good. And using c++ 11 is totally worth it.
Do it all in Xcode's build settings like most Apple developers. Xcode simplifies life in many ways.
I am a java developer. I have some C++ code to make some system realted calls. This code is compiled on Intel 32-bit platform using GCC (I have make files) and it works fine on regular Intel based 32-bit linux machine. Now I need to run this on a linux OS running on Marvell ARM processor. When I load the shared objects in java I get the following error.
cannot open shared object file: No such file or directory (Possible cause: can't load IA 32-bit .so on a ARM-bit platform)
Please tell me how to resolve this issue. I looked at the GCC options and I found one option to specify the architecture (-march=armv5) and I can't compile with that option.
Thanks in advance.
You need more than just a switch, you need a cross-compiler. You can make your own, but probably the easiest way is :
Find the development tools for your board. It probably comes with a development kit that includes a cross-compilation toolchain
If you don't have these, you can try to install a precompiled cross-compilation like the ones provided freely by CodeSourcery
Then you have to make the location of your toolchain (look for something like arm-none-linux-gnueabi-gcc) available in your path.
Cross compiling simple project is then easy, just override the CC variable in your Makefile :
CROSS = arm-none-linux-gnueabi-
CC = $(CROSS)gcc
LD = $(CROSS)ld
Try using the -mcpu=armv5 switch for gcc.
Here is what's written on http://elinux.org/RPi_Software#ARM:
-Ofast -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s
I recently switched back to Windows7 (x64) because of perfomance issues with my graphics card on linux but i miss the abilty to easily compile open source software on Windows. I have a copy of the intel c compiler which is somewhat better than the gnu c compiler and i would like to use it to compile software written for linux.
I've already installed cygwin and managed to compile something. The 'make-install' didn't work though but that's another issue. Now my question is, how can i tell 'make' to use the windows intel compiler?
Most of the configure scripts you'll find in OSS have probably been created by the Autotools. Those should, basically, support the icc. To use it, although you may have GCC installed side-by-side, it would be necessary to set the environment variable CC to the (cygwin) path to Intel's C compiler and CXX to Intel's C++ compiler prior to running configure.
You may run into trouble with software packages that unconditionally set compiler flags that only GCC understands. I have heard, though, that, by now, icc actually implements most of these.
Update
Something similar has been asked before.