Wary: upgrade glibc/gcc?

I am working on a recompile in T2 of the packages for the next major version jump of Wary, to "5.2".

Originally, I was thinking that glibc and gcc should stay at the same versions for the life of the Wary project, to help to ensure that packages stay working in later releases of Wary.

But, I'm not quite sure.

Glibc is currently version 2.10.1, latest in T2 is 2.13.

Gcc is currently 4.3.4, latest in T2 is 4.6.1.

The big question is, would bumping either of these packages to the latest version, break anything, in particular break any of the current collection of packages in the Wary repository?

I will send a pm to tempestuous, as I think that he know a lot about this topic.

Bumping glibc, and the libstdc++ in gcc, can break packages, especially libsdtc++. Yes, perhaps I should leave them at the current versions.


Posted on 31 Jul 2011, 20:52


Comments:

Posted on 31 Jul 2011, 22:53 by tempestuous
glibc and kernel
What I know about glibc, and to a lesser extent GCC, is that it affects kernel compatibility ie. kernel modules compiled after a glibc/gcc upgrade will most likely be totally incompatibile with the existing kernel and modules.
This is no problem if you intend to "lock off" your kernel and kernel modules, but any later kernel module additions would need to be compiled in the pre-upgrade environment.

The most sensible/flexible solution is to proceed with a glibc upgrade if it helps, but immediately make a new kernel and modules under this new environment.

Regarding the impact on libsdtc++, sorry, I don't know.


Posted on 31 Jul 2011, 23:37 by Terryphi
Retain compatibility of existing packages
Retaining the compatibility of existing packages is in my opinion the most important consideration. Unless there is a pressing need to upgrade glibc and gcc why bother?


Posted on 32 Jul 2011, 2:55 by maxerro
modular systems
For the sake of user-friendliness no, but for the sake of shear experimentation YES - if you can make it in a breeze you can offer it for closed testing. Otherwise it's not worth the hassle.

libstdc++ is (almost) never an issue on its own. Upgrading requires a whole new engine.


Posted on 1 Aug 2011, 8:26 by BarryK
Keep current glibc/gcc
Ok, I'll leave them at the current versions.



Posted on 1 Aug 2011, 14:41 by technosaurus
glibc/eglibc
Glibc and eglibc will allow you to provide backwards compatibility to a specific version iirc.
The reason most build kits have refrained from jumping to glibc v2.14 is that gnu decided to _almost_ completely drop support for RPC (can't compile new package with it, but it is still technically there for backwards compatibility)
eglibc doesn't usually do that sort of stuff, so if you are thinking of upgrading past v2.13, its probably a better choice.

If it matters, I do know that glibc prior to 2.12 have a "cprog" function that is an incorrect implementation and that gcc 4.6+ will add its own version to its libs... possible bloat if it ends up in every binary

You'd be in pretty good company with glibc 2.13 (or eglibc if you prefer the Debian crowd)


Posted on 1 Aug 2011, 18:15 by Terryphi
Remove or hide Fido
Slightly off topic but relevant to the next build of Wary:

Fido seems to cause some confusion for new users. Will you consider removing it or at least hiding it from new users? More advanced users who want to try it can be instructed what to do.


Posted on 1 Aug 2011, 19:09 by BarryK
Re fido
But, the window at first shutdown that offer 'administrator' or 'fido' has red letters stating do not choose fido.

Are people just ignoring that?



Posted on 1 Aug 2011, 23:42 by GCMartin
Supporting alternate userIDs
@Terryphi is sharing an observation that I have also. Seems that there are several approaches, depending on which PUP you are using to the "new" notion of additional userIDs in Puppyland,

The problem areas are[list][*]new user understanding as this does NOT resemble anything coming from a Windows environment.
[*]Non-savvy Linux users who are jumpting to Puppy Plaftform
[*]Inconsistencies across the PUP distros (spot/rido/Admisistrator/root/etc_ and these implementations
[*]The problems that the community now has when trying to support the user community via the forum for some problems which are encountered are due to rights and userIDs.[/list]Hope this helps


Posted on 1 Aug 2011, 24:02 by GCMartin
Supporting alternate userIDs
Pleaae delete the prior post by me. I tried but the system would NOT allow me to.

My post should read as follows:
@Terryphi is sharing an observation that I have also. Seems that there are several approaches, depending on which PUP you are using to the "new" notion of additional userIDs in Puppyland,

The problem areas are[list][*]new user understanding as this does NOT resemble anything coming from a Windows environment.
[*]Lack of understanding on the use of te userID and the steps necessary for users to get what they want/need.
[*]Non-savvy Linux users who are jumping to Puppy Plaftform
[*]ID inconsistencies across the PUP distros (spot/fido/Admisistrator/root/etc)
[*]The problems that the community now has when trying to support the user community via the forum for some problems which are encountered are due to rights and userIDs.[/list]Hope this helps


Posted on 2 Aug 2011, 4:23 by GCMartin
WARY upgrade
I opened this thread on a general Puppy-WARY problem here to appeal to the community for help. Hopefully they may be able to address this. But, it will require your assistance to review and add.

Hope this helps


Posted on 2 Aug 2011, 18:54 by BarryK
autotools
Right now, my old laptop is running, doing a T2 compile. This is supposed to be upgraded packages for the future Wary 5.2.

I upgraded autoconf, automake and m4, but I have had a rethink on that, and think it better if I roll those back.

if upgraded, they can cause compatibility problems with source packages that have been pre-configured with 'autogen.sh' using Wary's current autotools.

This first run through with T2 is discovering all sort of issues, and I will do another run when this one has finished.



Posted on 2 Aug 2011, 19:48 by gjuhasz
Pmount endless loop
I just recognized that if I put an empty CD into the CD rive, Pmount starts an endless loop trying handling it. No such problem in Lupu 5.2.5.
Does this problem originate in some T2 packages?


Posted on 3 Aug 2011, 12:28 by BarryK
T2 issues
I have posted a bunch of "advisories" and questions to the T2 mail-list (2-3 Aug 2011):

http://news.gmane.org/gmane.comp.t2.devel

No replies yet!

Maybe one of our Puppy-developer-T2-experts would have a suggestion about how to fix libvpx. ...I think the top guy in this area is kirk (FatDog64 creator).



Posted on 6 Aug 2011, 8:57 by kirk
T2
Sorry, Haven't did a T2 build since libvpx came out. Hoping to avoid a T2 build this year :) I can only tell you what you already know. Run the script that puts you in the T2 build sandbox. Then try compiling the package with T2's configure options and working from there.

Hopefully me and James will have fatdog64-520 final out soon, though I'm uploading beta7 this weekend.



Posted on 18 May 2012, 24:07 by Terryphi
Upgrade glibc/gcc?
I have posted a suggestion in the forum that it is time to consider upgrading glibc/gcc in Racy and Wary.

http://murga-linux.com/puppy/viewtopic.php?p=628234#628234