https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #32 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #31) > > --- Comment #29 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > [...] > > Ok, what's the minimum configuration I need to build here? > > > > srcdir/configure --build=sparc-sun-solaris2.11 > > > > srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as > > --without-gnu-ld > > > > ?? > > srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as > --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld OK, I'll add this to my notes. Thanks. BTW, the above seems like it would be a perfect thing to put in /etc/motd :). > > should do the trick. > > Preferably prepend /usr/gnu/bin to PATH. > > > I really don't care how it builds, I just want the bare minimum so I can > > bootstrap and run tests. > > > > A minor rant, but why can't all this be set up automatically in the compile > > farm machines? Keeping track of minor nuances of each architecture is > > distracting. They should all be set up, whether by setting default paths in > > Agreed, but you always run into stuff like this when leaving Linux (like > AIX, HP-UX, or macOS). PATHs won't help much for reasons explained in > install.texi. > > > /etc/profile or whatever, or by having the relevant patches in GCC's source > > base, such that they work with src/configure && make. > > But what should be the default: GNU or native tools? You have choices > here and need to decide what you need/want. No one can do this for you. My guess would be to use gnu tools if available, cause those would be "guaranteed" to work correctly to build gcc? > > > I know this isn't your fault, but if more cfarm boxes where set up to go > > with > > no surprises, I'd add more boxen to my testing harness. > > Well, I *did* set up the Solaris cfarm systems, actually ;-) I see your > point, but things are not that simple unfortunately. And GCC's > configure doesn't need to cater to users of the cfarm only... > > Some of the issues (like the need for --build) have been caused by > upstream (like the config.guess maintainers that refuse to listen to > reason ;-). I thought about improving the --with-as/ld situation; maybe > something can be done there. Thanks for the explanation.
