I've been trying to get Mac OSX Yosemite to use gcc instead of clang when cc is invoked, but no matter what I do, it refuses to play along. I've already tried changing my bash_profile/bashrc and even relinking the symlink, but to no avail--every time I invoke "cc" it is still clang that runs. I'm trying to force it to be gcc instead (and no, just calling gcc is not an option).
I previously asked a similar question (Make gcc default c compiler on Yosemite/disable clang).
Neither OS X nor Xcode comes with real GCC. For compatibility with scripts which assume the compiler is called "gcc", it has executables by that name, but they are all fronts for Clang. No amount of symlinking, setting environment variables, or setting up aliases will allow those executables to run real GCC.
If you want GCC, you need to install it. You can do that using one of the package managers, such as MacPorts (the one I'm familiar with). I'm sure you could also use Homebrew.
You should not modify anything in /usr/bin. If you've already done so, you should restore what you've changed, if possible.
Well-behaved package managers will also not modify that directory. They should install to a separate directory such as /opt/local/bin, /usr/local/bin, or the like. In that case, you will want to modify your PATH to put those directories earlier than /usr/bin.
You shouldn't do this. A lot of tools rely on the installation binaries to point to what they should. Another option is to set the environment variable CC to gcc, and invoke compilation with $CC ... rather than cc ... ; this environment variable will also be picked up when building packages via configure (autotools) or cmake.
This is also a compatible approach with MacPorts versions of gcc (like the much more up to date gcc-4.9.2), which can be set up with: sudo port select --set gcc mp-gcc49
Related
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 am trying to build an alternative compilation suite on my debian-testing machine (sorry, real question is actually at bottom).
Technically it is a "cross-compilation" because I need to use this toolchain on another machine, but hardware is compatible (x86_64-unknown-linux-gnu) so I don't need to bother about build/host/target differencies.
On the other hand I do need to worry about prefix/sysroot because I cannot install in any standard location (to be more precise: I could install anywhere, since I have root access there, but I shouldn't); This leaves me with my $HOME, some completely non-standard place (e.g.: /usr/local/my/toolchain) or some semi-standard (e.g.: /opt) place. In any case I will need to do something to enable compilation to find includes and libs in such places and runtime linker to find needed .so.
My requirements are:
I have a running Linux that shouln't be messed with.
This system does not have a "C" compiler.
Said linux is BusyBox-based, so I will need a substantial amount of utilities to do any serious compiling there, including make, sed, awk, ..., beside the compiler proper.
I would be happy to stuff my augmented toolchain in /opt, but that is not a requirement; any place is ok as long as it's accessible by more than a single user, I would like ot avoid installing in $HOME.
I am aware of "optware", I installed it and it does work... up to a point. Unfortunately:
It's really old software
it's only 32bit (my system is Linux syno0 3.2.40 #5004 SMP Thu Nov 6 15:26:44 CST 2014 x86_64 GNU/Linux).
Some programs won't compile because provided libs have 32/64 mismatch.
Real motivation to do all this exercise is I need to install some perl modules needed for one application that will have to run there and to install them from cpan I need a native compiler (and other stuff, of course).
Similar arguments about a Ruby-on-rails application I should port there.
If at all possible I should try to use the "native" libs in /lib:/lib64:/usr/lib:/usr/lib64:/usr/lib32 ("static" .a libs are not available).
I had a limited success preparing a custom tarball from an available toolchain for my processor, relocating it to /opt, stuffing needed apps in its sysroot and compiling with: CPPFLAGS="-I/opt/include" and LDFLAGS="-L/opt/lib -Wl,-rpath -Wl,/opt/lib".
This enables me to build almost everything "LFS-style", but it's rather error-prone and 64-bit-only.
I seem to understand it should possible to automatize all this by a careful mix of --prefix, --with-sysroot, --with-native-system-header-dir, --enable-multilib and their friends.
I tried to understand exactly how they should be used and failed, for a reason or another. I didn't find any exhaustive documentation and information in GCC instalation docs are confusing me.
Can someone, please, give me a recipe to build this toolchain?
Any pointer to in-depth documentation welcome, but I suspect some tutoring will be necessary.
I assume recompilation of Binutils and GCC is mandatory, Glib is probably not needed; anything else can be recompiled "native" on target.
TiA
ZioByte
After installing your toolchain in nonstandard places you need to set environment(maybe system-wide) correctly for GCC using LIBRARY_PATH and C_INCLUDE_PATHor CPLUS_INCLUDE_PATH.
Environment Variables Affecting GCC
I see three ways to automate setting path variables for your relocatable toolchain:
on every relocation adding your GCC path to your PATH environment variable. And create alias in your busybox profile (usually /etc/profile)
alias example:
alias gcc='TOOLCHAIN_PREFIX=$(which gcc | rev | cut -d"/" -f3-10 |rev); \
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ gcc'
creating for your toolchain launcher-script that will calculate pathes, but you'll should launch it with direct path, setting it when you launch build process, or of course you can add its location to PATH environment varaible.
script example
#!/bin/sh
TOOLCHAIN_PREFIX=$(echo $0 | rev | cut -d"/" -f3-10 |rev);
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ \
$TOOLCHAIN_PREFIX/bin/gcc-4.*
The most reliable and ergonomic way — create install/uninstall script that will unpack and set environment correctly, to relocate toolchain you will uninstall from it from one prefix and install to another. If you have dpkg on your debian-testing system, .deb package is best choice.
I can see no way to set environment fully automatically. But we can reduce it to setting just one path — path of toolchain.
HINT* For better stability you should isolate your toolchain and also install in your prefix Linux Kernel headers and Glib
I'm using Code::Blocks for a project. I have not used an IDE on Linux in years, so I'm a bit out of touch with Linux IDEs.
I'm working with an OpenSSL project that uses FIPS validated library. I duplicated the GCC compiler toolchain and modified it to use OpenSSL's fipsld (and set it as default).
When the project's code executes under Code::Blocks via F8, FIPS_mode_set fails with error 252104805 (0xF06D065). 0xF06D065 is:
$ openssl errstr 0xF06D065
error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported
which tells me Code::Blocks is not using the OpenSSL I specified in /usr/local/ssl/lib. Rather, the program is using the non-FIPS library provided by Debian in /usr/lib/x86_64-linux-gnu/.
An image of the link library settings is below. Note that the libraries are fully specified, and nothing is left to chance.
CodeBlocks is clearly doing things with LD_LIBRARY_PATH (shown below).
I've also verified the project is using the correct search directories - /usr/local/ssl/include for headers and /usr/local/ssl/lib for the linker.
With compiler logging set to "Full Command Line" set, here's what I get from the build log:
-------------- Build: Debug in ac ---------------
Compiling: main.cpp
/home/jwalton/Desktop/ac/main.cpp:8:5: warning: unused parameter ‘argc’ [-Wunused-parameter]
/home/jwalton/Desktop/ac/main.cpp:8:5: warning: unused parameter ‘argv’ [-Wunused-parameter]
Linking console executable: bin/Debug/ac
Output size is 569.67 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 2 warnings
I'm aware of Basile Starynkevitch's suggestions on rpath's and LD_PRELOAD tricks, but this seems like one of those things the IDE should be handling for me (Visual Studio will handle it properly, and even gives us an input box to set Working Directories to find additional libraries).
Any ideas how to make Code::Blocks use the shared objects in /usr/local/ssl/lib when executing the program under the debugger?
Your IDE instructs the compiler to link against the specified libraries, but not to load them at run time. For this latter thing to happen, you need to pass another option to the linker, namely
-rpath=/path/to/directory/with/your/libraries
or, if the linker is invoked by the compiler,
-Wl,-rpath=/same/thing
Code::Blocks don't use shared objects (DLL are a Windows thing). Because Code::Blocks is simply an IDE. IDEs are glorified source code editors with the ability to run external software development tools. You could (and sometimes you should, at least to learn how things happen) edit your code with a plain good editor like emacs, and build it with commands. Your IDE is just running commands, notably a compiler and a linker, probably using gcc
So what is using shared objects in /usr/local/ssl/lib/ is the compiler and linker (and the runtime dynamic linker). BTW, /usr/local/ssl/lib/ is a very strange name for a directory containing shared objects; you should have configured OpenSSL to be installed in /usr/local/lib/ !
First, I really believe you should reconfigure and recompile and rebuild and reinstall your SSL to get it installed under /usr/local/ (or perhaps /opt/) prefix (i.e. shared libraries in /usr/local/lib).
Then you could add appropriate options for the ld linker (from binutils). You probably want -L/usr/local/ssl/lib (to the gcc command which is running ld), and you may want to pass -Wl,-rpath (see this).
I would suggest to reinstall your SSL in /usr/local/, add /usr/local/lib/ into /etc/ld.so.conf (or at least into your LD_LIBRARY_PATH...) and run ldconfig
Otherwise, add at least /usr/local/ssl/lib/ in front of your LD_LIBRARY_PATH (and also -L/usr/local/ssl/lib/ to your linking command).
Read Program Library HowTo, the answers to this, and Drepper's How To Write Shared libraries paper.
Just open the terminal and type
export LD_LIBRARY_PATH=/path/to/your/libraries
sudo ldconfig
I've compiled clang to use it as a cross compiler for ARM (by configuring it with ./configure --target=armv7l-unknown-linux-gnueabihf ), but when I try to compile any C code, it tries to use /usr/bin/as. I already have binutils compiled for ARM, and they are in a separate directory. How do I direct clang (or llvm) to use the assembler that I specify?
try passing the --host option to configure which will cause all the cc ar etc utilities to prefix with armv7l-unknown-linux-gnueabihf-
eg:
./configure --host=armv7l-unknown-linux-gnueabihf --build=i686-unknown-linux-gnu
Since you are using configure with hopefully autotools take a look at:
automake Cross compiling
I've always had trouble configuring from the source directory using ./configure and gave up in the end. These days I always configure from a separate directory i.e. ..//configure although I'm told it's recommended to use an absolute path for configure.
Your ARM binutils should be installed in the same prefix you're using for clang and make sure that they're in the path when you configure & build clang - i.e. PATH=/some/prefix/bin:$PATH; /configure --target=armv7l-unknown-linux-gnueabihf. If you're keeping them in separate directories for packaging purposes then make install DESTDIR= should help.
I don't generally build clang but the buildscripts I use for devkitARM might be helpful - http://sourceforge.net/p/devkitpro/buildscripts/ci/c372699fc7b4de90eb044314ce5bed04db640291/tree/
I want all my C programs to be compiled with the options -Wall -pedantic -ansi by default. Is there a way to have Eclipse add these flags to the compiler command by default for all projects?
Assign CFLAGS to include those values, and have Eclipse run a tool that uses that environment variable by default when compiling (such as make).
You may have to specify environment variables before running Eclipse (and then they get inherited when Eclipse runs make) but there might be a way to specify default environment in Eclipse.
(I don't use Eclipse, so I'll have to see about installing and testing this; or maybe this answer can jog someone's memory, if so, feel free to edit.)
As an aside, you might want -std=c99 instead of -ansi. The -ansi option simply means -std=c89 or -std=c++98, depending on whether you're compiling C or C++, and both of those standards are showing their age.
I installed Eclipse inside a VM running Windows to test this, and, even though CFLAGS is in the environment, Eclipse doesn't use it. Eclipse also pretends (by displaying text like "make all" and "make clean") that it's running make in a few situations/projects I tried, when it is not really using make (probably using some internal engine). This answer was on the wrong track for Eclipse.
Assuming you are using Eclipse's internal builder goto Preferences->C/C++ Build->Settings
Choose the warnings section for the compiler, there are tick boxes for -Wall and -pedantic
For -ansi set in Miscellaneous
As the OP notes this is just for each project not a global setting
Eclipse on Windows: For a project: Properties -> C/C++ Build -> Setting than "Tool Setting" tab. select "CGG C++ Compiler" than at the right side you will see Command : g++
modify it to Command: g++ CFLAGS for instance if you like to have C++11 support modify as Command: g++ --std=c++11
PS: This modification will valid for only current project and for only current configuration. If you want it for all configurations modify each configuration (Run, Debug) similarly.
EDIT: I see that the OP runs Windows from a prior comment, however the following information may benefit users of Eclipse on the Linux platform, if Eclipse honors the alias.
Are you running Eclipse in Linux? If so, try aliasing the gcc command; run this at a terminal:
alias gcc='gcc -Wall -pedantic -ansi'
This is a common method in Linux to specify default parameters for an application. However, Eclipse might execute the actual gcc application and ignore the alias; I have not tested it.
Yes, Run as -> Run configuration -> 1st Tab is "Main" , choose the second tab(the one next to it) , you have there arguments box, paste -Wall -pedantic -ansi and just apply then run. Every next time you run you'll have these arguments as default