public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Jonathan Callen <jcallen@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Dependency conflict.  openjpeg  ffmpeg
Date: Mon, 16 Jun 2014 03:43:25 -0400	[thread overview]
Message-ID: <539EA01D.8030205@gentoo.org> (raw)
In-Reply-To: <539D5D8E.6080805@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/15/2014 04:47 AM, Dale wrote:
> John Campbell wrote:
>> On 06/14/2014 10:10 PM, Dale wrote:
>> 
>>> Well, I have 16Gbs here.  I'm not lacking for memory.  If
>>> memory prices were to drop a bit, I could upgrade some more.
>>> I'd have to swap out what I have tho.  Old mobo would only take
>>> 4GB sticks and this new one will take 8GB sticks.
>> 
>> Unless you have a specific reason for keeping both x32 and 64
>> ABIs I'd suggest changing to ABI_X86="32 64" globally in
>> /etc/make.conf (or /etc/portage/make.conf).  It's a lot easier
>> than waiting for the next conflict.  Then do "emerge --new-use
>> --deep @world" and you're done. There shouldn't bee too many
>> packages that need rebuilding.
>> 
>> 
> 
> I put that in make.conf and get this:
> 
> # required by sys-fs/eudev-1.7[gudev] # required by @selected #
> required by @world (argument) =dev-libs/glib-2.40.0 ~amd64
> 
> Does it make sense to keyword that?  Isn't that the package that
> once upgraded you can't go backward?  I'm just double checking that
> this all makes sense.  < scratches head >
> 
> Dale
> 
> :-)  :-)
> 

The package you are thinking of that is a one-way upgrade is glibc,
not glib.  Glibc is the C Runtime Environment, absolutely everything
written in C and C++ ends up linking against it (and things that
aren't tend either to be compiled using something that is or
interpreted by something that is).  If glibc is downgraded, anything
that uses something from a newer version (or something that *changed*
in a newer version, due to how symbol versions work) will fail to run
against the older version.

For example, any program linked against glibc 2.14 or greater that
uses memcpy ends up linking against the symbol "memcpy@@GLIBC_2.14",
which is only in newer versions of glibc.  Programs linked against
older versions of glibc use "memcpy@GLIBC_2.2.5", which differs in
some way (specifically in this case, the old memcpy always went in a
particular direction, the new memcpy may be faster on some CPUs, but
this broke old Adobe Flash).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTnqAdAAoJELHSF2kinlg4RwIQAIBA/fnW7hq6GUK3fQimcEIo
RdeXK3RXy750T6XP5vo71NFhrJJmaROaNzSksKXfAtfJZt3PnpbIxFxtvKep7Xp3
bJnAOXHej+EndkSDXEoZTAepzEmqIj8V+Y4blSmRE25w+NLTe2Wgkjd92Y6ugroW
Hk1A/nrGRNO5pBepSvIUOIn5GIoTMMH4485HBnwUdtt6+EQja50cfSMbTUoXqF38
GgkJkik28TOYSivn6b6VdzCvl+X8ZqFY0M+BhWSLLaN+7/BR1S5dI1Th1QNDaHSX
KcCbtSIwqB1V5w5jSLb4JtU+Noi5nqXyy4ZnwR0wCN/MkhBFFQlRYE/sgOeYrOgw
mxCj7442q0Ml1nv+4ASHdOsQ/M8VCoBR3TZhCYDU5wZB6Wb4AVY/tSxopDL54aqi
4iutCTBn9fh7NIfasVjhvSdNMdglF/SHnHfiS9C94odFGvbZjHJd7ICwshSh9eNG
/jwRRSrmdMK9IiqK9IkTYDXlCYkre2CtIt8urlypoWaQwD5IrkEIeE9PvXEUcDNU
jw8S+3hhNkQ5/3MKErBwGOshdhoogTM03afbSg/M3DRn+B3GAo8Zi9i26wUPTMJo
Y6Nm3xhPd5K5h9hmh4bTkG+eqIshtTpqC9cdzQ/xf1dA2X1yxvBdXt6B3cGQg/+1
kUyTwlCW3O11b9l0LzeH
=C+Xr
-----END PGP SIGNATURE-----


  reply	other threads:[~2014-06-16  7:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-14 21:23 [gentoo-user] Dependency conflict. openjpeg ffmpeg Dale
2014-06-14 23:00 ` Alan McKinnon
2014-06-15  0:12   ` Dale
     [not found]   ` <EQDB1o00e1kktTk01QDC7q>
2014-06-15  1:20     ` John Campbell
2014-06-15  2:10       ` Dale
     [not found]       ` <ESAJ1o00S1kktTk01SAKbb>
2014-06-15  2:31         ` John Campbell
2014-06-15  5:10           ` Dale
2014-06-15  8:46             ` Neil Bothwick
2014-06-15  8:59               ` Dale
2014-06-15  9:09                 ` Neil Bothwick
2014-06-15 10:29                   ` Dale
     [not found]           ` <EVAt1o00G1kktTk01VAu3p>
2014-06-15  6:13             ` John Campbell
2014-06-15  6:40               ` wraeth
2014-06-15  6:56                 ` wraeth
2014-06-15  8:47               ` Dale
2014-06-16  7:43                 ` Jonathan Callen [this message]
2014-06-17 23:43       ` Dale
2014-06-19 22:03         ` Dale
2014-06-17 15:56 ` thegeezer
2014-06-17 21:10   ` Dale

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=539EA01D.8030205@gentoo.org \
    --to=jcallen@gentoo.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