Date: Fri, 10 Mar 2000 19:49:32 -0500 (EST) From: Chuck Robey <chuckr@picnic.mat.net> To: Oscar Bonilla <obonilla@fisicc-ufm.edu> Cc: Alfred Perlstein <bright@wintelcom.net>, Kris Kennaway <kris@hub.freebsd.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: inner workings of the C compiler Message-ID: <Pine.BSF.4.21.0003101939150.32633-100000@picnic.mat.net> In-Reply-To: <20000310182602.A94174@fisicc-ufm.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Mar 2000, Oscar Bonilla wrote: > On Fri, Mar 10, 2000 at 06:51:20PM -0500, Chuck Robey wrote: > > I wasn't reading this too closely, but if you're trying to hand feed in > > the object files, the C startup object file *MUST* come first in the list > > of object files, because it's gotta link at the lowest address ... > > > > Is that it? > > Ok, I'm even more puzzled than before... This is just for a simple C program, no C++? I've been working in 2.2 and 3.4 lately, but I'll show you the trick I use, done this time for -current. Here's the trick. Write yourself a little C program, something that uses at least one include file. I don't give a damn what it does, but when you compile it, use the -v flag: gcc -v -o testme testme.c That -v flag is great for what you want, because it shows you what gcc itself is doing to get good linkages: chuckr:/usr1/chuckr:167 >gcc -v -o testme testme.c Using builtin specs. gcc version 2.95.2 19991024 (release) /usr/libexec/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -Dunix -D__FreeBSD__=4 -D__FreeBSD_cc_version=400004 -D__i386__ -D__unix__ -D__FreeBSD__=4 -D__FreeBSD_cc_version=400004 -D__i386 -D__unix -Acpu(i386) -Amachine(i386) -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__ELF__ testme.c /tmp/ccD35733.i GNU CPP version 2.95.2 19991024 (release) (i386 FreeBSD/ELF) #include "..." search starts here: #include <...> search starts here: /usr/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/include/g++ End of omitted list. /usr/libexec/cc1 /tmp/ccD35733.i -quiet -dumpbase testme.c -version -o /tmp/ccj35733.s GNU C version 2.95.2 19991024 (release) (i386-unknown-freebsd) compiled by GNU C version 2.95.2 19991024 (release). /usr/libexec/elf/as -v -o /tmp/ccn35733.o /tmp/ccj35733.s GNU assembler version 2.9.1 (i386-unknown-freebsdelf), using BFD version 2.9.1 /usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1 -o testme /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/libexec/elf -L/usr/libexec -L/usr/lib /tmp/ccn35733.o /usr/lib/libgcc.a -lc /usr/lib/libgcc.a /usr/lib/crtend.o /usr/lib/crtn.o Notice here the order it links, and what files it links in. First, if you're using nostdlib, then you have to call out your own libs, all of them, and you forgot to do libgcc. I've been able to move the lib calls before and after the object files, so I don't think that order matters, as long as you get both, but the objects (in order) are: crt1.o crti.o crtbegin.o ccn35733.o (your obj, that is) , then crtend.o crtn.o It calls out the ld-elf.so.1, but I don't think that's really linked in. I've been doing all my stuff statically linked, so I could be wrong on that part of it. I don't think you need to care about the -L calls, because when you use the full path, -L doesn't really matter. Always remember that -v, when your messing with tools. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0003101939150.32633-100000>