Talk:Updating GCC on rPath Linux

From rPath Wiki

I've been using rPath linux as a base development platform, upgrading packages here and there as needed. Now I may have happened upon a pandora's box, or I may have discovered a packaging error.

GCC starts life as 3.4.4. Poof. Do conary update and here's the result:

[root@fchuey ~]# conary  q -i gcc
Name      : gcc                Build time: Thu Aug 16 15:39:09 2007
Version   : 4.2.1-1-1          Label     : unsupported.rpath.org@rpl:1
Size      : 108803908
Pinned    : False
Flavor    : ~!bootstrap is: x86

And so on and so forth until you get to libstdc++ (initially 3.4.4, of course.) Libstdc++ has a dependency on libc which cannot be automatically resolved:

[root@fchuey ~]# conary update libstdc++=/conary.rpath.com@rpl:devel/4.2.1-1-1
The following dependencies could not be resolved:
   libstdc++:lib=4.2.1-1-1:
       soname: ELF32/libc.so.6(GLIBC_2.0 GLIBC_2.1 GLIBC_2.1.3 GLIBC_2.2 GLIBC_2.3 GLIBC_2.4 SysV  x86)

Ok, aside from the fact that conary should just go fix it, that seems reasonable. Now I try updating glibc too:

[root@fchuey ~]# conary update libstdc++=/conary.rpath.com@rpl:devel/4.2.1-1-1 glibc=/conary.rpath.com@rpl:devel/2.5-33-1
The following dependencies could not be resolved:
   glibc:devellib=2.5-33-1:
       trove: userspace-kernel-headers:devel
   glibc:devel=2.5-33-1:
       trove: userspace-kernel-headers:devel

Ick, I say, not wanting to put kernel-headers on my machine just to get libstdc++. Perhaps there is a different version which does not require kernel headers and is still new enough...

[root@fchuey ~]# conary update libstdc++=/conary.rpath.com@rpl:devel/4.2.1-1-1 glibc=/conary.rpath.com@rpl:devel/2.4-8-1
Troves being removed create unresolved dependencies:
   tzdata:runtime=2007c-3-0.2 requires glibc:runtime=2.3.6-8.8-1:
       file: /usr/sbin/tzdata-update

Urgh. Well as troubles go, this seems fairly light. Only one package depends on "old Glibc". But why oh why does it need old glibc? Why can't it use new glibc?

I did not track this problem down any further. Mainly because I wanted to ask if updating packages one at a time with conary was the way to go, or if there was some other tool...My grasp of Conary concepts is a little weak, but would this particular pandora's box be an appropriate application of a group trove? Collect together all the troves needed for new gcc and update all at once? Or is this rather an example of "trying to please all developers all the time"? In other words, by assimilating troves from multiple branches, am I placing myself in the position of needing to have all development setups simultaneously present on my machine? If the latter, is it perhaps wiser to ignore the low-hanging fruit of "cooked" troves and just cook 'em myself?

Bnordgren 20:30, 28 August 2007 (EDT)

The label on the gcc 4.2.1 package you updated to in the first step is "unsupported.rpath.org@rpl:1", which indicates that your system has been updated to a version of gcc outside the supported tool chain for rPath Linux 1. The most recent version of gcc supported on rPath Linux 1 is gcc=conary.rpath.com@rpl:1/3.4.4-9.4-1.

(Was the update to that version of gcc from unsupported.rpath.org intentional?)

Given the relatively tight coupling between gcc, glibc, libstdc++, etc., the described dependency problems are not unexpected, especially considering the major-number change (from 3 to 4) in gcc and the subsequent attempts to update to tool-chain components on the conary.rpath.com@rpl:devel label--components that have not been released as part of rPath Linux 1.

Do you have a specific need for gcc 4 on your system?

--Up2 15:34, 29 August 2007 (EDT)

I finally rolled everything back to 3.3.4 and packaged up my own build of 4.3.0 as a snapshot of the current gcc mainline. My requirement is for java 1.5/generics and that is introduced in 4.3.0. The fortran compiler doesn't work with my snapshot, but I don't need that. c/c++/java/libc/libstdc++ all compiled just fine. 4.3.0 is currently in "stage 2", so they're only allowing bugfixes from here till the release comes.