| View previous topic :: View next topic |
| Author |
Message |
platojones
Veteran
Joined: 23 Oct 2002
Posts: 1602
Location: Just over the horizon
|
 Posted: Sun Jan 26, 2014 8:03 pm Post subject: libjpeg-turbo issue - Missing /usr/lib32/libjpeg.so.8 |
 |
|
Ran into an issue yesterday when portage upgraded app-emulation/emul-linux-x86-baselibs. I wound up with a missing 32 bit library that preserved-rebuild and revdep-rebuild cannot resolve. When I run revdep-rebuild, I get this:
| Code: |
20% ] * broken /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so (requires libjpeg.so.8)
* broken /usr/lib32/libImlib.so.1.9.15 (requires libjpeg.so.8)
[ 21% ] * broken /usr/lib32/libmng.so.1.0.0 (requires libjpeg.so.8)
|
Apparently libjpeg-turbo doesn't supply the libjpeg.so.8. I found some bugs on the subject having to do with app-emulation/emul-linux-x86-gtklibs not providing the libjpeg.so.8 anymore, though I'm not sure I completely understand the issues.
Anybody know how to resolve this or have a workaround? |
|
| Back to top |
|
 |
jok
n00b
Joined: 26 Jan 2008
Posts: 22
Location: Finland
|
| Posted: Fri Jan 31, 2014 8:17 am Post subject: |
|
|
I too had broken linkages to 32-bit libjpeg.so.8 from 11 libraries in app-emulation/emul-linux-x86-{media,gtk,qt,base}libs, since libjpeg-turbo does not provide that.
Like Samuli Suominen stated in bug 499170#1, jpeg-8d-r1 would provide it. The problem with that is that there's no way to install 64-bit libjpeg-turbo with 32-bit jpeg because the cross-blockers are independent of ABI.
What I did locally was make a copy of jpeg-8d-r1 that does not install the files provided by libjpeg-turbo-1.3.0-r3, depends on it to provide those files and uses a SLOT that is not blocked.
| Code: |
--- /usr/portage/media-libs/jpeg/jpeg-8d-r1.ebuild 2014-01-31 01:31:22.000000000 +0200
+++ /usr/local/portage/media-libs/jpeg/jpeg-8d-r1.ebuild 2014-01-31 09:48:09.081075459 +0200
@@ -11,11 +11,11 @@ SRC_URI="http://www.ijg.org/files/${PN}s
mirror://debian/pool/main/libj/lib${PN}8/lib${PN}8_8d-1.debian.tar.gz"
LICENSE="IJG"
-SLOT="0"
+SLOT="8"
KEYWORDS="~alpha amd64 arm hppa ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc x86 ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~x86-freebsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
IUSE="static-libs"
-RDEPEND="!media-libs/libjpeg-turbo:0
+RDEPEND="media-libs/libjpeg-turbo:0
abi_x86_32? ( !<=app-emulation/emul-linux-x86-baselibs-20130224-r5
!app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] )"
DEPEND="${RDEPEND}"
@@ -56,14 +56,23 @@ multilib_src_install() {
multilib_src_install_all() {
prune_libtool_files
+ rm ${D}usr/bin/cjpeg \
+ ${D}usr/bin/djpeg \
+ ${D}usr/bin/jpegtran \
+ ${D}usr/bin/rdjpgcom \
+ ${D}usr/bin/wrjpgcom \
+ ${D}usr/include/jconfig.h \
+ ${D}usr/include/jerror.h \
+ ${D}usr/include/jmorecfg.h \
+ ${D}usr/include/jpeglib.h \
+ ${D}usr/lib32/libjpeg.so \
+ ${D}usr/lib64/libjpeg.so \
+ ${D}usr/share/man/man1/cjpeg.1 \
+ ${D}usr/share/man/man1/djpeg.1 \
+ ${D}usr/share/man/man1/jpegtran.1 \
+ ${D}usr/share/man/man1/rdjpgcom.1 \
+ ${D}usr/share/man/man1/wrjpgcom.1
dodoc change.log example.c README *.txt
- # Install exifautotran and jpegexiforient
- newdoc ../debian/changelog changelog.debian
- cd ../debian/extra
- emake \
- DESTDIR="${D}" prefix="${EPREFIX}"/usr \
- INSTALL="install -m755" INSTALLDIR="install -d -m755" \
- install
}
|
This is likely to be wrong in many ways but should at least work as a temporary workaround until an official solution appears. |
|
| Back to top |
|
|
platojones
Veteran
Joined: 23 Oct 2002
Posts: 1602
Location: Just over the horizon
|
| Posted: Fri Jan 31, 2014 3:57 pm Post subject: |
|
|
jok,
Thank you for that reply. I can see this isn't something as simple as unmasking the right packages. It is bugging me having libraries with missing deps laying around, but so far I haven't noticed any functional impact from the missing libjpeg.so.8. I'll just hold tight for now and hope the devs can get this straightened out sooner rather than later. |
|
| Back to top |
|
|
jasn
Guru
Joined: 05 May 2005
Posts: 439
Location: Maryland, US
|
| Posted: Sat Feb 01, 2014 2:37 pm Post subject: |
|
|
I just wanted to add that this appears to be a problem with several emul-linux-x86 libs. For my system right now revdep-rebuild always shows;
| Code: | * Configuring search environment for revdep-rebuild
* Checking reverse dependencies
* Packages containing binaries and libraries broken by a package update
* will be emerged.
* Collecting system binaries and libraries
* Generated new 1_files.rr
* Collecting complete LD_LIBRARY_PATH
* Generated new 2_ldpath.rr
* Checking dynamic linking consistency
[ 28% ] * broken /usr/lib32/directfb-1.4-5/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_jpeg.so (requires libjpeg.so.8)
[ 30% ] * broken /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so (requires libjpeg.so.8)
[ 32% ] * broken /usr/lib32/libImlib.so.1.9.15 (requires libjpeg.so.8)
[ 33% ] * broken /usr/lib32/liblavfile-2.0.so.0.0.0 (requires libjpeg.so.8)
* broken /usr/lib32/liblavjpeg-2.0.so.0.0.0 (requires libjpeg.so.8)
* broken /usr/lib32/libmng.so.1.0.0 (requires libjpeg.so.8)
[ 34% ] * broken /usr/lib32/libsane.so.1.0.23 (requires libjpeg.so.8)
[ 36% ] * broken /usr/lib32/qt4/plugins/imageformats/libqjpeg.so (requires libjpeg.so.8)
* broken /usr/lib32/sane/libsane-dc210.so.1.0.23 (requires libjpeg.so.8)
* broken /usr/lib32/sane/libsane-dc240.so.1.0.23 (requires libjpeg.so.8)
* broken /usr/lib32/sane/libsane-dell1600n_net.so.1.0.23 (requires libjpeg.so.8)
[ 100% ]
* Generated new 3_broken.rr
* Assigning files to packages
* /usr/lib32/directfb-1.4-5/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_jpeg.so -> app-emulation/emul-linux-x86-medialibs
* /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so -> app-emulation/emul-linux-x86-gtklibs
* /usr/lib32/libImlib.so.1.9.15 -> app-emulation/emul-linux-x86-gtklibs
* /usr/lib32/liblavfile-2.0.so.0.0.0 -> app-emulation/emul-linux-x86-medialibs
* /usr/lib32/liblavjpeg-2.0.so.0.0.0 -> app-emulation/emul-linux-x86-medialibs
* /usr/lib32/libmng.so.1.0.0 -> app-emulation/emul-linux-x86-baselibs
* /usr/lib32/libsane.so.1.0.23 -> app-emulation/emul-linux-x86-medialibs
* /usr/lib32/qt4/plugins/imageformats/libqjpeg.so -> app-emulation/emul-linux-x86-qtlibs
* /usr/lib32/sane/libsane-dc210.so.1.0.23 -> app-emulation/emul-linux-x86-medialibs
* /usr/lib32/sane/libsane-dc240.so.1.0.23 -> app-emulation/emul-linux-x86-medialibs
* /usr/lib32/sane/libsane-dell1600n_net.so.1.0.23 -> app-emulation/emul-linux-x86-medialibs
* Generated new 4_raw.rr and 4_owners.rr
* Cleaning list of packages to rebuild
* Generated new 4_pkgs.rr
* Assigning packages to ebuilds
* Generated new 4_ebuilds.rr
* Evaluating package order
* Generated new 5_order.rr
* All prepared. Starting rebuild
emerge --complete-graph=y --oneshot --jobs=8 --load-average=8 --with-bdeps y --autounmask-write y --keep-going app-emulation/emul-linux-x86-baselibs:0 app-emulation/emul-linux-x86-gtklibs:0 app-emulation/emul-linux-x86-medialibs:0 app-emulation/emul-linux-x86-qtlibs:0
.......... |
The libs that are affected are;
| Code: | emul-linux-x86-baselibs-20131008-r12
emul-linux-x86-gtklibs-20131008-r1
emul-linux-x86-medialibs-20131008-r1
emul-linux-x86-qtlibs-20131008 |
I noticed this one bug report for this issue but only as it pertains to emul-linux-x86-baselibs. I originally noticed that this problem exists with emul-linux-x86-baselibs-20131008-r9, and was fixed with emul-linux-x86-baselibs-20131008-r10, but now is back with emul-linux-x86-baselibs-20131008-r12.
Does anyone think that there should be bug reports opened for each affected lib? |
|
| Back to top |
|
|
majoron
Apprentice
Joined: 12 Oct 2005
Posts: 239
Location: Frankfurt
|
| Posted: Wed Feb 11, 2015 11:30 am Post subject: |
|
|
Hello,
I'm having this same problem: libjpeg.so.8 not found because is not provided by otherwise needed libjpeg-turbo package. I searched and found this thread, so I wonder...
Is there an official solution to this issue now?
I imagine that the new way of dealing with the 32bit libraries in a x86_64 system will be the best solution in the near future, but after reading the quoted link it looks to me a bit unstable for now (this problem happend to me in one of our servers and I need a solid fix for this issue).
TIA,
Best
_________________
Computers are like air conditioners, they stop working properly if you open Windows |
|
| Back to top |
|
|
ascendant
n00b
Joined: 13 Nov 2008
Posts: 60
Location: / (USA)
|
| Posted: Wed Feb 11, 2015 11:34 am Post subject: |
|
|
This is a pretty old topic. I subscribed when I had this issue but it's been resolved. Like many issues portage-related, the solution for me was to update more things. There's no chance of remembering what things to update in particular, though.
_________________
This post brought to you by a cheap router. |
|
| Back to top |
|
|
majoron
Apprentice
Joined: 12 Oct 2005
Posts: 239
Location: Frankfurt
|
| Posted: Wed Feb 11, 2015 11:49 am Post subject: |
|
|
| ascendant wrote: | | This is a pretty old topic. I subscribed when I had this issue but it's been resolved. Like many issues portage-related, the solution for me was to update more things. There's no chance of remembering what things to update in particular, though. |
In other words, I should start a new topic.
_________________
Computers are like air conditioners, they stop working properly if you open Windows |
|
| Back to top |
|
|
|
Portage & Programming
