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