On Wed, 10 Sep 2014, Oleg Endo wrote: > On Wed, 2014-09-10 at 15:46 -0400, Hans-Peter Nilsson wrote: > > (Thanks to people CC'ed and others forgotten; I hope I > > incorporated at least some of everyone's suggestions.) > > > > [...] > > Also, the idea of using a *combined* tree here, has been challenged, > > so I toned down the wording from the actual "require" to the > > negation(!) and added an apologetic blurb. > > It says: > "Testing with a simulator makes use of a combined tree here; you can't > easily build newlib, required for simulator testing,..." > > I don't understand why newlib can't be built for simulator testing > easily outside of a combined tree.
Why would that be an improvement? At most it'd be break-even. > Are you referring to the separate > make all-gcc - build newlib - continue with full gcc build? It's not clear to me what you mean and I haven't done a build from newlib sources separate from gcc in any way. It seems to add at least one step and just remove the merge of the newlib tree. You'd also have to point at the newlib sources with separate configure-options. Why a separate "make all-gcc" if you can point it at the newlib sources from the beginning? Maybe it's still easier than "can't easily", maybe better with some other wording? I forgot to say "suggestions are welcome" (but wholesale rewrites aren't, sorry for sounding apologetic). > Or is it > just a coincidence that it works rather easily on SH? I don't know, have you actually tried it on other targets? I'd suggest you do that before any improvement suggestion. (I built arm-eabi and mcore-elf with the updated simtest-howto.html) Have you inspected the configuration and build logs? I see sh-elf doesn't use libgloss, so I'm leaning towards a tentative "yes" to your question. > " other alternatives exist. For example, binutils and simulators can be > built for the target, and installed beforehand." > > I still think we should somehow document how to do that. I assume you mean the general configure && make all install, as in binu+gdb/configure --target=... --prefix=... && make all install (Not forgetting to include .../bin in your $PATH.) > The info is > scattered out there on the net, but it'd be easier to have it on the > official doc pages. Maybe but please put that in the official documentation. This page isn't that; that'd be in the .texi pages or maybe the wiki depending on your taste. This is not the "build and install a simulator toolchain to develop your own programs" documentation, this is the "build a simulator to test gcc" howto. IMO this page will not improve by adding detailed instructions for several alternatives. The intended audience is people working on gcc but just about grasping the concept of a cross-compiler and who actually wants a reasonably simple way to test their patches on a wider set of targets than their native x86_64 box. brgds, H-P
