| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 06/15/2014 04:47 AM, Dale wrote: |
| 5 |
> John Campbell wrote: |
| 6 |
>> On 06/14/2014 10:10 PM, Dale wrote: |
| 7 |
>> |
| 8 |
>>> Well, I have 16Gbs here. I'm not lacking for memory. If |
| 9 |
>>> memory prices were to drop a bit, I could upgrade some more. |
| 10 |
>>> I'd have to swap out what I have tho. Old mobo would only take |
| 11 |
>>> 4GB sticks and this new one will take 8GB sticks. |
| 12 |
>> |
| 13 |
>> Unless you have a specific reason for keeping both x32 and 64 |
| 14 |
>> ABIs I'd suggest changing to ABI_X86="32 64" globally in |
| 15 |
>> /etc/make.conf (or /etc/portage/make.conf). It's a lot easier |
| 16 |
>> than waiting for the next conflict. Then do "emerge --new-use |
| 17 |
>> --deep @world" and you're done. There shouldn't bee too many |
| 18 |
>> packages that need rebuilding. |
| 19 |
>> |
| 20 |
>> |
| 21 |
> |
| 22 |
> I put that in make.conf and get this: |
| 23 |
> |
| 24 |
> # required by sys-fs/eudev-1.7[gudev] # required by @selected # |
| 25 |
> required by @world (argument) =dev-libs/glib-2.40.0 ~amd64 |
| 26 |
> |
| 27 |
> Does it make sense to keyword that? Isn't that the package that |
| 28 |
> once upgraded you can't go backward? I'm just double checking that |
| 29 |
> this all makes sense. < scratches head > |
| 30 |
> |
| 31 |
> Dale |
| 32 |
> |
| 33 |
> :-) :-) |
| 34 |
> |
| 35 |
|
| 36 |
The package you are thinking of that is a one-way upgrade is glibc, |
| 37 |
not glib. Glibc is the C Runtime Environment, absolutely everything |
| 38 |
written in C and C++ ends up linking against it (and things that |
| 39 |
aren't tend either to be compiled using something that is or |
| 40 |
interpreted by something that is). If glibc is downgraded, anything |
| 41 |
that uses something from a newer version (or something that *changed* |
| 42 |
in a newer version, due to how symbol versions work) will fail to run |
| 43 |
against the older version. |
| 44 |
|
| 45 |
For example, any program linked against glibc 2.14 or greater that |
| 46 |
uses memcpy ends up linking against the symbol "memcpy@@GLIBC_2.14", |
| 47 |
which is only in newer versions of glibc. Programs linked against |
| 48 |
older versions of glibc use "memcpy@GLIBC_2.2.5", which differs in |
| 49 |
some way (specifically in this case, the old memcpy always went in a |
| 50 |
particular direction, the new memcpy may be faster on some CPUs, but |
| 51 |
this broke old Adobe Flash). |
| 52 |
-----BEGIN PGP SIGNATURE----- |
| 53 |
Version: GnuPG v2 |
| 54 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 55 |
|
| 56 |
iQIcBAEBCgAGBQJTnqAdAAoJELHSF2kinlg4RwIQAIBA/fnW7hq6GUK3fQimcEIo |
| 57 |
RdeXK3RXy750T6XP5vo71NFhrJJmaROaNzSksKXfAtfJZt3PnpbIxFxtvKep7Xp3 |
| 58 |
bJnAOXHej+EndkSDXEoZTAepzEmqIj8V+Y4blSmRE25w+NLTe2Wgkjd92Y6ugroW |
| 59 |
Hk1A/nrGRNO5pBepSvIUOIn5GIoTMMH4485HBnwUdtt6+EQja50cfSMbTUoXqF38 |
| 60 |
GgkJkik28TOYSivn6b6VdzCvl+X8ZqFY0M+BhWSLLaN+7/BR1S5dI1Th1QNDaHSX |
| 61 |
KcCbtSIwqB1V5w5jSLb4JtU+Noi5nqXyy4ZnwR0wCN/MkhBFFQlRYE/sgOeYrOgw |
| 62 |
mxCj7442q0Ml1nv+4ASHdOsQ/M8VCoBR3TZhCYDU5wZB6Wb4AVY/tSxopDL54aqi |
| 63 |
4iutCTBn9fh7NIfasVjhvSdNMdglF/SHnHfiS9C94odFGvbZjHJd7ICwshSh9eNG |
| 64 |
/jwRRSrmdMK9IiqK9IkTYDXlCYkre2CtIt8urlypoWaQwD5IrkEIeE9PvXEUcDNU |
| 65 |
jw8S+3hhNkQ5/3MKErBwGOshdhoogTM03afbSg/M3DRn+B3GAo8Zi9i26wUPTMJo |
| 66 |
Y6Nm3xhPd5K5h9hmh4bTkG+eqIshtTpqC9cdzQ/xf1dA2X1yxvBdXt6B3cGQg/+1 |
| 67 |
kUyTwlCW3O11b9l0LzeH |
| 68 |
=C+Xr |
| 69 |
-----END PGP SIGNATURE----- |
Archives