Sorry for the gory details below. I know no other way
to communicate exactly what I did, what I found, &c, so
someone can find the build bug (or my config bug).
Todd Lyons writes:
:: Dean S. Messing wrote on Mon, Jan 06, 2003 at 12:28:14PM -0800 :
:: >
:: > + ln -s /usr/include/libgcj-3.2.1
:/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/libgcj
:: > ln:
:`/var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.1/include/libgcj':
: File exists
:: > error: Bad exit status from /var/tmp/rpm-tmp.71143 (%install)
:: > The problem is that there is already a file (link) in
:: > /var/tmp/gcc-3.2.1-root/usr/lib/gcc-lib/athlon-mandrake-linux-gnu/3.2.1/include/
:: > called `libgcj'. It points to `root/etc/alternatives/libgcj'
:: > so when the above link is attempted, it fails.
:: > Surely other athlon users have run across this? But I've not seen
:: > anything mentioned. I went over the cooker archives and see nothing.
::
:: Can you isolate
:: 1) Does the link already exist in some tarball (almost certaily no).
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. In the etc/ subdir there's an empty alternatives/ subdir.
They are also present in the BUILD/gcc-3.2.1/blah-blah diretory in /usr/src/RPM
and are created during build. (Sorry I don't remember exactly the path.)
On my PIII laptop the link I mentioned in the
first message and the above subdirs don't exist
and hence the bomb-out never occurs.
:: 2) Does the link get made by some earlier invocation of
:: update-alternatives?
I don't understand update-alternatives at all except from what little
I read in the man page. In trying to trace the error I think I
found a possible source in the .spec file but I really don't
understand it enough to say for sure.
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
in the .spec file. But again I really don't understand what
"update-alternatives" does or why these lines would be triggered on one
machine and not other (but see differences between machines below).
:: 3) Can you ascertain exactly where it gets created?
No. I'm too ignorant of the process.
:: 4) Does it do the same thing if you do everything by hand?
Didn't try, but I seriously doublt it because the .spec file
contains the explicit `ln -s' commands that cause the failure.
And, as I said, I believe the offensive "alternatives" stuff is called
from the .spec file also.
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).
It's rpm was gcc-3.2-4mdk.athlon.rpm
The second difference was that on the working system only
libgcj3-3.2-1mdk.i586.rpm
libgcj3-devel-3.2-1mdk.i586.rpm
were present.
On the non-working system
libgcj3-3.2-4mdk.athlon.rpm
libgcj3-devel-3.2-4mdk.athlon.rpm
libgcj3-static-devel-3.2-4mdk.athlon.rpm
were present.
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)
and then issuing
rpm --short-circuit -bi gcc.spec
It then correctly did the "install" in /var/tmp/gcc-3.2.1-root
and built .rpm's.
The astute reader will now be wondering why, when I reported
the error the messages refer to `i586-mandrake-linux-gnu'
whereas the above installed .rpm's have "athlon" in their name
(so that the messages should have had `athlon-mandrake-linux-gnu'
in them.
It is because when I first started to get the error, in order
to simplify things, I got rid of my /etc/rpmrc which builds
for athlon-mp. This did not get rid of the build bomb-out so
I reported errors relative to a vanilla i586 build (on my athlon) to
avoid someone saying "It must be your /etc/rpmrc file".
After I discovered how to make it work (with user intervention) I put
the /etc/rpmrc file back and re-built for athlon.
:: I'm really just replying to this to acknowledge your message. I know
:: that nothing I've written above is something you couldn't do on your own
:: (and probably already have), but I saw your "was this a faux pas"
:: message and just wanted to send the acknowledgement.
::
:: Blue skies... Todd
Thanks Todd.
So when I find bugs is it OK to report them here as I did?
Shall I assume they will get seen even if there's no ack?
I'm afraid that when it comes to complex (for me) .rpm build processes
like gcc or the kernel I'm not much help for actually tracing
the bug much further than I did.
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.
Dean
P.S.
I ask again: why can't I digestify the cooker list?
Can someone look into this. I really want to track
this list and help if I can but the constant dribble
of mail is Messing (pun intended) me around.
Dean S. Messing
Display Algorithms & Visual Optimization Lab
Information Systems Technologies Dept.
Sharp Laboratories of America
E-Mail: [EMAIL PROTECTED]
