On Tue, Jan 03, 2006 at 10:39:06PM +0100, Laurent GUERBY wrote: > On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote: > > On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote: > > > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: > > > > > Actually, looking more closely, the libiberty.a is the only one > > > > > installed > > > > > that way (from the gcc sources). All others (for example > > > > > libstdc++.a) seem > > > > > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). > > > > > Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? > > > > > > > > Bingo. :-) http://gcc.gnu.org/PR16513 > > > > > > I wonder how many more examples like that we need before we impose > > > testing after install and not in tree... > > > > > > Only consequence for the few who configure with --prefix=/usr from their > > > tree will be to change to --prefix=/some/user/dir so install doesn't > > > break the system if the tested compiler is not up to the task. > > > > We can do this without touching --prefix, in fact, via DESTDIR and > > relocatable installs. > > I assume DESTDIR will suffer a lot of recurrent breakage if we still > test in tree when it goes in. > > > It's just a bit disruptive to the workflow, so I > > wanted to wait until toplevel bootstrap was settled first. > > Yes, another impact of testing after install is that > many small dev scripts will have to be changed to > make check after make install and not before.
No, you've missed my point. DESTDIR support (which we already have, and people use constantly) allows us to install a tree somewhere different than its configured --prefix. Relocatable toolchains (ditto) allow the toolchain to work when run from an address different than the configured --prefix. "make check", or even "make all", can finish with "make install DESTDIR=$top_objdir/install". That will generate an installed toolchain which behaves just like the final installed toolchain. -- Daniel Jacobowitz CodeSourcery
