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] |
Joe: > a) build a bootstrap compiler, b) then build whatever library > support with said compiler, c) and THEN manually compile and link > whatever external stuff I need (other than barebones C support, > which was done in step b), would there be a problem? Depends on what you call "barebones C support". If you're talking just about "it understands the language, but has no support for the C runtime environment", then as long as you have the helper functions (which are technically part of the implementation environment, and not the runtime environment), I think you're ok with this procedure. > The black box I don't understand here is the aforementioned "helper > functions" that we've been talking about. If I want GCC to just be > dumb and act as a compiler, can I circumvent this third step of > recompiling the bootstrap compiler? The SH version of gcc has helper functions with names like __udivsi3, __ashlsi3, and __mulsi3, which implement primitive operations that aren't natively supported by the microprocessor. I'm not intimately familiar with very many other gcc's, but I suspect that all ports have at least a few helper functions. Gcc inserts calls to these functions in the code it generates, rather than inline the equivalent asm code. The trouble is, I DON'T KNOW WHEN THESE FUNCTIONS ARE BUILT during the compiler construction process. Some of them are implemented in C (soft-float, for example), and so they *can't* be built by the bootstrap compiler because you don't have enough of an environment to build them. You don't need these functions to build libraries, obviously, but you do need them to build applications. The set of helper functions needed for any particular configuration and application is highly application and configuration specific. So I can't make a blanket statement like "you don't need anything other than the bootstrap compiler" without doing a lot of non-gratis research. > And as far as the simplicity of being able to just say > $ gcc hello.c > > Isn't that almost NEVER done in a real development situation > anyways? Whenever I set up make and Makefile, I'm usually passing > arguments of -c and -o to gcc. I can't speak for anyone else, but my stuff tends to be a mixture of -c's, -o's, and just straight gcc's, depending on what I'm up to that day. I think that gcc's automation of the whole process is an artifact of its native compiler heritage. This is a Good Thing, for me anyway. > So, am I jumping through all of these hoops to let gcc provide > features that I'm not going to use? Is there some easy way to tell > gcc when I build it that I don't want all of the collect2 nonsense > to be built? You're probably better off just trying to work with the setup how it is, until you get more comfortable with what it takes to change it. Who knows, you may even find out that you *like* gcc's current way of doing things! :^) 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] |