1 |
On 11/17/2009 11:06 AM, Alan McKinnon wrote: |
2 |
> Yes, I have read this in |
3 |
> /var/portage/sys-libs/glibc/files/eblits/pkg_setup.eblit |
4 |
> and I understand the risks. |
5 |
> |
6 |
> if has_version '>'${CATEGORY}/${PF} ; then |
7 |
> eerror "Sanity check to keep you from breaking your system:" |
8 |
> eerror " Downgrading glibc is not supported and a sure way to destruction" |
9 |
> die "aborting to save your system" |
10 |
> fi |
11 |
> |
12 |
> I want to do it anyway. |
13 |
|
14 |
I have never done this on a package-managed system but I did have to |
15 |
downgrade glibc on a slackware system once. It's very VERY ugly; all |
16 |
kinds of implementation details get exposed as special symbols, or new |
17 |
symbol versions, or whatever, that make going backwards a mess. |
18 |
|
19 |
The way I was told to do it was to get a compiled copy of lower glibc |
20 |
version into an alternative install path, like /usr/local/glibc, and |
21 |
rebuild everything against that copy. You could have emerge build 2.10 |
22 |
into an alternative --root, or go get a binary package of 2.10 and |
23 |
uncompress it somewhere. Then update CFLAGS and LDFLAGS to include the |
24 |
correct -L and -I parameters pointing to |
25 |
/usr/local/glibc/{lib,usr/lib,include}. |
26 |
|
27 |
When I did it, I rebuilt everything on my system twice, just to be safe. |
28 |
First time through, you build against the extra copy of glibc, |
29 |
including building a downgraded glibc in the proper system location, and |
30 |
having the build tools link to the correct lower version. Then you |
31 |
remove the CFLAGS/LDFLAGS and rebuild everything again, this time |
32 |
against the downgraded version in the correct location, and then you can |
33 |
remove your extra copy. I'm not entire positive that second one was |
34 |
strictly necessary but it worked. |
35 |
|
36 |
Or you can just back up your data and reinstall :) |
37 |
|
38 |
> A multitude of apps that used to run just fine now give "free(): invalid |
39 |
> pointer" errors since I upgraded to glibc-2.11 |
40 |
|
41 |
Make sure you file bug reports on these. The programs are probably |
42 |
doing buggy things that glibc used to be rather forgiving about. I |
43 |
believe in 2.11 they added extra checks to the memory management used by |
44 |
C++ programs, though I don't know specifics. This would catch things |
45 |
like using delete where they meant delete[], or free() on something |
46 |
allocated with new. |
47 |
|
48 |
The standard says the behavior of this type of operation is undefined, |
49 |
so glibc is technically free to do "anything it wants". Unfortunately, |
50 |
when glibc is nice and make that "anything" be "what you wanted it to do |
51 |
anyway" it encourages people do keep doing bad things, thus the |
52 |
ever-increasing strictness of the library. |
53 |
|
54 |
--Mike |