The configure script only looks in /usr/include for linux kernel headers, so it doesn't find them in /usr/local/include: .. checking linux/videodev.h usability... no checking linux/videodev.h presence... no checking for linux/videodev.h... no configure: error: in `/tmp/obj/usr/ports/graphics/zbar/work/zbar-0.10': configure: error: test for video support failed! rebuild your kernel to include video4linux support or configure --disable-video to skip building video support. See `config.log' for more details. ===> Script "configure" failed unexpectedly. .. Fix: Patch attached with submission follows: How-To-Repeat: # cd /usr/ports/graphics/zbar # make PORT_OPTIONS=V4L
Maintainer of graphics/zbar, Please note that PR ports/187923 has just been submitted. If it contains a patch for an upgrade, an enhancement or a bug fix you agree on, reply to this email stating that you approve the patch and a committer will take care of it. The full text of the PR can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/187923 -- Edwin Groothuis via the GNATS Auto Assign Tool edwin@FreeBSD.org
State Changed From-To: open->feedback Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Looks good to me. Feel free to commit.
Update: I've started stagifying this and working through some issues that are thrown up by portlint and the various make checks.
Created attachment 143624 [details] Fix CPP include path This issue impacts more than just V4L for zbar; under FreeBSD 10.0, the port fails to build since libjpeg cannot be found as the local include dir (normally /usr/local/include) is not passed to CPPFLAGS. This results in the following build failure when the libjpeg.h header can't be found: /bin/sh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I./include -I./zbar -I./include -DLIBICONV_PLUG -Wall -Wno-parentheses -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -MT zbar/zbar_libzbar_la-jpeg.lo -MD -MP -MF zbar/.deps/zbar_libzbar_la-jpeg.Tpo -c -o zbar/zbar_libzbar_la-jpeg.lo `test -f 'zbar/jpeg.c' || echo './'`zbar/jpeg.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I./include -I./zbar -I./include -DLIBICONV_PLUG -Wall -Wno-parentheses -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -MT zbar/zbar_libzbar_la-jpeg.lo -MD -MP -MF zbar/.deps/zbar_libzbar_la-jpeg.Tpo -c zbar/jpeg.c -fPIC -DPIC -o zbar/.libs/zbar_libzbar_la-jpeg.o zbar/jpeg.c:25:10: fatal error: 'jpeglib.h' file not found #include <jpeglib.h> ^ 1 error generated. The new zbar-cpp-includes.patch alters the logic of the earlier patch by moving the CPPFLAGS definition to the body of the Makefile. There's no reason to conditionally add this as the configure arg --with-jpeg=yes is always set. With this patch applied, the build completes normally for me, and should also resolve the V4L build issue.
Created attachment 144216 [details] Fix build and staging for all OPTIONS - Fix build/staging for all permutations of OPTIONS - Fix pkg-plist - Bump PORTREVISION @Maintainer: Please verify and approve if patch is correct
Also, added USES= libtool in attachment 144216 [details]
This patch looks good. I approve of it and many, many thanks to Thomas for doing this. I'm puzzled though by the june 17th commit. It modifies LIB_DEPENDS for ImageMagick to: LIB_DEPENDS+= libMagick++-6.Q*.so:${PORTSDIR}/graphics/ImageMagick Which apparently ImageMagick-nox11 from the repository can't satisfy. When I rewrite to: LIB_DEPENDS+= libMagick++.so:${PORTSDIR}/graphics/ImageMagick all is well again and zbarimg works fine. Do you need a new patch for this, a new PR perhaps, or is there good reason to keep it as is?
The June 17 commit was probably necessary because 16BIT_PIXEL option has been made default for ImageMagick. This means by default ImageMagick will build shared libs named libMagick++-6.Q(8|16).(a|so). I just double-checked this in a fresh jail with default OPTIONS (both on 10.0 and 9.2 with both ImageMagick and ImageMagick-nox11), and indeed no libMagick++.so gets installed, instead we get libMagick++-6.Q16.so. The LIB_DEPENDS line is correct; changing it back would now break building zbar from ports from scratch. Once ImageMagick-nox11 is rebuilt on the cluster, the necessary shared libs will be provided.
A commit references this bug: Author: riggs Date: Sun Jun 29 07:58:03 UTC 2014 New revision: 359739 URL: http://svnweb.freebsd.org/changeset/ports/359739 Log: - Fix build/staging of graphics/zbar for all permutations of OPTIONS - CPPFLAGS - Get rid of MAN1 - Fix pkg-plist - Introduce USES=libtool - Bump PORTREVISION including dependent ports that need rebuild PR: 187923 Submitted by: kamikaze@bsdforen.de Reviewed by: Oliver Heesakkers <dev2@heesakkers.info> (maintainer) Approved by: maintainer, mentors (implicit) Changes: head/graphics/gstreamer1-plugins-zbar/Makefile head/graphics/zbar/Makefile head/graphics/zbar/pkg-plist
Committed, thank you!