I just installed gcc 4.9 (with C11 support), and want to add it to Xcode 4.6.3's build options as a compiler option. I ran make and make install, and the packages are all there (under /usr/bin/gcc. Running gcc --version confirms that gcc 4.9 is installed rather than an older version.
When I go into an existing Xcode project's build settings, the only compiler options available are
Apple LLVM compiler 4.2
LLVM GCC 4.2
Other...
Clearly, GCC 4.9 would have to be added using the "Other..." option, although I'm not sure how. I've tried inputting the path to gcc (/usr/bin/gcc), although the default value for other isn't a path at all: com.apple.compilers.llvmgcc42.
I've also tried following the instructions from the answer to this question as well, but the machine I'm on doesn't have the /Developer directory at all, since I believe Apple integrated the developer tools that required (and created) this directory into Xcode.
How do I add gcc 4.9 as a compiler option in Xcode?
Related
I'm trying to install this project: https://github.com/drufat/triangle. Unfortunatly, I get the following error:
error: Cygwin gcc cannot be used with --compiler=mingw32
I'm using the lastest version of gcc for Cygwin on Windows 7 64 bit and I'm trying to install that project for python 3.7.1. It's seems to come from my distutil configuration. My distutils.cfg file contains:
[build]
compiler=mingw32
I tried that solution but it doens't helped:
https://stackoverflow.com/a/16740123/5075502
The gcc options to build for MinGW64 is no longer supported by the regular cygqin compiler gcc, aka x86_64-pc-cygwin-gcc. Instead, you should also install the mingw64-x86_64-gcc-core package which provides the GCC for Win64 toolchain (C, OpenMP). This will also install other packages (through dependencies) which provide compatible binutils, headers, libraries, and runtime.
In your Makefile or compiler command line, replace gcc with x86_64-w64-mingw32-gcc. This will allow you to compile and link executables which do not depend on the cygwin1.dll.
A similar problem occured. I fixed it by changing mingw32 by gcc like #phd said.
I need to use tools that depend on clang on a Unix machine I remote onto at work. Anything I install is locally installed onto ~/local. I do not have root permissions.
/usr is pretty outdated, with gcc being at version 4.4.7. clang requires gcc 4.7+
I read on linux from scratch that a gcc 6.1 installation requires 8.4 gb. This is not something I can do, because that's huge.
Can someone advise me on the best workaround to install up to date clang on my ~/local?
Please and thanks.
Edit:
Courtesy of Nishant, here is the short answer:
Set up a personal machine running the same linux distro and cross compile using gcc to your specific architecture. For me, I will run a Redhat 6.5 VM and compile using gcc an arm x64 binary. Thanks Nishant!
You can get pre-build binaries for Unix system from LLVM's release website: http://llvm.org/releases/
You can then put the binaries in any local folder you want and source it using the PATH variable, which can be done by modifying your ~/.bashrc file by appending:
export PATH=$PATH:<clang-binary-directory>
Now you will able to use clang from the command line terminal as if it was installed.
If you want to build from source only, you can get older source code of clang which will use gcc 4.4.7 and build it and then use clang to build clang. Or get the latest clang binary and use it to build latest clang.
I am running the latest version of MinGW GCC 4.7.2, and it was working fine with -std=c++11 before I installed Haskell using Haskell Platform. Please take a look at this:
For some reason, the GCC went back to 4.5.2, after installing Haskell, I re-installed it, with version 4.7.2, but its still showing 4.5.2.
Haskell adds its own GCC to your system PATH. You can check this is true by running
where gcc
which will show two commands, the Haskell one first, followed by your MinGW GCC.
The solution is to change your PATH to point to the GCC you want (but make sure Haskell still uses its GCC, I doubt it'll agree with GCC 4.7 if it came with GCC 4.5).
The easiest is to have some script ou can run to set up your compilation environment, so you don't have to worry about system PATHs.
If you don't care much about that exact GCC version you had installed, you can get my builds (32-bit and 64-bit), which come with a .cmd file you can doubleclick and it will give you a build environment much like the MSVS commandline shortcut, but for GCC. All it really does is add the compilers to PATH.
I want to use Red Hat Enterprise Linux 5.8 to compile folly, and gcc is 4.1.2. But folly needs gcc >=4.6. So I need to upgrade gcc to 4.6, maybe binutils etc. If new toolchain generates binary files such as *.a *.so, would running them on old Red Hat Enterprise Linux 5.8 bring any problem or unstabitily?
Probably no big trouble (because GCC 4.1 & soon released GCC 4.8 produces compatible code), at least for C code.
For C++ code I believe there is a incompatibility. Certainly the libstdc++ is tied to the compiler version. Sometimes it may be compatible in practice, sometimes not (but the C++ ABI slightly changed too). And this incompatibility may spread to every C++ library.
I believe you should try. If you recompile -with the same newest GCC- all the C++ dependencies, you'll probably be quite safe. So you could compile the newest GCC, then compile folly and all its dependencies with it.
BTW, I would suggest going to the latest GCC (today 4.7, in a few weeks 4.8).
So we have this program which is being compiled in OpenSuse 13.1 with the following configuration:
GCC 4.6-15.1.3
GLIBC 2.14
Libcrypto 1.0
However, it's supposed to run with OpenSuse 10.3 which has the following configuration:
GCC 4.2-24
GLIBC 2.6.1-18
Libcrypto 0.9.8
The only dependency I could find so far was the __isoc99_sscanf which is introduced in GLIBC 2.7. I tried to fix this with writing my own sscanf function and replace it by adding the following line in my source code:
__asm__(".symver __isoc99_sscanf1, __isoc99_sscanf##GLIBC_2.7");
Now I'm left with the libcrypto dependency and it also looks like it's segfaulting on a munmap() (when i strace the program) function when I try to run it in the old OpenSuse environment (could be a GCC thing?)
So basically, I don't really know what the standard procedure is for fixing this kind of backwards compatibility issues. Any idea's on this?
Normally you would simply install the older gcc, glibc, and other libraries on the new OS (usually made available as RPMs for this reason) and make sure you compile only with those. It's an uphill battle to try to fix all the backwards incompatibilities yourself.
To be more thorough you could build in a chroot of the older OS, maybe even package it up into an RPM so the dependencies are automatically checked. Something like the Open Build Service makes this very easy.