GNOME Bugzilla – Bug 507572
gimp ./configure --without-libjpeg doesn't work
Last modified: 2008-10-30 20:08:02 UTC
Please describe the problem: The configure script of gimp doesn't honour the --without-libjpeg parameter. The reason is that the logic inside configure.in doesn't set jpeg_ok if that parameter is passed, thus leaving it in an undefined state (being empty), which causes the makefile to try to build the jpeg plugin. This will fail if libjpeg isn't installed The fix is simple, just set jpeg_ok before the parameter-check to no (as it's done on various other places in configure.in), which will prevent it from getting undefined states. I'll attach a oneliner-patch doing that. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 102248 [details] [review] gimp-without-jpeg.diff
Hmm, I was a bit too fast. While this patch causes the configure-script to correctly say JPEG: no, it still tries to build the jpeg-plugin. Seems someone with deeper knowledge of autotools should have a look at it.
Created attachment 102249 [details] [review] improved patch Does this patch fix it for you?
No. Why are you setting jpeg_ok default to yes? Imho doesn't make sense (as the check afterwards checks for != no, thus if the check fails, it's ==no) Changing jpeg_ok=yes to jpeg_ok=no should be correct, I'll just try that.
That was just an oversight. Please test the patch with this value changed to no.
/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -O2 -march=pentium-m -fomit-frame-pointer -pipe -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wl,-O1 -Wl,--as-needed -o uri uri.o uri-backend-gnomevfs.o ../../libgimp/libgimpui-2.0.la ../../libgimpwidgets/libgimpwidgets-2.0.la ../../libgimpconfig/libgimpconfig-2.0.la ../../libgimpmath/libgimpmath-2.0.la ../../libgimp/libgimp-2.0.la ../../libgimpcolor/libgimpcolor-2.0.la ../../libgimpbase/libgimpbase-2.0.la -pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgconf-2 -lgmodule-2.0 -ldl -lORBit-2 -lgthread-2.0 -lrt -lgobject-2.0 -lgnome-keyring -lglib-2.0 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 mkdir .libs libtool: link: cannot find the library `/usr/lib/libjpeg.la' or unhandled argument `/usr/lib/libjpeg.la' make[3]: *** [uri] Fehler 1 make[3]: Leaving directory `/var/tmp/portage/media-gfx/gimp-2.4.3/work/gimp-2.4.3/plug-ins/uri' So not yet fixed, but better than before :-)
Well, the point is that libjpeg is a hard dependency of GTK+. You can't really compile without it. I am going to commit the change to trunk and close this report as FIXED.
Committed to trunk: 2008-01-06 Sven Neumann <sven@gimp.org> * configure.in * plug-ins/Makefile.am: fixed --without-jpeg configure option (bug #507572). I don't think it's worth back-porting this to the stable branch. Closing as FIXED.
That's not true, gtk+ can be built without libjpeg. I tried again and found that the libjpeg.la is pulled in by libgnomeui, if that's also built without jpeg support, gimp now can be compiled fine without jpeg support. >I don't think it's worth back-porting this to the stable branch. Closing as >FIXED. Does that mean it won't appear in 2.4? I'd really prefer to have it fixed there, there's no "backporting", as the patch applies 1:1 on 2.4.3, so you can easily commit it and have it fixed in 2.4.4.
The patch has the risk of breaking the build and it is not generally useful. So it is not going to be back-ported to the stable branch.
Why can I already see Gentoo users coming to #gimp or Bugzilla in order to complain that JPEG is not supported by GIMP? ;)