Bugzilla Bug 283089

I updated my system to use jpeg 7, and everything compiled fine when I
revdep-rebuild for the old jpeg libs.

However, when I try to run Wine, it will not run due to Wine looking for
libjpeg-7 (installed as 64-bit) but only finds libjpeg-6b (installed by
emul-linux-baselibs).

There is no updated emul-linux-baselibs to match the new version of libjpeg. 
Only solution so far is to mask jpeg-7 and rebuild all the packages that depend
on libjpeg.

Reproducible: Always

Steps to Reproduce:
1.upgrade to jpeg-7
2.rebuild wine
3.run any wine application

Actual Results:  
Wine does not start with message "Wrong JPEG library version: library is 62,
caller expects 70"

Expected Results:  
Wine to run

bluex@station ~/.wine/drive_c/gms/WoW $ ls /usr/lib/libjpeg*
/usr/lib/libjpeg.a  /usr/lib/libjpeg.la  /usr/lib/libjpeg.so 
/usr/lib/libjpeg.so.7  /usr/lib/libjpeg.so.7.0.0
bluex@station ~/.wine/drive_c/gms/WoW $ wine Launcher.exe
Wrong JPEG library version: library is 62, caller expects 70

the output goes something like that, i believe... I can still launch WoW trough
Wow.exe, though the launcer (that appears in the menus) can't be used.

So emul-linux-x86-baselibs will need both, >=media-libs/jpeg-7 (libjpeg.so.7)
and media-libs/jpeg-compat (libjpeg.so.62).

Until the emul package gets fixed, is there a possible workaround? Some of my
applications in Wine cannot run because of this issue.

I read somewhere that you can build jpeg from overlay multilib with use-flag
lib32 to get 32-bit version of libs. I had also to delete 32-bit jpeg 6 libs
and managed to run some wine programs.

+  30 Sep 2009; Samuli Suominen <ssuominen@gentoo.org> package.use.mask:
+  Mask app-emulation/wine[jpeg] wrt #283089.

btw, why is(was) the jpeg useflag available, if just not using the jpeg flag
fixes the issue? (i'm still rebuilding wine along with jpeg7, so i haven't had
a chance to check). Is this a quick'n'dirty fix or don't we need the jpeg libs
into wine? (as the useflag list doesn't show the jpeg flag at all, running
testing/unstable) sry if there's something i should have known but missed here

Actually, I think all the graphical emul-linux-x86 packages seem to need new
versions with the latest stable jpeg. Subsequent revdep-rebuilds will pull in
all the emul-* dependencies to merge them every singe time r-r is run, since
the old jpeg-6 cruft is still present.

As you can see from the forums
(http://forums.gentoo.org/viewtopic-p-5995893.html#5995893), disabling the jpeg
flag in wine on an amd64 system breaks more games than it fixes.

Following the suggestion of ssuominen with a couple of extra steps fixes the
jpeg issue:

emerge -1 app-emulation/emul-linux-x86-baselibs
FEATURES="collision-protect" ABI="x86" DEFAULT_ABI="x86" CFLAGS="-march=i686
-m32 -O2 -pipe" emerge -av1 jpeg

After this, it will abort the emerge because of file collision. That's O.K.

Now,

cp -af /var/tmp/portage/media-libs/jpeg-7/work/jpeg-7/.libs/libjpeg.so*
/usr/lib32/ 

Added steps:

- Comment out "app-emulation/wine jpeg" line in
/usr/portage/profile/arch/amd64/package.use.mask
- rebuild wine (with the jpeg USE flag enabled

Hope this helps.

app-emulation/emul-linux-x86-baselibs-20091004_rc1 contains jpeg-7.  It needs
testers.

(In reply to comment #9)
> app-emulation/emul-linux-x86-baselibs-20091004_rc1 contains jpeg-7.  It needs
> testers.

Seems to work okay with Skype at least. No runtime errors there.

However, revdep-rebuild still wants to keep re-emerging a few other packages,
citing broken jpeg-6.2 libs:

app-emulation/emul-linux-x86-xlibs-20080810
app-emulation/emul-linux-x86-medialibs-20071114
(also vte and freeglut, but I expect those to disappear once the next r-r
finishes)

(In reply to comment #10)
> (In reply to comment #9)
> > app-emulation/emul-linux-x86-baselibs-20091004_rc1 contains jpeg-7.  It needs
> > testers.
> 
> Seems to work okay with Skype at least. No runtime errors there.
> 
> However, revdep-rebuild still wants to keep re-emerging a few other packages,
> citing broken jpeg-6.2 libs:
> 
> app-emulation/emul-linux-x86-xlibs-20080810
> app-emulation/emul-linux-x86-medialibs-20071114
> (also vte and freeglut, but I expect those to disappear once the next r-r
> finishes)
> 
I've updated them all, see
http://dev.gentoo.org/~kingtaco/emul-linux-x86-20091004_rc1.xml

I updated to app-emulation/emul-linux-x86-baselibs-20091004_rc1, unmasked the
jpeg use keyword for wine, and updated wine. I was able to run the patcher
program with World of Warcraft, which was crashing before. So looks like wine's
fixed again.
The only broken package that I still had was sci-electronics/eagle-5.6.0. Since
it's a binary only package, I just copied the old libjpeg library back into
/usr/lib32

app-emulation/emul-linux-x86-baselibs-20091004_rc1 and unmasking the jpeg
useflag for wine fixed the jpeg issue for me as well. That was the only piece
of software that was misbehaving for me. I wonder if there is a reason
we(users) just don't build our own 32 bit versions of libs, maybe with some use
flag that could then be checked for with the use dependencies of EAPI2.
</wishlist>

I vote for this too, it seems not to break anything (though I did not test it
deeply)

*** Bug 287902 has been marked as a duplicate of this bug. ***

*** Bug 288143 has been marked as a duplicate of this bug. ***

*** Bug 290409 has been marked as a duplicate of this bug. ***

*** Bug 292364 has been marked as a duplicate of this bug. ***

I can confirm the workaround in the bug (emul-linux-x86-baselibs-20091004_rc1 +
umasking wine jpeg use flag).