gcc -o options query

[sed_y]

gcc -o options query
hi all,
I am using ubuntu 11.04 within vmware.
I have a following query.

for running and executing a C code , i can do following
1)
Compile but not link:

gcc –c  filename.c

Link using the object file:

gcc –c filename filename.o

2) Compile and link together :

gcc –o  filename  filename.c

however, i tried the following

gcc –o  filename.o  filename.c

this works, and creates a executable with .o extension. why? it should be a object file? though i did get 2 warnings regarding malloc ( which i was using in this code) when i gave the above option, but when i run

./filename.o

it gave me correct output. why? any help?

[hazel]

My guess is that gcc has both compiled and linked this program, but has slavishly given you the filename you asked for, even though the .o suffix is not appropriate for an executable. You can check by running the file command on it. An unlinked object file is reported as ELF 32-bit LSB relocatable, whereas a linked executable file is ELF 32-bit LSB executable.

[sed_y]

hi, i checked and filename.o is also a 64 bit executable. i guess compiler skips the .o and treats it as full name. for example, sometimes , by mistake, if u save a firl abc.jpg as abc.d.jpeg,
it still saves as jpeg as abc.d is treated as full name.

[hazel]

hi, i checked and filename.o is also a 64 bit executable. i guess compiler skips the .o and treats it as full name. for example, sometimes , by mistake, if u save a firl abc.jpg as abc.d.jpeg,
it still saves as jpeg as abc.d is treated as full name.

Yes, that's correct. In Unix systems like Linux, filenames can legally contain several periods. For example archive files that are assembled with tar and then compressed with gzip have names ending in ".tar.gz". But also Unix OS's attach less importance to suffixes than Windows does. Linux tends to identify file types by "magic numbers" (byte sequences that reliably occur at the beginning of certain types of file) rather than by suffixes.

Gcc is very sensitive to the suffix of its input file because that tells it what language the file is written in, but your experiment suggests that it doesn't take much notice of the suffix you give the output file. If you don't use the -c option, you get a linked executable, whatever you call it.

[sed_y]

yes,I guess that is the way it is.
so, we have a consensus