This is the mail archive of the crossgcc@sourceware.org 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] |
Other format: | [Raw text] |
Greetings, I had the same problem a few weeks ago, once i got it working i posted the patch on this board (check 2-3 week ago). Gets crosstool nice and static. Dan, I could make a more permanent patch suggestion if you think it could be of use? Btw, currently trying to build a native GCC (by using a built crosstool toolchain), not having much luck. If i make it (or not) i'll post a quick howto on the page. Btw my target is SH3. Best wishes Kristoffer Quoting "J. Robert Wyatt" <jamwyatt@cisco.com>: > > That was a great pointer and things are progressing well. Sadly, the time to > build a complete compiler is on the long side. I did notice that the > binutils are linking dynamically when I did an "export LDFLAGS=--static" ... > Is there a proper way to have the whole tool chain link statically? I only > want to run this configuration for a while and memory conservation during > the design phase isn't a big deal. > > Robert > > > On 8/4/05 11:40 AM, "Dan Kegel" <dank@kegel.com> wrote: > > > J. Robert Wyatt wrote: > >> The liberals, conservatives, and NDP were the party names when this term > was > >> likely coined ... Since I left, they renamed a few things ;-) > >> > >> So, that being said, if I wanted to use crosstool for this second > compiler, > >> what is the "preferred" way to have crosstool do the work of generating > the > >> host=target compiler? Would that be setting an environment variable like > >> "HOST" to be equal to the same as the target that was generated in the > first > >> build? As well, I guess that the "RESULT_TOP should be named different too > >> to avoid overwritting the first build? > > > > Well, most importantly, you have to set CC and friends to point to the > results > > of the first crosstool run > > before running crosstool for the second compiler; > > otherwise the resulting compiler won't run on your host, right? > > > > I've put a draft of an old script I used last > > year to do canadian cross builds at > > http://kegel.com/crosstool/canadian-foo.sh.txt > > > > Have a look at the function setCanadianCrossVariables() > > to see how I set variables when building the > > final compiler. > > > > Since you're not doing a full canadian cross, you might > > not need quite all the foo that's in there, but > > it might be a useful place to look to see which > > environment variables need to be set. > > - Dan > > ------ > Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ > Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com > > ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |