public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Edenfield <kutulu@kutulu.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Downgrade glibc-2.11 to 2.10
Date: Tue, 17 Nov 2009 14:35:48 -0500	[thread overview]
Message-ID: <4B02FB14.1040808@kutulu.org> (raw)
In-Reply-To: <200911171806.45373.alan.mckinnon@gmail.com>

On 11/17/2009 11:06 AM, Alan McKinnon wrote:
> Yes, I have read this in
> /var/portage/sys-libs/glibc/files/eblits/pkg_setup.eblit
> and I understand the risks.
>
> if has_version '>'${CATEGORY}/${PF} ; then
>    eerror "Sanity check to keep you from breaking your system:"
>    eerror " Downgrading glibc is not supported and a sure way to destruction"
>    die "aborting to save your system"
> fi
>
> I want to do it anyway.

I have never done this on a package-managed system but I did have to 
downgrade glibc on a slackware system once.  It's very VERY ugly; all 
kinds of implementation details get exposed as special symbols, or new 
symbol versions, or whatever, that make going backwards a mess.

The way I was told to do it was to get a compiled copy of lower glibc 
version into an alternative install path, like /usr/local/glibc, and 
rebuild everything against that copy.  You could have emerge build 2.10 
into an alternative --root, or go get a binary package of 2.10 and 
uncompress it somewhere.  Then update CFLAGS and LDFLAGS to include the 
correct -L and -I parameters pointing to 
/usr/local/glibc/{lib,usr/lib,include}.

When I did it, I rebuilt everything on my system twice, just to be safe. 
  First time through, you build against the extra copy of glibc, 
including building a downgraded glibc in the proper system location, and 
having the build tools link to the correct lower version.  Then you 
remove the CFLAGS/LDFLAGS and rebuild everything again, this time 
against the downgraded version in the correct location, and then you can 
remove your extra copy.  I'm not entire positive that second one was 
strictly necessary but it worked.

Or you can just back up your data and reinstall :)

> A multitude of apps that used to run just fine now give "free(): invalid
> pointer" errors since I upgraded to glibc-2.11

Make sure you file bug reports on these.  The programs are probably 
doing buggy things that glibc used to be rather forgiving about.  I 
believe in 2.11 they added extra checks to the memory management used by 
C++ programs, though I don't know specifics.  This would catch things 
like using delete where they meant delete[], or free() on something 
allocated with new.

The standard says the behavior of this type of operation is undefined, 
so glibc is technically free to do "anything it wants".  Unfortunately, 
when glibc is nice and make that "anything" be "what you wanted it to do 
anyway" it encourages people do keep doing bad things, thus the 
ever-increasing strictness of the library.

--Mike



  parent reply	other threads:[~2009-11-17 19:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-17 16:06 [gentoo-user] Downgrade glibc-2.11 to 2.10 Alan McKinnon
2009-11-17 16:57 ` daid kahl
2009-11-17 18:45   ` Alan McKinnon
2009-11-17 19:25     ` daid kahl
2009-11-17 23:09     ` [gentoo-user] " walt
2009-11-18  7:23       ` Alan McKinnon
2009-11-18  8:38         ` daid kahl
2009-11-18 10:01         ` Volker Armin Hemmann
2009-11-17 18:45 ` [gentoo-user] " Nagatoro
2009-11-17 19:35 ` Mike Edenfield [this message]
2009-11-17 20:02 ` Volker Armin Hemmann
2009-11-19 14:52 ` [gentoo-user] " Thorsten Kampe
2009-11-19 15:03   ` Alan McKinnon
2009-11-19 15:27     ` Volker Armin Hemmann
2009-11-19 15:32       ` Alan McKinnon
2009-11-19 15:37         ` Volker Armin Hemmann
2009-11-19 15:40           ` Alan McKinnon
2009-11-19 15:45             ` Volker Armin Hemmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B02FB14.1040808@kutulu.org \
    --to=kutulu@kutulu.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox