Bugzilla Bug 191916

Not sure if we're missing a dependency somewheres.  Looks like something isn't
right regarding jpeg dependencies.  Thoughts?

We'll be removing mips keywords from 2.4* until we get this bug resolved, as
2.3.19 is stable for us (even though it's a dev-branch).  Once this is sorted
out, I'll throw ~mips back into the KEYWORDS.


Error Message:

mips-unknown-linux-gnu-gcc -O2 -march=r10000 -mtune=r10000 -pipe
-fomit-frame-pointer -ftracer -fforce-addr -fweb -Wall
-Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations
-Winit-self -Wpointer-arith -o jpegqual jpeg-quality.o jpegqual.o -pthread 
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so
/usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so
/usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libgobject-2.0.so
/usr/lib/libgmodule-2.0.so -ldl /usr/lib/libgthread-2.0.so -lrt
/usr/lib/libglib-2.0.so
jpegqual.o: In function `main':
jpegqual.c:(.text+0x5a4): undefined reference to `jpeg_std_error'
jpegqual.c:(.text+0x5c4): undefined reference to `jpeg_CreateDecompress'
jpegqual.c:(.text+0x5d8): undefined reference to `jpeg_stdio_src'
jpegqual.c:(.text+0x5ec): undefined reference to `jpeg_read_header'
jpegqual.c:(.text+0x630): undefined reference to `jpeg_destroy_decompress'
jpegqual.c:(.text+0x6ac): undefined reference to `jpeg_std_error'
jpegqual.c:(.text+0x6cc): undefined reference to `jpeg_CreateDecompress'
jpegqual.c:(.text+0x6e0): undefined reference to `jpeg_stdio_src'
jpegqual.c:(.text+0x6f4): undefined reference to `jpeg_read_header'
jpegqual.c:(.text+0x88c): undefined reference to `jpeg_destroy_decompress'
jpegqual.c:(.text+0xa54): undefined reference to `jpeg_destroy_decompress'
collect2: ld returned 1 exit status
make[3]: *** [jpegqual] Error 1
make[3]: Leaving directory
`/usr/obj/portage/media-gfx/gimp-2.4.0_rc2/work/gimp-2.4.0-rc2/plug-ins/jpeg'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/usr/obj/portage/media-gfx/gimp-2.4.0_rc2/work/gimp-2.4.0-rc2/plug-ins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/usr/obj/portage/media-gfx/gimp-2.4.0_rc2/work/gimp-2.4.0-rc2'
make: *** [all] Error 2


emerge --info:

Portage 2.1.3.9 (default-linux/mips/2007.1-dev/ip30/o32, gcc-4.1.2,
glibc-2.6.1-r0, 2.6.23-rc5-mipsgit-20070904 mips64)
=================================================================
System uname: 2.6.23-rc5-mipsgit-20070904 mips64 R14000 V2.3 FPU V0.0
Timestamp of tree: Sat, 08 Sep 2007 21:20:01 +0000
distcc 2.18.3 mips-unknown-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [disabled]
app-shells/bash:     3.2_p17-r1
dev-lang/python:     2.3.6, 2.4.4-r4, 2.5.1-r2
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.10-r4
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18
sys-devel/gcc-config: 1.4.0-r2
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="mips ~mips"
CBUILD="mips-unknown-linux-gnu"
CFLAGS="-O2 -march=r10000 -mtune=r10000 -pipe -fomit-frame-pointer -ftracer
-fforce-addr -fweb"
CHOST="mips-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/init.d /etc/pam.d
/etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O2 -march=r10000 -mtune=r10000 -pipe -fomit-frame-pointer -ftracer
-fforce-addr -fweb"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sfperms strict unmerge-orphans
userfetch userpriv"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/usr/obj"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="X berkdb cli cracklib fortran gdbm iconv ip30 isdnlog libwww midi mips
mudflap nptl nptlonly openmp pam pcre perl pppd python readline reflection
session spl ssl tcpd truetype-fonts type1-fonts unicode usb userlocales xorg"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev impact newport
v4l"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Turns out that gtk+ needs to be built with use 'jpeg', per drac's suggestion. 
I'll see if I can put a patch later on for that.

The GIMP ebuild should check wheither gtk+ is compiled with the correct
USE-flags.

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

I've tried this, and it's not the case, at least not on all machines.

I can build gtk+ with USE="-jpeg" and gimp with USE="jpeg" without problems.

Does anyone see this on !=mips?

Hanno,

confirmed here with amd64:

USE="-jpeg" emerge gtk+ && USE="jpeg" emerge gimp

emerges without problems.

Not really a mips issue, same thing on x86.

jakub, if you can reproduce it on x86, please tell me how. I couldn't.

Build gtk+ with -jpeg in USE, then switch it to 'jpeg', then merge gimp; you
should get the errors I have listed in my opening post.  Least, that roughly
mimics the setup I had on my Octane until it was suggested I try rebuilding
gtk+ with jpeg USE.

I don't get the error (after merging gtk+ with -jpeg and then gimp with +jpeg),
so there's nothing I can do for now. If anyone sees this on x86, please post
compile log and emerge --info.

So can we get this change in, or until reproduced on x86, it's blocked for us?

I'll attach a screenshot of it running on my Octane to show 2.4.0 is working
(gonna build 2.4.2 shortly).

Created an attachment (id=137779) [edit]
Gimp 2.4.0 sunning on an SGI Octane

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

I've digged deeper into this. This has nothing to do with gtk+ (nor with mips
or ppc), it's basically a bug in gimp's configure-script. For the details, see
this upstream bug:

http://bugzilla.gnome.org/show_bug.cgi?id=507572

I don't consider this importand enough to patch it in gentoo (as this would
require running eautoreconf/autotools-eclass, thus adding additional bloat).
I'll wait till this get's fixed upstream, should get fixed within the next one
or two gimp releases. Workaround is not to build gimp with -jpeg or emerge
media-libs/jpeg before doing so.

Hmm, well, all I know is since rebuilding gtk+ w/ the jpeg stuff, if I
re-keyword gimp-2.4.x, it'll build and update for me.  Perhaps we can add a
mips & ppc specific bit in the current ebuilds until upstream fixes the issue? 
That keeps the impact minimized to two archs suffering the issue right now.

I'd have said disable the jpeg useflag until it's fixed, but as long as it gets
fixed I don't care :)

(In reply to comment #14)
It does not only affect mips & ppc. I just ran across this in my newbie
installation on a new amd64. Could not build gimp (same complaints about
missing jpeg methods).

Summary: On my AMD64, I installed gentoo without "jpeg" USE flag. gtk+ was
built without the flag. Then gimp build failed. I then (being a newbie) did:
# emerge jpeg (I found the library and suspected some lacking dependency)
# emerge gimp --> Still failing
When everything else fails, read the documentation, right?
Then I found this bug description.
I set the jpeg USE flag (in /etc/make.conf in my case)
# emerge --newuse gtk+
# emerge gimp --> SUCCESS

So (after emerging jpeg library, if that has anything to do with it), things
work if both gtk+ and gimp are built with the jpeg USE flag. Being a newbie, I
can only observe, not diagnose ;-)

I've now temporarily removed the jpeg-useflag from the gimp ebuild (as jpeg
disabling was broken anyway).

This is fixed in gimp trunk, but backporting is nontrivial, so it'll stay this
way till upstream trunk get's a new version. Then we'll add the jpeg flag back.

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

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

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

im having this same failure on gimp-2.6.1 when USE=-jpeg is set for gimp