I am using GCC and I want to essentially read and load the stdlib/libc stuff from another location than /usr/include and /usr/lib. I tried to copy them to another place and compile it like this, but it doesn't work. I am not surprised that this naive approach didn't work, but it was worth a try.
gcc -nostdlib -nolibc -I<custompath>/include -L<custompath>/lib -xc test.c
Could someone nudge me in the right direction here?
With this command:
gcc -nostdlib -nolibc ...
you are asking GCC to not link with libc.
Of course it doesn't work (if your program is using libc functions). What did you expect?
Start by dropping these two flags. And if the result doesn't work then, tell us exactly what doesn't work (by editing your question).
See also documentation for the -sysroot option.
Related
I want to know when i should use ld linker instead off gcc. I just wrote a simply hello world in c++, of course i include iostream library. If i want make a binary file with gcc i just use:
g++ hello hello.cpp
and i've got my binary file.
Later i try to use ld linker. To get object file i use:
g++ -c hello.cpp. Ok that was easy, but the link command was horrible long:
ld -o hello.out hello.o \
-L /usr/lib/gcc/x86_64-linux-gnu/4.8.4/ \
/usr/lib/gcc/x86_64-linux-gnu/4.8.4/crtbegin.o \
/usr/lib/gcc/x86_64-linux-gnu/4.8.4/crtend.o \
/usr/lib/x86_64-linux-gnu/crti.o \
/usr/lib/x86_64-linux-gnu/crtn.o \
/usr/lib/x86_64-linux-gnu/crt1.o \
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -lstdc++ -lc
I know fact that gcc uses the ld.
Using gcc is better in all cases or just in most cases? Please, tell me somethink about cases where ld linker has advantage.
As you mentioned, gcc merely acts as a front-end to ld at link time; it passes all the linker directives (options, default/system libraries, etc..), and makes sure everything fits together nicely by taking care of all these toolchain-specific details for you.
I believe it's best to consider the GNU toolchain as a whole, tightly integrated environment (as anyone with an experience of building toolchains for some exotic embedded platforms with, say, dietlibc integration will probably agree).
Unless you have some very specific platform integration requirements, or have reasons not to use gcc, I can hardly think of any advantage of invoking ld directly for linking. Any extra linker-specific option you may require could easily be specified with the -Wl, prefix on the gcc command line (if not already available as a plain gcc option).
It is mostly a matter of taste: you would use ld directly when the command-lines are simpler than using gcc. That would be when you are just using the linker to manipulate a small number of shared objects, e.g., to create a shared library with few dependencies.
Because you can pass options to ld via the -Wl option, often people will recommend just using gcc to manage the command-line.
I'm working on setting up autotools for a large code base that was once just a bash script compile and later just hand written Makefiles.
We have a set of files that require that compiler optimizations be turned off. These files are already in their own subdirectory, so they will have their own Makefile.am.
What's the proper way to drop any existing compiler optimizations and force a -O0 flag on the compiler for these specific files?
I went with Brett Hale's comment to use subpackages. I was able to insert
: ${CFLAGS="-O0"}
before AC_PROG_CC, which sets the appropriate optimization. The other solutions do not work, since the -g -O2 was getting added very last. You can never get another -O variable after it.
You don't have to remove existing optimizations: the last value of -O on the compiler invocation will be used, so it's good enough to just add -O0 at the end.
This is not directly supported by automake, but there's a trick you can use defined in the documentation.
Otherwise if you know you'll only ever invoke your makefile with GNU make you can play other tricks that are GNU make specific; you may have to disable automake warnings about non-portable content.
Trying to compile something for 64 bit unix using Ubuntu. As a disclaimer I only started using linux and gcc a few days ago so still learning my way around. Anyway, getting the following error:
/home/myuser/myproject/myfile.cpp:437: undefined reference to `clock_gettime'
A quick google reveals I need the -lrt option to link with librt.a. So I check my command line ( formatted for readability, different file names and I've remove lists of file names ):
/usr/bin/g++
-Wl,
--gc-sections
-fno-exceptions
-m64
-B/usr/bin
-o
"/home/myuser/myproject"
-Wl,
-Map, "/home/myuser/myproject/myproject.map"
-g
"/home/myuser/myproject/myproject.cpp.obj"
..and some more .objs..
-Xlinker
--start-group
"-lpthread"
"-lrt"
"/home/myuser/myproject/lib/mylib.a"
..and some more .as..
-Xlinker
--end-group
Hmm. Looks like -lrt is already there, maybe I don't have librt.a? Nope searching all files reveals I have /usr/lib/x86_64-linux-gnu/librt.a. I guess g++ is looking in the wrong place. So in the above command line I replace -lrt with /usr/lib/x86_64-linux-gnu/librt.a and bingo! it compiles and links fine. Unfortunately, this is an automated tool and I need this to work on many computers and can't make assumptions about the location of librt.a so I really need it to work with -lrt. So how do I set the local libary search path? First attempt is changing LD_LIBRARY_PATH environment variable but apparently ( from what I can tell from more googling ) this is ignored on ubuntu and instead I should be messing with .conf files in /etc/ld.so.conf.d/, however I already it looks like I already have x86_64-linux-gnu.conf in there with the following lines:
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
From my reading up this point it looks that should be all I need. Kind of stuck as to where to go from here...
Answering my own question just in case someone else has this problem. Turns out the correct librt.a was being linked but the linker is very sensitive to the link order. Putting -lrt and -lpthread at the end of the group fixes the problem.
I am interested in seeing the code where gcc has actually optimized the code. Is there a way I could do?
I have gone through few other similar questoins, I have tried following few things,
-Wa,ahl=filename.lst :- this option is really good, you can browse the code and corresponding machine code, but it is not good when I enable O3 option.
Dumping optimized tree :- I am sure gcc is giving me good amount of debug information. But I do not how to decipher it. I will be glad if someone could point to any available information.
Is there any other better way, to find out what part of the code gcc optimized?
Thanks,
Madhur
You can compile the code twice, first with:
$ gcc -O0 -S -o yourfile_o0.s
Then with:
$ gcc -O3 -S -o yourfile_o3.s
Then you can diff the two resulting assembly files:
$ diff -u yourfile_o0.s yourfile_o3.s
$ vim -d yourfile_o0.s yourfile_o3.s
$ emacs --eval '(ediff "yourfile_o0.s" "yourfile_o3.s")'
Look at the assember code or decompile your compiled application. C decompilers produce ugly C code, but for analyzing which code was generated, it have to suffice.
I am building a large project with a makefile that was originally built with icpc, and now I need to get it running with g++.
When it compiles the file that uses openmp, it uses the -c flag, and doesn't use any libraries, so it ends up being serial instead of openmp. All of the examples I am seeing aren't using this -c flag.
Is there some way to compile without linking, but using openmp?
edit:
I've been using the -lgomp flag(and the library is on the library path):
g++ -lgomp -c -w -O4 mainS.cpp
g++: -lgomp: linker input file unused because linking not done
Edit: my boss made several mistakes in the code, the makefile, and the documentation. Sorry to have wasted your time, at least it was less than the 5 hours I spend on it =/
Are you passing the flag to enable OpenMP (IIRC it's something like -fopenmp? If you don't chances are the compiler will ignore the OpenMP-related primitives and just produce serial code.
I don't think that -c (ie, compile only, don't like) has anything to do with your problem.
Perhaps the documentation helps...