I am trying to better understand link-time optimization in GCC and -fuse-linker-plugin seems to matter in that context. However, I do not exactly understand how.
Suppose my compilation with link-time optimization looks like this:
gcc a.c -c -o a.o -flto -fno-fat-lto-objects
gcc b.c -c -o b.o -flto -fno-fat-lto-objects
gcc main.c -o main.out a.o b.o
What would be a good use case for enabling -fuse-linker-plugin?
I found the official GCC documentation somewhat confusing on that point. They suggest that -fuse-linker-plugin matters only for archive files (.a) but most conversation I have seen mentions that option without discussing archive files.
Related
I want to assemble and link some code for a 32-bit target from a 64-bit host, and I'm trying to use make's implicit rules as much as possible.
If I put -m32 in ASFLAGS it works fine for linking and assembling in one step, as make will use gcc for this. But if one of my executables needs separate linking, everything breaks, because make will then use as for assembling, and as doesn't understand -m32. To solve this I can use --32 instead, but this will of course not work with gcc.
$ cat Makefile
ASFLAGS = -m32
all: prog1 prog2
prog2: prog2.o
$ make
cc -m32 prog1.s -o prog1
as -m32 -o prog2.o prog2.s
as: unrecognized option '-m32'
<builtin>: recipe for target 'prog2.o' failed
make: *** [prog2.o] Error 1
Why does make use ASFLAGS for both gcc and as when their flags aren't compatible? Am I not supposed to specify the architecture this way? Do I really have to hack my way around this (i.e. actually write something in my Makefile), or is there something I've missed?
Since ASFLAGS is used by both LINK.s (gcc) and COMPILE.s (as) as you mentioned, one possible solution is to add following in the Makefile for compiling %.s with $(AS),
EXTRA_ASFLAGS = --32
%.o : %.s
$(AS) $(ASFLAGS) $(EXTRA_ASFLAGS) $(TARGET_MACH) -o $# $<
, or
COMPILE.s += --32
Well, you lied to make and as. If you put in ASFLAGS something that is not an assembler option, you're doing something out of spec.
make cannot know what options the compiler and assembler understand. To deal with this, make provides a way to specify the options for each tool separately: use CFLAGS for the compiler, ASFLAGS for the assembler, LDFLAGS for the link step.
I suggest using make CFLAGS=-m32 ASFLAGS=--32.
I use the following LLVM tools to convert a cpp project which is written in multiple files into "ONE" single assembly file.
clang *.cpp -S -emit-llvm
llvm-link *.s -S -o all.s
llc all.s -march=mips
Is there any way of doing this in GCC? In particular, is there any way of linking GCC generated assembly files into one assembly file? i.e., what is the equivalent of LLVM-LINK?
Perhaps LTO (Link Time Optimization) is what you want.
Then, compile each compilation unit with gcc -flto e.g.
gcc -flto -O -Wall -c src1.c
g++ -flto -O -Wall -c src2.cc
and use also -flto (and the same optimizations) to link them:
g++ -flto -O src1.o src2.o -lsomething
LTO works in GCC by putting, in each generated assembly file and object file, some representation of the internal GCC representations (like Gimple). See its documentation
You might want to use MELT to customize GCC (or simply use its probe to understand the Gimple, or try just gcc -fdump-tree-all).
I'm trying to combine object files created from C++ files into an executable using gcc. Unfortunately, gcc is giving me thousands of undefined reference errors to strings, arrays, etc.
I am doing this on a Windows machine, so no terminal commands; only cmd commands.
I'm simply doing:
gcc a.o b.o c.o -o prgm.exe
What am I missing/doing wrong?
EDIT:
I recreated the .o files with g++ doing:
g++ a.cpp -g -c -Wall -std=c++0x -lSDLmain -lSDL -lSDL_image -lSDL_ttf -IC:\SDL-1.2.14\include -o a.o, where a.cpp and a.o are the directories where i keep the files, not the g++ directory
Then, I did g++ a.o b.o c.o -o prgm.exe. This gave dozens (I guess that's an improvement?) errors like
undefined reference to `_SDL_SetColorKey'
but I included SDL didnt I?
The final error from this is:
c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../li
bmingw32.a(main.o):main.c:(.text.startup+0xa7): undefined reference to `_WinMain
#16'
collect2.exe: error: ld returned 1 exit status
int main(int argc, char * argv[]) is in the code
You are trying to link a C++ program with the C linker. You need to use g++ instead of gcc.
Generally speaking gcc is for compiling/linking C, while g++ is for C++. IIRC compiling C++-code with gcc works by virtue of dispatching according to the file extension. Linking C++ code with gcc however does not work, since it won't link the C++ standard libraries, resulting in your undefined reference errors.
If this does not solve your problem, you might want to give us a more concrete description of your errors and your system.
Based upon your updates then I think you'd need to do the following:
g++ a.cpp b.cpp c.cpp -g -Wall -IC:\SDL-1.2.14\include -LC:\SDL-1.2.14\lib -std=c++0x -lSDLmain -lSDL -lSDL_image -lSDL_ttf -o prgm.exe
I'm guessing C:\SDL-1.2.14\lib exists based upon where the headers are located.
GCC is the C compiler. Your code is C++ so you need to use G++ to do the linking:
g++ a.o b.o c.o -o prgm.exe
This automatically adds the C++ libraries to the link line, resolving many if not all of your missing references.
I would like to know if I can tell gcc/ld to omit unused modules from being put into the output file.
Suppose I have modules a.c, b.c and c.c. a.c and b.c depend on each other, one of them contains a main(), and due to whatever reasons, no parts of c.c are referenced.
gcc -c a.c
gcc -c b.c
gcc -c c.c
If I bundle the stuff together into a library, no code from c.c won't be in the output:
ar rcs abc.a a.o b.o c.o
gcc abc.a
But if I give the .o files directly to gcc, the code from c.c resp. c.o is included.
gcc a.o b.o c.o
Can I, by any way, tell gcc to leave out unused modules without putting them into a library?
I am programming an AVR µC and use AVR Studio, which doesn't allow the creation of libraries, but would like to omit the source files which are not used, depending on the build configuration.
I don't know if it's possible on AVR, but you could ask GCC to put each symbols in its own section using -ffunction-sections -fdata-sections at compile time. Then at link step, you could use -Wl,--gc-sections to ask ld to remove unused sections.
I'm trying to specify rpath in my binary.
My makefile looks like this-
CC=gcc
CFLAGS=-Wall
LDFLAGS= -rpath='../libs/'
main: main.c
gcc -o main main.c
clean:
rm -f main main.o
But when I query rpath using command readelf -a ./main | grep rpath I get nothing
I've tried specifying rpath as LDFLAGS= "-rpath=../libs/" but even that doesn't seem to work.
Can someone please post an example on how should I specify rpath in a makefile?
GCC and ld versions are-
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
GNU ld (GNU Binutils for Ubuntu) 2.21.0.20110327
If you set the variables, you should probably use them. It's silly not to, especially when make won't magically set those variables for you! :)
main: main.c
$(CC) $(CFLAGS) $(LDFLAGS) -o main main.c
Another problem is LDFLAGS, it should be
LDFLAGS="-Wl,-rpath,../libs/"
The usual gcc switch for passing options to linker is -Wl,, and it is needed because gcc itself may not understand the bare -rpath linker option. While some builds of various versions of gcc accept -rpath, I have never seen it documented in gcc man pages or info pages. For better portability, -Wl,-rpath should be preferred.