On Tue, 2003-01-07 at 23:26, Dean S. Messing wrote: > No it is getting created during the build. I discovered, also, > that after the build bomb-out one finds in > /var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/ > a `root/' directory in which there is both a usr/ subdir and an etc/ > subdir.
This is normal. This is the buildroot directory. It's where RPM gets the files to put into the package. > The lines I suspected of creating the alternative stuff > were: > > %if %{build_java} > %post -n libgcj%{libjava_major}-devel > update-alternatives --install %{_includedir}/libgcj libgcj >%{_includedir}/libgcj-%{version} %{gcj_alternative_priority} > %endif These lines are executed at install-time, not compile time. > Didn't try, but I seriously doublt it because the .spec file > contains the explicit `ln -s' commands that cause the failure. ln -s is not causing the failure. The failure is caused by said symbolic link already existing. Which is why Todd and I both had the initial question: are you 100% sure your buildroot was empty? > I did discover two differences between the system on which it > builds and the one on which it does not. > The working system had a stock Mdk 9.0 installation of gcc-3.2-1mdk.i586.rpm. > The non-working system had a re-build of the cooker gcc-3.2 from > around Nov 25th. built for an athlon-mp. (This was necessary to > get MPlayer to compile). Again leads me to believe that the symlink was leftover from that build. > I did "solve" the problem by deleting the link and root/etc/ directories > deep down in the /usr/src/RPM/BUILD/gcc-3.2.1 (again, sorry > for not remembering exactly where) You mean /var/tmp/gcc-3.2.1-buildroot/etc. > So when I find bugs is it OK to report them here as I did? Yes. Although this wasn't technically a 'bug'. > Shall I assume they will get seen even if there's no ack? They will get seen. But it's always possible that nobody will have time to work on it. > If someone instructs me on what, exactly, to do to trace this > I'll do it. Problem is that now that I have installed the > latest gcc the bug may vanish, if it had anything to do > with the above machine differences. Do this: # rm -fr /var/tmp/*root # rm -fr /usr/src/RPM/BUILD/* # rm -fr /usr/src/RPM/tmp/* before you try to build anything, and you won't have any problems like this. Best of luck, Austin -- Austin Acton Hon.B.Sc. Synthetic Organic Chemist, Teaching Assistant Department of Chemistry, York University, Toronto MandrakeClub Volunteer (www.mandrakeclub.com) homepage: www.groundstate.ca