Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 499952 - app-emulation/emul-linux-x86-baselibs: provide libpng16 as the primary provider since app-emulation/wine needs matching 32bit and 64bit libraries to work
Summary: app-emulation/emul-linux-x86-baselibs: provide libpng16 as the primary provid...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
: 500012 500052 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-01 08:56 UTC by Richard H.
Modified: 2014-05-15 10:00 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Configs for Comment 27 (f99config.tar.bz2,93.76 KB, application/x-bzip)
2014-03-25 12:30 UTC, Frank Krömmelbein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard H. 2014-02-01 08:56:57 UTC
Recently, libpng was bumped to 1.6.8 which horribly breaks wine because it's using 1.5.12 from app-emulation/emul-linux-x86-baselibs. I traced all my steps and it does crash anymore when I install self compiled libraries of libpng-1.6.8 into /usr/lib32 (compiling by setting USE="abi_x86_32" and telling the ebuild to merge with the system). So it seems the best fix for this problem is to include libpng16.so and update the libpng.so symlink. That would fix this problem.

Reproducible: Always

Steps to Reproduce:
1. emerge libpng-1.6.8
2. emerge wine
3. run some Windows programs
Actual Results:  
Wine crashes horribly with exceptions

Expected Results:  
The software should simply run!

I googled everywhere and stumbled upon this message about compiled with 1.6.8 but running with 1.5.12 and mostly it is said it's harmless. It is NOT!
Comment 1 Samuli Suominen gentoo-dev 2014-02-01 09:02:58 UTC
No new files get added to emul-linux-x86- packages as the whole point is to migrate away from them.
That's why media-libs/libpng has ABI_X86="32" possibility, so user can get 32bit libpng16.so*

$ qlist libpng-1.6.8|grep lib32
/usr/lib32/pkgconfig/libpng16.pc
/usr/lib32/pkgconfig/libpng.pc
/usr/lib32/libpng.so
/usr/lib32/libpng16.so.16.8.0
/usr/lib32/libpng16.so
/usr/lib32/libpng16.so.16

So everything looks to be in order here as-is.
Comment 2 Samuli Suominen gentoo-dev 2014-02-01 09:16:26 UTC
And yes, it's a known fact wine needs matching 32bit and 64bit libraries. So if you have libpng15 normally, you'd make sure to also have libpng15 in 32bit, if you have jpeg-9a, you'd make sure to also have jpeg-9a in 32bit, and so forth

And you might indeed need to use emul-linux-x86-baselibs from ~arch for that for now, as in, to allow ABI_X86="32" libpng16 to be installed without blockers. This will autoresolve once the new emul-linux-x86- packages go stable in the future
Comment 3 Frank Krömmelbein 2014-02-01 11:00:44 UTC
@Samuli Suominen

I can understand your point to not stop that migration process.
But after the stablelization of libpng the stable version of wine was after the rebuild "broken".
It costs me >2 days just to find out what was the reason, including a complete a new stage3 installation....

Is there a complete howto to get this ABI_X86="32" for libpng working?
Shure on the forums and google finds some pices, some or outdated, etc... 

I masked libpng >1.6 for now.
Comment 4 Richard H. 2014-02-01 16:16:40 UTC
Okay, that is good enough for me (with the newer releases of emul-linux-x86-baselibs). Wouldn't it be easier then to *remove* libpng from the package then and use ABI_X86? I really am fond of this new way - and can't wait to migrate my system as it will surely be smoother.
Comment 5 Samuli Suominen gentoo-dev 2014-02-02 09:25:56 UTC
So app-emulation/wine is known to be broken and I'll reopen this bug for that and let the amd64/multilib people decide what to do...

a) Create special revision bump for current stable emul-linux-x86- with libpng16 as primary, that provides the headers, pkg-config files, and the .so symlink(s)

b) Create special revision bump for current stable emul-linux-x86 with sys-libs/zlib and media-libs/libpng having ABI_X86="32" unmasked

c) Stabilize current ~arch stuff?

d) Do nothing and decide app-emulation/wine is not a showstopper and wait for this to autoresolve

