I am usually coding on OSX and compile all my program with : -Wall -Wextra -Werror
I download on another laptop nixos and when i want to compile the same project, i have -Wunused-result error.
I can disable it with : -Wno-unused-result but why this flag error appear on this os ?
I found nowhere a default flag configuration file or environment variable.
For curious the program i'm trying to compile is : libft.
If you're compiling on OSX and haven't installed gcc, Apple has provided clang pretending to be gcc. The pretense isn't very good, since there are a lot of differences in warnings (and exit-codes). You can see what you are running using
gcc --version
and (for instance ‐ I have installed gcc using MacPorts under /opt):
$ path -lL gcc
-rwxr-xr-x 3 root admin 1131416 Jun 10 2016 /opt/local/bin/gcc
-rwxr-xr-x 1 root wheel 18176 Jul 8 22:52 /usr/bin/gcc
$ /opt/local/bin/gcc --version
gcc (MacPorts gcc5 5.4.0_0) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
As you can see, /usr/bin/gcc is really clang, and (barring Apple improving things further), will produce similar messages.
Related
Mac 10.13.6 High Sierra here. New to C development and I'm trying to get myself setup with the latest stable/recommended GCC version, which I believe (keep me honest here) is 10.2.
When I go to the terminal to see what I have installed:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ gcc -dumpversion
4.2.1
OK...surprised to see LLVM/clang-related stuff in the output. So I try this:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
So its almost as if... I have both clang and gcc installed, but my clang installation has assimilated my GCC installation?! Why else would the gcc --version output reference clang?
Is this typical for Mac setups?
What do I need to do to get GCC 10.2 properly installed on my machine?
Here are some simple truths, statements and observations to try and explain what's going on:
Apple ships the clang/LLVM compiler with macOS. Clang is a "front-end" that can parse C, C++ and Objective-C down to something that LLVM (referred to as a "back-end") can compile
Clang/LLVM is located in /Applications/Xcode.app/somewhere
Apple also ships a /usr/bin/gcc which just runs clang. I have no idea why they do that - it doesn't seem very helpful to me - but they don't answer my questions
Apple puts its binaries (programs) in /usr/bin. That is an integral part of macOS and you should never touch or change anything in there - you are asking for problems if you do. This warning applies to Python too.
If you want the real, lovely GNU Compiler Collection (GCC) which includes the gcc, g++ and gfortran compilers, your best bet, IMHO, is to get them from homebrew. I will not put the installation instructions here because they could become outdated, so you should use the ones on the homebrew site.
Once you have homebrew installed, you can install the GNU Compiler Collection (GCC) with:
brew install gcc
After that, you will have all the lovely GNU Compiler Collection (GCC) of tools in /usr/local/bin, so you should put that in your PATH, near the beginning, and in any case before /usr/bin, using:
export PATH=/usr/local/bin:$PATH
In general, you should also add a similar line into your login profile, or into the system login profile, so it is set up every time you or any other user logs in.
Let's take a look:
ls /usr/local/bin/gcc* /usr/local/bin/g++*
/usr/local/bin/gcc-10
/usr/local/bin/g++-10
Depending on the versions and updates, you will then have these programs available:
gcc-10 # the real GNU C compiler
g++-10 # the real GNU C++compiler
gfortran # GNU fortran compiler
And you can check their versions with:
gcc-10 -v
g++-10 -v
gfortran -v
Now you know about homebrew, here are some more simple truths and observations:
folks (who are not the supplier of the operating system) who supply binaries (programs) for you should put their stuff in /usr/local to show that it is just a locally installed program rather than a part of the core macOS operating system
homebrew is well-behaved and installs its binaries (programs) in /usr/local/Cellar and then usually makes symbolic links from /usr/local/bin/PROGRAM to the Cellar. None of this interferes with Apple-supplied stuff.
if you want to run the homebrew version of a command, you should have /usr/local/bin first on your PATH
Let's have a look at those symbolic links:
ls -l /usr/local/bin/g*10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/g++-10 -> ../Cellar/gcc/10.2.0/bin/g++-10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/gcc-10 -> ../Cellar/gcc/10.2.0/bin/gcc-10
If you want to know what you are actually running when you enter a command, use the type command like this.
type gcc
gcc is hashed (/usr/bin/gcc)
That tells you that if you run gcc you will actually be running /usr/bin/gcc which we know is from Apple - because it is in /usr/bin
Now try this:
type gcc-10
gcc-10 is hashed (/usr/local/bin/gcc-10)
That tells you that if you run gcc-10 you will actually be running /usr/local/bin/gcc-10 which we know is from homebrew - because it is in /usr/local/bin
I've tried to replace the included gcc 4.2.1 compiler on my Mac Book Pro with latest version of Mac OSX but can't figure out what Im doing wrong:
Also this screen scrape from my shell doesn't make sense for me:
Johans-MBP:bin johanlindfors$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Johans-MBP:bin johanlindfors$ which gcc
/usr/local/bin/gcc
Johans-MBP:bin johanlindfors$ /usr/local/bin/gcc --version
gcc (Homebrew GCC 8.2.0) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Johans-MBP:bin johanlindfors$
It's because it's actually Apple Clang pretending to be GCC.
The system gcc-4.2.1 compiler is a (very old) legacy of the migration from the gcc to clang compilers. It should never be used for your own code. Edit your .profile or .tcshrc to prepend the newer gcc directory to the path. Or save a lot of time and energy and use MacPorts.
Unfortunately, Clang has established 'absolute' compatibility at gcc-4.2.1: see: clang -E -dM - < /dev/null | grep GNU
That's not a bad thing. Once the compiler gains traction it's going to provide it's own extensions, and no longer track those of others. Many extensions remain compatible like Intel's <x86intrin.h>. It's not really in either compiler's interests to provide too much divergence with extensions...
The 'stable' gcc is now 8.2.0 according to MacPorts. The stable MacPorts clang (which irritably conflicts with OS X) is apparently 7.0.0 ... short story - don't go replacing sets of files arbitrarily that you think might work. Then set up paths correctly - IIRC, MacPorts will do this for you.
I provided a more recent summary: here.
On OS X 10.11.6, I installed gcc 6.2.0 using homebrew. It lives over in usr/local/Cellar/gcc/6.2.0/bin. After getting it to link (it didn't do this automagically), I cd there and try the solution from this other thread to create an alias
ln -s gcc-6 gcc
then gcc --version gives me
cc (GCC) 4.9.2 20141029 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
All this is because trying to install things crashes because of -rdynamic flags, that I hope is fixed in a newer version.
You created the symlink with the proper target name (gcc) but forgot to set the PATH to your newly installed location (or set it after the system path).
What's confusing is that your system already has a version of gcc installed. You have to override the default path so your gcc command comes first.
edit your ~/.profile file and check PATH adjustment. Add a line in the end which contains:
export PATH=/usr/local/Cellar/gcc/6.2.0/bin:$PATH
Then open a new terminal and ensure that which gcc prints
/usr/local/Cellar/gcc/6.2.0/bin/gcc
I try to use packages that use scipy.weave for numeric optimization, and are met with a CompileError from the scipy.weave.inline calls.
Some experimentation brings out a minimal failing example:
import scipy.weave
scipy.weave.inline('printf("%d\\n",1);')
which results in a massive error dump that I for space reason have put on pastebin: http://pastebin.com/0QR4kq2V
The first error in the dump is
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/complex:47:28: error: bits/c++config.h: No such file or directory
and the last output is
CompileError: error: Command "g++ -fno-strict-aliasing -fno-common -dynamic -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -DNDEBUG -g -O3 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -I/Library/Frameworks/Python.framework/Versions/7.3/lib/python2.7/site-packages/scipy/weave -I/Library/Frameworks/Python.framework/Versions/7.3/lib/python2.7/site-packages/scipy/weave/scxx -I/Library/Frameworks/Python.framework/Versions/7.3/lib/python2.7/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/7.3/include/python2.7 -c /Users/mik/.python27_compiled/sc_f6039f30c0a12f4687924b6a12ef83730.cpp -o /var/folders/_z/qd8rt65n1n56_nvv4nyy7xlh0000gn/T/mik/python27_intermediate/compiler_ecdbc4f3f030692747d93319f8d429b2/Users/mik/.python27_compiled/sc_f6039f30c0a12f4687924b6a12ef83730.o" failed with exit status 1
I run MacOSX 10.8.4,
> g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
> python --version
Python 2.7.3 -- EPD 7.3-2 (32-bit)
I've not used weave at all myself, so I don't know if it has specific SDK requirements, but I suspect that the issue is that you should not be using the 10.5 SDK with the newer Xcode that you appear to be using. I also have that version and it only has the 10.7 and 10.8 SDKs installed. Several releases back Xcode stopped using the /Developer folder and it is all installed inside the Xcode application bundle now. So the first thing I would try would be to move /Developer somewhere out of the way and try building again and see if that takes care of it. If so then you should be able to remove /Developer entirely.
On my version of Mac OS X (10.7.1 (Lion) and Xcode 4.1), there is LLVM 3.0svn and Clang 2.1.
The current versions are LLVM 3.0 and Clang 3.0.
From the Xcode web site, it seems that the latest version (4.2.1) still uses LLVM 2.0, and this seems to be a mistake.
If installing the latest Xcode, will I get a more recent version of LLVM/Clang?
Are there any possible issues installing Clang manually?
Once installed, will the new Clang be used automatically by all the IDEs I have (e.g., NetBeans)?
The web site is incorrect. Xcode 4.2.1 and 4.2 include LLVM 3.0 and Clang 3.0:
clang --version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
clang++ --version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
llvm-g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
llvm-gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
You can comfortably build your own LLVM using Homebrew:
brew install llvm
There are also versioned packages in case you need a specific version:
llvm#3.7
llvm#3.8
llvm#3.9
llvm#4
Software vendors are traditionally conservative about updating build tools and with good reason. If you want to use the latest publicly-supported versions of build tools supplied and modified by Apple, you should stick to those in the latest version of Xcode for the OS X release you are running.
There are usually good reasons why Apple has not yet updated to the latest cutting-edge versions of open source components, like serious bugs.
If you don't need the Apple-supplied modifications and don't mind living on the edge - i.e., no support from Apple and possibly (re-)discovering known problems - and are not planning to ship compiled files to other people's systems, you could install your own versions in, say, /usr/local/bin or by using third-party package managers, like MacPorts http://www.macports.org/ports.php?by=name&substr=clang). You should definitely not try to replace the files at the paths installed by Xcode.
Is it worth it? Only you can decide that.
I highly recommend against replacing the system compiler on macOS:
Many build processes you will see (e.g. Xcode) rely on Apple-specific extensions. For example, last I checked Apple have their own linker.
Also, Linuxes do not enforce binary compatibility -- generally, people build software from source, or download specific binaries for each operating system version. As an end-user (as opposed to developer/professional user) operating system, macOS goes to great effort to maintain compatibility with binaries built on older macOS versions.
Replacing the compiler, or worse, system libraries, will break these compatibility guarantees. It may also break your system in subtle, non-obvious ways.
But feel free to install a second copy of clang in /usr/local or so and explore new features, but leave the system compiler alone.
Also note that Apple do not support submitting software to the app stores that aren't built with Xcode and the compiler it includes. While you may go unnoticed if you do that, you may get rejected during app store review if your compiler fails to do anything that Apple's compiler does.
On 10.8.2 (Mountain Lion) with Xcode 4.6, the versions are:
$ clang --version
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
$ clang++ --version
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
$ llvm-g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ llvm-gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
You can update Xcode for Lion too from the App Store or Apple Developer Account direct download, and install the command line tools, which will update Clang and LLVM to the above versions.
OS X Update version 10.9.2 (Mavericks) brings Xcode to version 5.1 (5B130a), and Clang to the latest stable (for OS X):
clang --version
Output:
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
On my Mac, llvm-gcc and llvm-g++ are symbolic link to this Clang:
lrwxr-xr-x 1 root wheel 5B 25 Oct 16:48 /usr/bin/llvm-gcc -> clang
lrwxr-xr-x 1 root wheel 7B 25 Oct 16:48 /usr/bin/llvm-g++ -> clang++
My latest R installation is configured to use llvm-gcc-4.2 which would cause error when building SHLIB. Creating symbolic links for llvm-gcc-4.2 and llvm-g++-4.2 the same way, instead of replacing LLVM or CLANG, is enough to resolve the errors.