On Wednesday 29 August 2007 6:05:46 am Gregg Reynolds wrote: > On 8/28/07, Rob Landley <[EMAIL PROTECTED]> wrote: > ... > > > Building the entire project, including all cross compiler targets, the > > build currently does this: > > > > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \ > > -malign-functions=0 -o tcc tcc.c -lm -ldl > > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \ > > -malign-functions=0 -DTCC_TARGET_ARM -DTCC_ARM_EABI \ > > -o arm-tcc tcc.c -lm -ldl > > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \ > > -malign-functions=0 -DTCC_TARGET_C67 -o c67-tcc tcc.c -lm -ldl > > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \ > > -malign-functions=0 -DTCC_TARGET_PE -o i386-win32-tcc tcc.c -lm > > -ldl cc -O2 -Wall -c -o libtcc1.o libtcc1.c > > cc -c -o i386/alloca86.o i386/alloca86.S > > cc -c -o i386/bound-alloca86.o i386/bound-alloca86.S > > ar rcs libtcc1.a libtcc1.o i386/alloca86.o i386/bound-alloca86.o > > cc -O2 -Wall -c -o bcheck.o bcheck.c > > cc -O2 -g -Wall -fsigned-char -Os -mpreferred-stack-boundary=2 -m386 \ > > -malign-functions=0 -DLIBTCC -c -o libtcc.o tcc.c > > ar rcs libtcc.a libtcc.o > > > > The above can actually be _simplified_ somewhat, I suspect. Why, > > exactly, does this need more complexity than a very small shell script? > > I just came across http://kegel.com/crosstool/ and took a (very) quick > look at the code. It builds gcc/glibc across a gazillion platforms, > but it looks like it does it all with bunch of small shell scripts.
Unfortunately it's very version dependent (a separate case for each dot release of each tool on each platform, last I checked), and it also uses lots of version-specific patches. I looked at that before doing Firmware Linux... > Which is essentially what we'd want for tcc, only on a smaller and > less hairy scale, and with a simple configure/makefile instead of the > Autotools build system gcc uses. I think it's worth looking at as a > model for a tcc system, especially since a c compiler wants a c > standard lib. It would be nice to be able to tell the build system > something like "Go forth, and build ye me a tcc compiler with a uClibc > library!". Currently, tcc doesn't care what libc you're using. It links against libc.so which is usually a symlink to your system's default C library. A compiler like gcc has six interesting paths: 1) Where do the compiler-supplied headers live. (varargs.h and friends) 2) Where do the system headers live (stdio.h and friends) 3) Where do the compiler-supplied libraries live (libtcc1.a, crtbegin.o) 4) Where do the system libraries live (libc.so, crt1.o, etc) 5) Where do the other executables (cpp, ld) live. 6) Where do source files come from? (Current working directory.) The fact that #5 isn't just $PATH is because gcc is "special". A sane implementation wouldn't special case that one, or #6. So that's two header paths and two library paths to search, and you should be done. Now there are some special files you link against by default: libc.so and the crt* files. Here's Eric Andersen explaining to me what the crt*.o files do (I asked): http://busybox.net/lists/uclibc/2003-September/006857.html This thread is was educational too: http://busybox.net/lists/uclibc/2003-September/006871.html I believe --nostdlib makes it not link against the crt* files by default, as well as libc.so. My darn wrapper script zaps all the gcc paths and replaces them with explicit ones on the command line, and to do this right it has to know what they all _are_ as well as parse the gcc command line including some weird corner cases used by thing like the kernel build: http://landley.net/hg/firmware/file/827b76efba8e/sources/toys/gcc-uClibc.c I'm tring to remember the difference between crt1.o and crt0.o. I think the 1 version is thread-safe, or some such. I forget, and I can't find where I asked Erik... The reason you can't run a glibc version of gcc against uClibc is that pieces of gcc like libgcc_s.so link against their libc, and leak references to that libc. So if you ever divide by a 64 bit number on a 32 bit platform or weird corner cases like that, a reference to glibc sneaks into your uClibc program. Since libgcc is part of the gcc source code, the only way to build a version of that library which leaks a reference the _right_ libc is to rebuild gcc against uClibc, from source code. The way tcc handles this is not NOT LEAK. This is a much better solution, and there's no reason you can't have a single tcc binary link against glibc or uClibc simply by feeding it different search paths. Are the search paths currently configurable enough? No. But if you know what they _are_, you can fix that. :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel