Someone else in my group built LD for my team to use. How can I tell if it was built with --enable-gold?
Check the symlink /usr/bin/ld via ls -al, if it links to ld.gold or ld.bfd. The rest should be obvious.
Note: Nameing might be slightly different, the above is true for ArchLinux. On other systems ld.gold might be called gold directly and ld.bfd could be called ld.
You are trying to comfirm how gcc is configured. So gcc -v will do the trick.
Related
With gcc, you can use the -L option to point to additional library directories. I can't find that option in th manpages in clang. How do we do this? I did find the -I for the include files directories however.
It's just -L, the Clang man pages are apparently still horridly incomplete.
gcc (or other compilers) often generate huge text output and it's very difficult to see where the error is or miss warnings. I've done some search but havn't found a clean simple solution to color code the compiler output (so for instance warnings are yellow, errors are red, etc...)
Gcc 4.9 seems to have added this feature via the -fdiagnostics-color flag:
here's an alternative if you are looking for something very simple:
#!/bin/bash -e
make ${#} 2>&1 | perl -wln -M'Term::ANSIColor' -e '
m/Building|gcc|g++|\bCC\b|\bcc\b/ and print "\e[1;32m", "$_", "\e[0m"
or
m/Error/i and print "\e[1;91m", "$_", "\e[0m"
or
m/Warning/i and print "\e[1;93m", "$_", "\e[0m"
or
m/Linking|\.a\b/ and print "\e[1;36m", "$_", "\e[0m"
or
print; '
Just alias your make to this script and make sure it's executable...
Debian and Ubuntu gives the colorgcc package for that purpose.
And I usually run gcc (and make) thru emacs with M-x compile then the messages are colorized.
addenda
GCC 4.9 has a native colorization facility and GCC 6 - released end of April 2016 - (and probably GCC 5 too) is enabling it by default (when stdout is a terminal).
Ok, I'll just leave a notice about my own (python based) tool also :)
It is called Pluggable Output Processor and designed not only to colorize output of one particular program. Here is sample GCC output before:
After:
See colorgcc, a perl script that coulours the gcc output.
How to install and use colorgcc to colorize your gcc compiler output:
At least 3 answers here so far mention colorgcc, but NONE OF THEM EXPLAIN HOW TO INSTALL IT! (And it's not obvious). So, here's how to install the latest version in Ubuntu!
Go here and click "Clone or download" --> "Download Zip". I saved it into "~/Downloads/Install_Files"
Navigate to it in your file browser and right click it and go to "Extract Here." I now have a directory called "~/Downloads/Install_Files/colorgcc-master".
Copy the "colorgcc.pl" script to "/usr/bin/colorgcc" to "install" it (be sure to use the correct directory according to where you extracted it above): sudo cp ~/Downloads/Install_Files/colorgcc-master/colorgcc.pl /usr/bin/colorgcc
Make it executable: sudo chmod +x /usr/bin/colorgcc
Make the "~/bin" directory if it does not yet exist: mkdir ~/bin
*Make symbolic links that point to "/usr/bin/colorgcc" so that whenever you call gcc or g++ it automatically calls colorgcc instead:
ln -s /usr/bin/colorgcc ~/bin/g++
ln -s /usr/bin/colorgcc ~/bin/gcc
(if you ever want to uninstall colorgcc for some reason just delete these symbolic links "~/bin/g++" and "~/bin/gcc", and the Perl script: "/usr/bin/colorgcc" and you're done)
Done!
Here is a sample g++ output now when I call g++ -Wall -std=c++11 time_until_overflow_2.cpp -o time_until_overflow_2:
*Note: making these symbolic links in "~/bin" only works if "~/bin" is in your PATH variable in a location before the folder where the actual gcc and g++ executables are located. To ensure you have "~/bin" in your path you can view the PATH variable contents with: echo $PATH. If you don't see "/home/YOUR_USERNAME/bin" at the beginning of your path, add it with: export PATH=~/bin:$PATH.
References:
See here for more info. and for where I originally learned most of these steps: https://imranfanaswala.wordpress.com/2009/02/02/setting-up-colorgcc/. Thanks Imran Fanaswala!
~GS
you can use GilCC which is a Ruby tool that will convert GCC output to color in real-time. Right now you have two choices: Perl script (colorGCC) or GilCC and if you already work with Ruby you will like GilCC.
Unique to GilCC; GilCC has warning and errors counters and also shows compile time, very handy when you are trying to improve things. Because it is in Ruby it is cross platform. It is flexible and you can add more gems to customize it anyway you want.
The link to the download page is here.
https://github.com/gilmotta/GilCC
Although GCC 4.9 has -fdiagnostics-color option to enable colored outputs to terminals, I have created a tiny tool called 'crror' to get colorized compiler output.
It supports outputs from make as well. I can add colorize patterns for other tools if anyone requires.
I'm trying to make the --dynamic-linker option work with CodeSourcery's ARM cross toolchain. However gcc seems to ignore it, and never adds an interpreter segment in the shared library's ELF. What am I missing to make this work?
I doubt gcc ignores the option. Add -v to the compiler command line to verify that the option is indeed passed to the linker.
More likely, you are using the option incorrectly. --dynamic-linker is taking a =file argument, and you didn't mention that you are passing one.
Edit: as you found out, you have no .interp section in your linker script. However, you should - see this example.
Lately I have been working on OS X. Things were going pretty peachy for a while until somehow ld got on my system and now gcc won't use dyld. Furthermore, all of my shared libraries are in *.dylib format, and ld is stubornly ignoring there existance. If I mv ld from PATH, gcc just complains it cant find ld.
Please help me to get gcc back on track and using what it should.
You can try some gcc options. From the man page:
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
You could then link explicitly using whatever linker you want.
Does it help to symlink ld to dyld?
mv /usr/bin/ld /usr/bin/ld.old
ln -s /usr/bin/dyld /usr/bin/ld
Edit: fixed ld params order
This isn't your exact question, but I had a need to switch to ld.gold, and for that, the -fuse-ld=gold option to gcc was very useful.
look at -Xlinker option
I got it from man gcc
you can double check using some verbose options like -v
if I understand the gcc manuals right than the option -print-prog-name should print the name of the program used.
But it seems that this option only echoes the given argument
Examples:
gcc -print-prog-name=ld
--> ld
gcc -print-prog-name=xxxsome-funny-name
--> xxxsome-funny-name
Is this the expected behaviour? I think it should print something like
gcc -print-prog-name=ld
--> /usr/bin/ld
gcc -print-prog-name=xxxsome-funny-name
--> unknown program
EDIT: testing on Debian Lenny 64bit with gcc v4.2.4
Meanwhile I found another reason for the behaviour of
gcc -print-prog-name=ld
The ld command is not invoked directly by gcc.
gcc invokes collect. And it is collect which in turn invokes ld.
I think the -print-prog-name option only applies to a small set of tools that GCC
uses internally. For example,
$ gcc -print-prog-name=cc1
/usr/libexec/gcc/x86_64-redhat-linux/3.4.5/cc1
$ ls -L /usr/libexec/gcc/x86_64-redhat-linux/3.4.5/
cc1 cc1plus collect2 f771 jc1 jvgenmain
$ gcc -print-prog-name=f771
/usr/libexec/gcc/x86_64-redhat-linux/3.4.5/f771
So gcc -print-prog-name is aware of the tools that live in that directory. But:
$ gcc -print-prog-name=ld
ld
My guess is that if gcc -print-prog-name returns an absolute path, it's configured
to use that version of the program, no matter what's on your $PATH -- otherwise
it just echoes back what you gave it without resolving it to an absolute pathname.