This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Marcus: > Heh, I can tell you that... they're built as part of libgcc, which > gets built whether you're building a bootstrap compiler or not. > That much isn't rocket science. See, I *knew* I'd draw out someone who actually knew! Knowledge wants to be free, thanks for saving me the research. :^) > The only reason gcc needs to rely on system headers and libraries is > for threading and shared library support (e.g. building a threaded > and/or shared version of libgcc and startup files) and for building > higher-level components like libiberty and g++. For System V ABI > targets, Linux, etc. it does *link* with startup files that don't > exist until glibc is built and installed. Oooh, let's constrain ourselves to the 2.95.x series, ok? I'm still reeling with the differences in 3.x... :^) I think I'm correct in saying that the "all-gcc" target stops before building libiberty, but after building libgcc, no? > Startup files are partially gcc's responsibility and partially ld's > responsibility - the linker script specifies the main startup file, > but gcc's specs often define "variants" of those startup files > (e.g. for C++ constructor/destructor code, profiling, etc.). Right. The -m options in particular. > Actually, if you do an unsigned 32-bit integer division on the SH > you do *need* __udivsi3_i4, whether you're building library code or > application code - it's a compiler intrinsic and you can't escape it > :P. Whether or not libgcc is linked statically or shared depends on > if you're using 3.0+, and whether you've bothered to build the full > compiler. Right, but you don't need the intrinsics until you actually try to do a fully-resolved link, i.e. an executable. > It's a Good Thing as long as you know how to "opt-out" of certain > compilerisms by using gcc's extensive options. I'd suggest anyone > seriously working with gcc read it's info pages, particulary the node > "Invoking GCC". Especially read up on target-specific options. Gcc is quite "opt-outable". That's (partly) why I likes it. b.g. -- Bill Gatliff bgat@billgatliff.com ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |