Re: [gentoo-user] jpg support

[Daniel Pielmeier]

Alan McKinnon schrieb am 08.11.2008 16:00:
> On Saturday 08 November 2008 16:08:22 Michael P. Soulier wrote:
>> On Sat, Nov 8, 2008 at 6:15 AM, Daniel Pielmeier
>>
>> <daniel.pielmeier@××××××××××.com> wrote:
>>> So there are two possibilities. First there is no need for a jpg useflag
>>> as it will work out of the box. Second the jpg support or needed
>>> libraries if they are indeed needed are detected automagically which is
>>> bad and a bug should be filed. But from a quick glance into the relevant
>>> files I did not recognize such things.
>>>
>>> So I guess rebuilding the affected packages and trying again is the best
>>> option.
>> I tried rebuilding gqview and feh with no success. feh complains about
>> no imlib support for jpegs so I rebuild imlib, which didn't help.
>> Before going to bed I started a full world rebuild. I'll reboot after
>> that to ensure I pick up new shared libraries and we'll see what
>> happens. This violates the principle of least surprise though.
>
> You are going about this the wrong way. Gentoo can't really make a package
> more configurable than what it's author provides. feh has no option
> to ./configure to explicitly enable jpeg support, thus there cannot be a USE
> flag for it, as described earlier in the thread. If you need/want to know
> what's going in with such things, emerge the package and look for the full
> build log in /var/log/portage/. Examine it, it will tell you how the package
> builds.
>
> imlib is the same, no explicit switch for jpeg, so you have to rely on the
> autodetect voodoo^Wmagic. it sucks, it shouldn't be that way but gentoo
> didn't make it that way.
>
> Why did you decide to rebuild world? That's a bit like a sledge hammer to kill
> a flea....
>
> You can't validly claim this violates least surprise. Even if your
> expectations were correct and gentoo does violate them, it's not something
> gentoo can fix, the problem is in the configure script.
>> I am finding this about gentoo. On FreeBSD I could disable X11
>> support, but it's on by default. I agree with that. On gentoo I have
>> to explicitely enable jpg support?? Why the hell would I not want it?
>> I find that needlessly difficult. The default should be the common
>> case, not the uncommon one.
>
> I'll bet your profile points to a server profile, not a desktop one. For the
> server profile, the default is no X server and thus no jpeg. A quick search
> shows me that all the desktop profiles enable jpeg by default - the expected
> state for most users. You profile is dictated by what the /etc/make.profile
> symlink points to.
>
> I think you need to re-read the gentoo handbook, the full thing from beginning
> to end. As you have made several mistakes thus far that show me you don't
> know where or how to select the thing you want.
>

Thank you Alan for your always helpful answers. While having nothing to
do I investigated a bit more on this issue and have something to add here.

First USE _jpeg_ should be enabled by default for desktop profiles.

I can view jpegs without problems in gqview and gqview doesn't require
anything jpeg related to view them. qgview only requires gtk+.

I took a look at the shared libraries (1) linked against gqview and with
the help of the reverse dependencies (2) of the packages owning that
shared libraries I was able to validate that gqview only needs gtk+
because all libraries used by gqview need gtk+ in some way. So the gtk+
dependency pulls in everything needed for gqview.

Now I took a look at the output of strace gqview (3). Here are the
relevant lines:

read(4, " 5 \"gtk20\" \"The JPEG image format"..., 1024) = 1024
stat64("/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so",
{st_mode=S_IFREG|0755, st_size=17756, ...}) = 0
open("/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so",
O_RDONLY) = 6
open("/usr/lib/libjpeg.so.62", O_RDONLY) = 6

Owners of the relevant libraries:
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so is owned by
x11-libs/gtk+-2.12.11
/usr/lib/libjpeg.so.62 is owned by media-libs/jpeg-6b-r8

So gtk+ can open jpegs but why can't you on your system?

USE flags for gtk+:
x11-libs/gtk+-2.12.11  USE="X cups jpeg tiff -debug -doc -vim-syntax
-xinerama"

The answer is gqview does not need a jpeg use flag nor does probably
feh, but gtk+ has to be built with jpeg support.

So there is no need for rebuilding world, adding the jpeg flag to gtk
should be enough. Or better if you use Gentoo on a desktop enable the
desktop profile. Plus instead of blaming Gentoo, learn how it works and
to use it properly. I know nothing about FreeBSD so I would not allow me
any prejudices against it. *sigh*


Just for your information I used the following commands for investigation

1) Packages needed by qgview by finding the owners of the shared
libraries needd by gqview:

ldd /usr/bin/gqview | sed -n 's/\s*\(.*\)\s=>\s.*/\1/p' | xargs qfile
--nocolor

2) Reverse dependencies of said Packages:

ldd /usr/bin/gqview | sed -n 's/\s*\(.*\)\s=>\s.*/\1/p' | xargs qfile
--nocolor | sed -n 's/\(.*\)\s.*/\1/p' | xargs emerge -pv --depclean

3) strace

strace gqview some.jpg  2>&1 | tee strace