Bug 8377 – Upgrade Guides feedback (Gentoo 1.4 Upgrade Guide)

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Ferris McCormick (RETIRED) 2002-09-25 14:16:58 UTC]

I am not sure these comments reflect errors, nor am I sure they are not specific to my installation, but here they are anyway.

I recently received GenToo's invitation to try the 1.1a-r1 --> 1.4 upgrade scripts, and, having a spare disk, decided to try them.  In summary, using them as a guide, I 'easily' upgraded to release 1.4 (I think), but just running the scripts fails:  For me, on Gentoo 1.1a-r1 (sparc64), if I set
'ARCH=sparc64' in script2 and run it, everything seems to go OK, but the resulting utilities are unusable because the new lib[bfd/opcodes]-2.13.90... libraries don't build/install.  I.e., (gcc-3.2 + binutils-2.11.92) cannot build binutils-2.13.90, although they think they can.  (Actually, it's a little worse:  the rebuilt 'ar' just Segfaults.)

If I build gcc-3.2, then force gcc-2.95.3 to build binutils-2.13.90 (using,
if I recall, libgcc_s.so from the 3.2 build), then binutils-2.13.90 is good
enough that I can use (gcc-2.95.3 + binutils-2.13.90), and script2 then
results in a good installation.

Script3 then rebuilds most everything, and there is nothing left for script4
to do (fairness in reporting requires me to indicate that rather than running script3, I ran the ebuild by hand).

As a side comment:  I noticed that xfree86 got rebuilt very early in the
update process (before glibc), so for fun I decided to try rebuilding it
once again after everything else was installed.  I notice something similar to my binutils situation:  The script3-build version works fine, but I am
unable to rebuild it using my architecture-dependent optimization flags for
gcc (which for this system are '-mcpu=v8 -mtune=ultrasparc' -O2 -pipe').
The failures are varied, but seem to be related to XF86's dynamic loading
mechanism (the rebuilt programs are fine).

[Comment 1 Ferris McCormick (RETIRED) 2002-09-29 14:01:09 UTC]

Concerning my second comment (regarding xfree86).


Another round of the form
  emerge gcc ; emerge glibc; emerge xfree
yields a working build for XF86.  In this round, however, I did force the
CFLAGS to include '-Dlinux -Dunix' since I don't trust the gcc fixup-header-files procedure to be foolproof.  (I wish the GNU people would
make up their minds; for me, linux versions of gcc did not -Dlinux on
sparc linux systems; gcc2.95.3 does '-Dlinux -Dunix', and gcc3.2 does not.
Perhaps the system update documentation should note this? Or maybe I should
look at the gcc documentation for incompatibilities?)

[Comment 2 John Davis (zhen) (RETIRED) 2002-11-24 11:10:00 UTC]

Can you fix any of this?

//ZhEN

[Comment 3 Jack Morgan (RETIRED) 2003-05-17 23:44:17 UTC]

I don't think we have many users upgrading from 1.0 profile to 1.4 profile on sparc so closing this bug.