e) ???
Comment 6 Samuli Suominen gentoo-dev 2014-02-02 09:26:21 UTC
*** Bug 500052 has been marked as a duplicate of this bug. ***
Comment 7 Samuli Suominen gentoo-dev 2014-02-02 09:47:06 UTC
*** Bug 500012 has been marked as a duplicate of this bug. ***
Comment 8 Pacho Ramos gentoo-dev 2014-02-02 09:48:31 UTC
Well, I am unsure if I will have time until next weekend to update the "old" emul set :(
Comment 9 Trevor Bowen 2014-02-07 06:48:37 UTC
Is there a workaround for mostly-stable users in the short-term? ... Thanks!
Comment 10 Delete ME 2014-02-12 12:42:38 UTC
Possible workaround found after hours of search. In short create your local wine ebuild (in your local overlay) and change the build time Slots for libpng to force the use of libpng 1.5 instead of libpng 1.6

...
mkdir -p /usr/local/portage/app-emulation/wine
cd /usr/local/portage/app-emulation/wine
cp -r /usr/portage/app-emulation/wine/* .
cp wine-1.7.12.ebuild wine-1.7.12.ebuild.orig
vi wine-1.7.12.ebuild (and change "media-libs/libpng:0=" to "media-libs/libpng:1.5=" as shown next)
diff /usr/local/portage/app-emulation/wine/wine-1.7.12.ebuild /usr/local/portage/app-emulation/wine/wine-1.7.12.ebuild.orig 
90c90
< 	png? ( media-libs/libpng:1.5= )
---
> 	png? ( media-libs/libpng:0= )
185c185
< 				media-libs/libpng:1.5[abi_x86_32]
---
> 				media-libs/libpng:0[abi_x86_32]
ebuild wine-1.7.12.ebuild manifest
...

This should work with other wine versions too.

According to the build process libpng 1.5 is used but i didn't do a real test yet.

steven@box ~ $ grep -i png /var/tmp/portage/app-emulation/wine-1.7.12/temp/build-x86.log 
/var/tmp/portage/app-emulation/wine-1.7.12/work/wine-1.7.12/configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 --docdir=/usr/share/doc/wine-1.7.12 --sysconfdir=/etc/wine --with-alsa --without-capi --without-cms --without-cups --with-curses --with-dbus --with-fontconfig --with-gnutls --with-gphoto --with-gsm --without-gstreamer --without-hal --with-jpeg --without-ldap --with-mpg123 --without-netapi --with-gettext --without-openal --without-opencl --with-opengl --without-osmesa --without-oss --with-png --with-pthread --without-sane --disable-tests --with-freetype --without-v4l --with-x --without-xcomposite --without-xinerama --with-xml --with-xslt --without-netapi --disable-win64
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
checking for -lpng... libpng15.so.15
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
x86_64-pc-linux-gnu-gcc -m32 -c -o pngformat.o /var/tmp/portage/app-emulation/wine-1.7.12/work/wine-1.7.12/dlls/windowscodecs/pngformat.c \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \
  -I/usr/include/libpng15 -D__WINESRC__
  -I/usr/include/libpng15 -D__WINESRC__
  -I/usr/include/libpng15 -D__WINESRC__
  -I/usr/include/libpng15 -D__WINESRC__
  -I/var/tmp/portage/app-emulation/wine-1.7.12/work/wine-1.7.12/include -I/usr/include/libpng15 \
  -I/var/tmp/portage/app-emulation/wine-1.7.12/work/wine-1.7.12/include -I/usr/include/libpng15 \
Comment 11 Frank Krömmelbein 2014-02-12 18:11:49 UTC
(In reply to Steven from comment #10)

I have just tested your workaround, but it did not work for me:

diff  ./wine-1.7.12.ebuild /usr/local/portage/app-emulation/wine/wine-1.7.12-r1.ebuild -ruN
--- ./wine-1.7.12.ebuild        2014-02-08 22:50:51.000000000 +0100
+++ /usr/local/portage/app-emulation/wine/wine-1.7.12-r1.ebuild 2014-02-12 18:06:54.013556920 +0100
@@ -87,7 +87,7 @@
        xml? ( dev-libs/libxml2 dev-libs/libxslt )
        scanner? ( media-gfx/sane-backends:= )
        ssl? ( net-libs/gnutls:= )
-       png? ( media-libs/libpng:0= )
+       png? ( media-libs/libpng:1.5= )
        v4l? ( media-libs/libv4l )
        xcomposite? ( x11-libs/libXcomposite )"
 
@@ -182,7 +182,7 @@
                        ssl? ( app-emulation/emul-linux-x86-baselibs[development] )
                        png? ( || (
                                app-emulation/emul-linux-x86-baselibs[development]
-                               media-libs/libpng:0[abi_x86_32]
+                               media-libs/libpng:1.5[abi_x86_32]
                        ) )
                        v4l? ( || (
                                app-emulation/emul-linux-x86-medialibs[development]


Slot 1.5 libpng was now installed when emerging wine. Ok
But wine was still build with libpng 1.6 which lead to the known exception.
Even removing libpng-1.6.8 first, lead to a png.h not found error message when compiling wine.

eix -Inc libpng
[I] media-libs/libpng (1.2.50-r1(1.2){tbz2}@12.01.2014 1.5.17-r15(1.5){tbz2}@12.02.2014 1.6.8{tbz2}@12.02.2014): Portable Network Graphics library

[ebuild   R   ~] app-emulation/wine-1.7.12-r1::lokal  USE="X alsa cups fontconfig gecko gphoto2 jpeg lcms ldap mono mp3 ncurses nls opencl opengl perl png prelink realtime run-exes samba scanner ssl threads truetype udisks v4l xcomposite xinerama xml -capi -custom-cflags -dos -gsm -gstreamer -netapi -odbc -openal -osmesa -oss -pulseaudio (-selinux) {-test}" ABI_X86="32 64 (-x32)" LINGUAS="de en -ar -bg -ca -cs -da -el -en_US -eo -es -fa -fi -fr -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -nl -or -pa -pl -pt_BR -pt_PT -rm -ro -ru -sk -sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th -tr -uk -wa -zh_CN -zh_TW" 0 kB

Any idea?
Comment 12 Delete ME 2014-02-12 18:45:26 UTC
Unfortunatly i can also confirm the workaround doesn't work. I still get the version mismatch error message.

An easy test for me is:

export WINEARCH=win32
WINEPREFIX=$HOME/.TEST winecfg
WINEPREFIX=$HOME/.TEST wineboot
libpng warning: Application built with libpng-1.6.8 but running with 1.5.15
err:menubuilder:convert_to_native_icon error 0x80004005 initializing encoder
...
Comment 13 Richard H. 2014-02-12 18:47:37 UTC
That workaround does not work as long as libpng16 is installed because configure of wine finds it and uses ist. Not much to do with the ebuild unfortunately.
Comment 14 Richard H. 2014-02-16 10:23:36 UTC
Just for everyone else who stumbles upon this. That's what I basically did:

# unmask abi_x86_32
echo "media-libs/libpng -abi_x86_32" >> /etc/portage/profile/package.use.mask

# but don't use it per default (or else you won't be able to emerge anything)
echo "media-libs/libpng -abi_x86_32" >> /etc/portage/package.use

# use ebuild merge so we don't get dependency hell
USE="abi_x86_32" ebuild $(equery w libpng) merge


I hope this gets resolved soonish. After this method you either

* DON'T use -N in emerge

or

* you repeat the last step after each world-update.


This works for me like a charm.
Comment 15 David Gasaway 2014-03-06 04:09:03 UTC
(In reply to Richard H. from comment #14)

> # use ebuild merge so we don't get dependency hell
> USE="abi_x86_32" ebuild $(equery w libpng) merge

When I try this, it fails to merge due to file collisions with emul-linux-x86-baselibs.  If I remove emul-linux-x86-baselibs and try a "ebuild merge" of wine, it fails looking for one of the other baselibs.  What am I missing?
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-03-06 08:12:30 UTC
Oh my...

@Richard: please abstain from giving bad advices.

@David: we can't really support mixing emul-linux with multilib packages. You could try hacking it around but you're going to break something earlier or later :).

I think you could try installing emul-linux back with FEATURES=-protect-owned. But it's a pretty easy way to screw up your system in the future.

The official solution so far would be to enable USE=abi_x86_32 everywhere and take the ride. It's not perfect but good enough to get wine working properly.
Comment 17 Richard H. 2014-03-06 11:36:33 UTC
(In reply to Michał Górny from comment #16)
> Oh my...
> 
> @Richard: please abstain from giving bad advices.
> 
> @David: we can't really support mixing emul-linux with multilib packages.
> You could try hacking it around but you're going to break something earlier
> or later :).
> 
> I think you could try installing emul-linux back with
> FEATURES=-protect-owned. But it's a pretty easy way to screw up your system
> in the future.
> 
> The official solution so far would be to enable USE=abi_x86_32 everywhere
> and take the ride. It's not perfect but good enough to get wine working
> properly.

Tried a lot of this. Didn't help, because not everything accepts emul-linux-baselibs missing.

I would be happy if the baselibs brought libpng16 with them, I don't need any more than that ;)
Comment 18 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-06 13:16:21 UTC
(In reply to Richard H. from comment #17)
> Tried a lot of this. Didn't help, because not everything accepts
> emul-linux-baselibs missing.

Simply emerge emul-linux-baselibs with USE=abi_x86_32, and it will install only those libraries which don't collide with native multilib ebuilds :)

If you are using ~amd64 ACCEPT_KEYWORDS, simply set ABI_X86="32 64" in make.conf and emerge wine - everything will work.
Comment 19 Frank Krömmelbein 2014-03-06 14:43:20 UTC
I have made now a decision after spending again more then 3 hours to migrate to that new funny abi_x86_32 stuff.
After adding more then 70 entrys to the different package.mask/unmask/accept_keywords files and changed also some useflags for llvm etc., and still had 2 unresolveable Blocks left.
I gave up now and did the only right thing for me: 

emerge -C wine

Ok the situation is getting better now, compared to the situation a few weeks ago with about ~120 entrys. But then i did not had any unresolveable blocker left...

If "equery d" is correct the only application left on my machines, which requires that app-emulation/emul-linux-x86-* packages, is the steam client.

So the next thing that i will now do, is to remove the steam-client and then later all app-emulation/emul-linux-x86-*

I will now use a Virtual Maschine with Windows for the last required Windows apps.
For the games, i will later restore my Dual Boot Windows partition...


Thanks anyway.
Comment 20 David Gasaway 2014-03-06 16:20:49 UTC
(In reply to Michał Górny from comment #16)

> The official solution so far would be to enable USE=abi_x86_32 everywhere
> and take the ride. It's not perfect but good enough to get wine working
> properly.

Please give specific steps, because I've tried to set ABI_X86="32" in make.conf already.  That didn't go well, which is why I was trying Richard's workaround.
Comment 21 Julian Ospald 2014-03-06 16:29:04 UTC
(In reply to Samuli Suominen from comment #1)
> No new files get added to emul-linux-x86- packages as the whole point is to
> migrate away from them.
> That's why media-libs/libpng has ABI_X86="32" possibility, so user can get
> 32bit libpng16.so*
> 
> $ qlist libpng-1.6.8|grep lib32
> /usr/lib32/pkgconfig/libpng16.pc
> /usr/lib32/pkgconfig/libpng.pc
> /usr/lib32/libpng.so
> /usr/lib32/libpng16.so.16.8.0
> /usr/lib32/libpng16.so
> /usr/lib32/libpng16.so.16
> 
> So everything looks to be in order here as-is.

That looks like a horrible policy if it's able to break stable consumers.

Besides that, it already confuses revdep-rebuild a lot.
Comment 22 Frank Krömmelbein 2014-03-06 16:36:53 UTC
(In reply to David Gasaway from comment #20)
> (In reply to Michał Górny from comment #16)
> 
> > The official solution so far would be to enable USE=abi_x86_32 everywhere
> > and take the ride. It's not perfect but good enough to get wine working
> > properly.
> 
> Please give specific steps, because I've tried to set ABI_X86="32" in
> make.conf already.  That didn't go well, which is why I was trying Richard's
> workaround.

Have a look here:
http://forums.gentoo.org/viewtopic-p-7509542.html#7509542

Before you begin with that, make a backup first!

Good luck!
Comment 23 Julian Ospald 2014-03-06 16:37:16 UTC
(In reply to Frank Krömmelbein from comment #19)


The whole point of multilib was to improve user experience, but so far it caused the exact opposite, at least for the time of migration, which is still not over.

A few things to note to make your life easier:
* _never_ use an overlay which adds it's own multilib versions of system libraries (that includes gamerlay, steam-overlay, FireBurn...)
* do NOT unmask single versions of multilib-libraries while not unmasking others... unless you are really good at finding dependency problems (which I do and I regret it a lot)
* switch to full ~arch and enable ABI_X86="32 64" ...which sucks hard enough and reverting back to stable arch will not be trivial, but possible
Comment 24 David Gasaway 2014-03-06 16:58:14 UTC
(In reply to Frank Krömmelbein from comment #22)

> Have a look here:
> http://forums.gentoo.org/viewtopic-p-7509542.html#7509542
> 
> Before you begin with that, make a backup first!
> 
> Good luck!

Well, I can't even get past step one: "Main gotcha: If you need any of these flags enabled, then you may be out of luck."
Comment 25 Oleh 2014-03-20 19:06:49 UTC
any updates on this?
maybe it's better to roll out newer emul-linux-* versions?
Comment 26 Gino McCarty 2014-03-24 23:15:32 UTC
(In reply to Oleg from comment #25)
> any updates on this?
> maybe it's better to roll out newer emul-linux-* versions?

looks like the multilib team is dead set on not working on any new emul releases, despite the fact that multilib is not ready, and there are tons of bugs with the current packages...
Comment 27 Frank Krömmelbein 2014-03-25 12:30:55 UTC
Created attachment 373494 [details]
Configs for Comment 27
Comment 28 Frank Krömmelbein 2014-03-25 12:31:30 UTC
At the end i have now made ​​it... 
Puuuh.

My Starting Point:
~1.400 packages installed, ~400 from unstable mostly kde and some media apps 
no wine installed, and also all(!) dependencies from wine removed

I have attached to this bug my complete list of installed packages, needed config files and patches. It may be useful for somebody.

1) I followed Julians advice, and removed all overlays and all packages from these overlays
2) with a little luck a few more deps are now stabilized so -> "emerge --sync"  OR  "eix-sync"
3) Fixed all updates, Useflag changes, problems etc which: "emerge -pv --update --newuse --deep world --with-bdeps=y" showed 
4) I had already failed with the conversion, but I remembered that many Xorg packages had received an update and started then with this:
   Bug 500368 - Xorg stabilization list for March 
   I took the attached list and copied the entrys for AMD64 to my package.accept_keywords 
   sys-devel/llvm needed some useflag changes, i followed the advice of portage, although I do not consider it advisable to add "video_cards_radeon"
5) Only real problem then was with x11-drivers/xf86-video-vmware-13.0.1 which failed https://bugs.gentoo.org/show_bug.cgi?id=504252
   The needed 2 patches are attached here.
6) ~35 Updates and the reinstall of the xorg drivers later, i started with the "fun" part and added ABI_X86="64 32" to make.conf
    and added "-abi_x86_32" to /etc/portage/profile/use.mask
7) Then checked from various sources already posted entries for package.accept_keywords and if neccesary added them
8) For the other entrys "emerge -pv --update --newuse --deep world --with-bdeps=y" countless times, until no(!) hard blocker is left
   portage requires a very long for every attempt
9) Which now resulted to 180 packages to get updated, Useflag changed etc.
10) Only 1 or 2 package failed if i remember correct, i removed the specific version numer from the entry in package.accept_keywords, which worked for me
11) emerge -pv @preserved-rebuild showed then ~20 packages needs to rebuild, only the both installed stable python versions failed.
    I had a little exercise now so yes I still added dev-lang/python also. I think it was a wrong dep. problem with readline-6.3-r2
12) "revdep-rebuild -p" showed also no errors so Finaly:
13) emerge wine, but with my global useflags enabled it pulls in ~25 new dependencies to handle, so i disabled only "scanner" and "gphoto2" for wine
14) wine works now again

Note:
Do not remove the emul-linux-x86-* paackges. This costs me much time to learn!
Use the latest unstable emul-linux-x86-* packages but NOT the hard masked ones.
Comment 29 Matthew Ogilvie 2014-03-28 22:26:03 UTC
I would suggest that the question of removing your machine's "emul-linux-x86-*" packages depends on whether you need anything that still unconditionally depends on them.  If you still need such a package (or package use flag), then Frank Krömmelbein's procedure above is probably your best option, although I suspect it will need some baby sitting as things continue to change.

But if you don't actually need emul-linux-x86-*, then my procedure will allow you to stay much closer to stable:
http://forums.gentoo.org/viewtopic-p-7509542.html#7509542
Step 1 gives some hints about tracking down emul-linux-x86 dependencies.

Note that I intend to continue editing that post to keep it reasonably up to date as things continue to change in the portage tree.  But I wonder if anyone might find it useful to occasionally add a new post to the thread, since simply editting the main post doesn't update the thread's date.
Comment 30 Oleh 2014-04-11 04:05:34 UTC
how emul-linux-* packages created? It's time to roll out update locally, because Gentoo lazy...
Comment 31 Matthew Ogilvie 2014-04-11 16:50:28 UTC
Apparently there is now a updated set of emul-linux packages (20140406), but they are still hard-masked and may have other difficulties.  See https://bugs.gentoo.org/show_bug.cgi?id=506900 and https://bugs.gentoo.org/show_bug.cgi?id=507416 .
Comment 32 Pacho Ramos gentoo-dev 2014-05-15 07:19:20 UTC
it is providing 1.6.x for some time
Comment 33 Richard H. 2014-05-15 10:00:51 UTC
app-emulation/emul-linux-x86-baselibs-20140406-r1 (/usr/lib32/libpng16.so.16.8.0)
app-emulation/emul-linux-x86-baselibs-20140406-r1 (/usr/lib32/libpng16.so -> libpng16.so.16.8.0)
app-emulation/emul-linux-x86-baselibs-20140406-r1 (/usr/lib32/libpng16.so.16 -> libpng16.so.16.8.0)


...and it works like a charm in Wine. Thanks a lot!