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 attachment 137779 [details] 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
