Hello everyone
I am trying to learn about the compilation process. I am working on a pretty simple SDL game, but I know that making games isn't very practical, so I am using the project to learn about other programming aspects as well. One of the things I am trying to learn about it the full compilation process, in detail. I have found an interesting article on the subject at: http://www.lisha.ufsc.br/teaching/os/exercise/hello.html
However, I followed the same steps the author of the article did, and I am having a lot of trouble in the linking stage. When I do the same thing the author did, I end up with a lot of undefined reference errors. If I link without the -static flag, it looks like it works, but when I try to run the executable, I get the error bash: ./hello: No such file or directory (which is not true, I can confirm that it exists and has the correct permissions with "file" and "ls -lA"). I thought that maybe the issue was my 64 bit processor and I was linking against some 32-bit libs, so I tried linking against libs from /usr/lib64/ instead on /usr/lib/ but the result was the same.
If I can't get this simple "hello world" code to build correctly, my game certainly won't. What am I missing?
I am using linux and gcc, if that isn't obvious.
gcc version 4.3.3
Compiling hello.c
<<snip>>
[B]
I thnk you got every step............Plz rate me i also want to get answers[/B]uncool_jatish,
YOU PLAGIARIZING <<flower>>
if you're going to beg for "ratings" by stealing someone else's work, at least have the common courtesy to paraphrase your source material rather than posting it verbatim.
or do you think we're so stupid we can't find where you cut and paste from?
http://www.linfo.org/create_c1.html
.
If ur so capble y didn't u answer my question
I didn't said u wrong words ............
my Parents and teachers didn't teach me like this
If ur Then get talking i does effect my reputation
dont bring your parents and teachers into this. they're already terribly upset at how spectacularly they FAILED with you.
seriously, <<snip, snip, snip & snip>>
@prushik
You may well find it easier, initially to link through gcc (or g++) Both of these programs are really entry points onto the entire tool chain rather than actual compilers which is why you have to issue them the -c switch to make the only compile. Similarly to can get then to just link by simple putting obejct files on there command line try gcc hello.o -o hello .
Calling through the entry point like this helps because it automatically adds things that are normally the same every time. you can call ld directly if you want but in my opinion it is only worth doing if you really need to call ld in a way that is different to how gcc calls it.
BTW what hasn't been said yet is that for embedded programming there is often (sometimes) a third step after linking as follows
compile
link
locate
Generally all platforms require you compile and link but linking tends to produce a relocatable executable image, that is an executable image that can be run from any memory location. For some embedded platforms they are expecting the image to be in a specific place in platform memory and the program loader is expecting the image to know where it is supposed to be located.
On platforms like this you run the relocatable image through a locator to produce an executable image for a specific location in memory.
Like I said generally this applies only to some embedded platforms in my experience.
dont bring your parents and teachers into this. they're already terribly upset at how spectacularly they FAILED with you.
seriously, <<snip, snip, snip & snip>>
You're currently this --> || close to getting (another) "keep it pleasant" infraction, which will get you banned for the next 6 months.
Have a smoke, do some yoga, drink a beer and come back when you're cooled down. Seriously.
Nobody has really answered my question. Banfa was the closest.
Maybe I didn't make myself clear before. I know how to compile c source code. I know I can just call "gcc hello.c -o hello" and end up with a working executable. However, that is not what I want. I want to know exactly all the little things that "gcc hello.c -o hello" does, and I want to be able to do all those little things myself. I want to call "cpp", "cc", "as", and "ld" separately so I understand the process completely.
If you want to see what's happening, then do gcc -v -o hello hello.c It will print out the full command lines generated for the compiler, assembler and linker.
If you really wanted to, you could do the same things yourself. But doing so is highly specific to your current setup (which is why the recipe you followed on the site you referenced didn't quite work for you).
If you want to see what's happening, then do
gcc -v -o hello hello.cIt will print out the full command lines generated for the compiler, assembler and linker.If you really wanted to, you could do the same things yourself. But doing so is highly specific to your current setup (which is why the recipe you followed on the site you referenced didn't quite work for you).
Well I tried that, I guess I didn't look at the output close enough, I didn't think that it was what I wanted. I ran it again, and I can see where it calls cc and as but it never calls ld. At the end of the process it calls a program called collect2, which seems to be the same as ld. I am not sure why its called collect2 instead. Is collect2 my linker?
/usr/lib/gcc/x86_64-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../.. /tmp/ccaeIJt4.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crtn.oA quick Google produces http://gcc.gnu.org/onlinedocs/gccint/Collect2.html
So the answer (reading that) is no collect2 invokes your linker for you but might well be the program you run when you execute ld.
Everything wraps something else which comes back to my point of why make things complicated trying to invoke ld yourself when you can invoke it through gcc and take the complications out of it. Producing good programs is more than hard enough without setting yourself extra challenges especially when anything you learn doing this will stop applying the moment you start using a different tool chain.
Also note in post #6 I said to invoke gcc on objects not on C files as you implied in post #8.
letting gcc do all the work doesn't make the process less complicated, it just hides it from me. That the reason I use linux in the first place, because I want to know whats going on. I want to know everything thats getting linked in to my executable. Thanks for the info
Knowing the link command line will not let you know what gets linked into you executable because the linker only includes the bits of a library that are needed and if non of the library is needed then the library might be on the link command line but it is not getting linked into your executable.
If you want to know what has been linked into your executable use a utility like nm that will tell you based on what is in the executable file.
Wanting to know what is going on is commendable but in my opinion you are taking it to an unnecessary level of detail when you could use your time more usefully learning something you will use more often.
However its your time so you may send it how you choose :-)
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.