`graphics/libgphoto2' port installs libraries to work with various digital cameras. It can also be built with NLS (enabled by default). While main library (/usr/local/lib/libgphoto2.so) correctly embeds explicit reference to libintl.so.9, other libraries (e.g. /usr/local/lib/libgphoto2_port.so and /usr/local/lib/libgphoto2_port/0.8.0/*.so driver support libs) do not. I believe this happens because of the `gnome-libtool' script (while system libtool script behaves alike). On FreeBSD, gettext-related functions are not in libc, but in libintl, and INTLLIBS detected by configure script(s) as follows: /usr/local/lib/libintl.so -L/usr/local/lib /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib Now, consider this part from the build log of `libgphoto2_port/ptpip' driver: /bin/sh /home/danfe/fbsd/ports/graphics/libgphoto2/work/gnome-libtool --tag=CC --mode=link cc -O2 -pipe -march=pentium4m -fno-strict-aliasing -O2 -pipe -march=pentium4m -fno-strict-aliasing -module -no-undefined -avoid-version -export-dynamic -export-symbols ../iolib.sym -o ptpip.la -rpath /usr/local/lib/libgphoto2_port/0.8.0 ptpip_la-ptpip.lo ../libgphoto2_port/libgphoto2_port.la /usr/local/lib/libintl.so -L/usr/local/lib /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -lpthread *** As you can see, reference to libintl.so passed in... *** gnome-libtool: link: cc -shared -fPIC -DPIC .libs/ptpip_la-ptpip.o -Wl,-rpath -Wl,/home/danfe/fbsd/ports/graphics/libgphoto2/work/libgphoto2-2.4.11/libgphoto2_port/libgphoto2_port/.libs -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib ../libgphoto2_port/.libs/libgphoto2_port.so -L/usr/local/lib /usr/local/lib/libltdl.so -lpthread -O2 -march=pentium4m -O2 -march=pentium4m -Wl,-rpath -Wl,/usr/local/lib -Wl,-soname -Wl,ptpip.so -Wl,-retain-symbols-file -Wl,../iolib.sym -o .libs/ptpip.so *** ...but judging from this libtool output, resulting shared object is not being linked to libintl. *** Apparently, this bug is usually unnoticed because it does not happen on GNU/Linux where glibc already includes gettext symbols. However, the bug exposes itself on FreeBSD, when using Python binding for libgphoto2, called piggyphoto, available here: http://magiclantern.wikia.com/wiki/Remote_control_with_PTP_and_Python How-To-Repeat: Checkout the source code for piggyphoto from the Git repository (git clone git://github.com/alexdu/piggyphoto.git) and try to do the following: $ python autodetect.py libgphoto2 version: 2.4.11 cc (C compiler used) no ltdl (for portable loading of camlibs) EXIF (for special handling of EXIF files) detected cameras: /libexec/ld-elf.so.1: /usr/local/lib/libgphoto2_port/0.8.0/ptpip.so: Undefined symbol "libintl_dgettext"
Responsible Changed From-To: freebsd-ports-bugs->pav Fix synopsis and reassign.
State Changed From-To: open->feedback Do you have a fix? When I tried to add -lintl linking to libgphoto2_port.so, your autodetect.py no longer complains about missing smybol, instead it segfaults when executed as user, and completes but detects no cameras when executed as root.
> Do you have a fix? Unfortunately, no. If I had a patch, I would glady included it in the PR. I am a bit short on time right now, and it would probably take me a while to find my way though libtool, which I try to avoid as much as possible. I use the following work-around right now to use these Python bindings: env LD_PRELOAD=libintl.so python autodetect.py > When I tried to add -lintl linking to libgphoto2_port.so, autodetect.py no > longer complains about missing symbol, instead it segfaults when executed > as user, and completes but detects no cameras when executed as root. Super-user privileges should not be required if you have something like "add path 'usb/*' mode 0660" in your local devfs rules. However, I've checked both root and non-root behavior, no segfauls observed. Camera detection works fine, but you need to teach piggyphoto/__init__.py about FreeBSD device naming (ugen), patch attached. With it, my 450D is detected and seems to work correctly: $ env LD_PRELOAD=libintl.so python autodetect.py libgphoto2 version: 2.4.11 cc (C compiler used) no ltdl (for portable loading of camlibs) EXIF (for special handling of EXIF files) detected cameras: cameraList object with 1 elements: 0: (Canon EOS 450D (PTP mode), usb:/dev/usb,/dev/ugen4.3)
The code path your patch changes does not execute at all here. The execution dies for me on this line: check(gp.gp_abilities_list_load(cameraAbilitiesList._static_l, context)) Backtrace dies in the C library (gdb) bt #0 gp_context_progress_start (context=0xe0d300, target=Variable "target" is not available. ) at gphoto2-context.c:165 #1 0x000000080132d4ae in gp_abilities_list_load (list=0x800f8f0f0, context=0xe0d300) at gphoto2-abilities-list.c:214 #2 0x000000080121c458 in ffi_call_unix64 () from /usr/local/lib/python2.7/lib-dynload/_ctypes.so Might be some problem with amd64 arch, as the pointers are 32-bit which looks odd. Can you rebuild your libgphoto2 port with attached patch and see if that runs for you without that LD_PRELOAD thing? Alexey Dokuchaev pí¹e v st 07. 09. 2011 v 11:44 +0700: > > Do you have a fix? > > Unfortunately, no. If I had a patch, I would glady included it in the PR. > I am a bit short on time right now, and it would probably take me a while > to find my way though libtool, which I try to avoid as much as possible. > > I use the following work-around right now to use these Python bindings: > > env LD_PRELOAD=libintl.so python autodetect.py > > > When I tried to add -lintl linking to libgphoto2_port.so, autodetect.py no > > longer complains about missing symbol, instead it segfaults when executed > > as user, and completes but detects no cameras when executed as root. > > Super-user privileges should not be required if you have something like > "add path 'usb/*' mode 0660" in your local devfs rules. However, I've > checked both root and non-root behavior, no segfauls observed. > > Camera detection works fine, but you need to teach piggyphoto/__init__.py > about FreeBSD device naming (ugen), patch attached. With it, my 450D > is detected and seems to work correctly: > > $ env LD_PRELOAD=libintl.so python autodetect.py > libgphoto2 version: > 2.4.11 > cc (C compiler used) > no ltdl (for portable loading of camlibs) > EXIF (for special handling of EXIF files) > > detected cameras: > cameraList object with 1 elements: > 0: (Canon EOS 450D (PTP mode), usb:/dev/usb,/dev/ugen4.3) -- -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> 42.7 percent of all statistics are made up on the spot.
On Wed, Sep 07, 2011 at 09:29:53PM +0200, Pav Lucistnik wrote: > The code path your patch changes does not execute at all here. > The execution dies for me on this line: > > check(gp.gp_abilities_list_load(cameraAbilitiesList._static_l, context)) > > Backtrace dies in the C library > > Might be some problem with amd64 arch, as the pointers are 32-bit which > looks odd. Hmm, weird indeed. Cannot test it here due to lack of 64-bit hardware, but 32-bit pointers look odd, true. > Can you rebuild your libgphoto2 port with attached patch and see if that > runs for you without that LD_PRELOAD thing? It does, thanks!
State Changed From-To: feedback->closed Fix committed
pav 2011-09-09 19:55:18 UTC FreeBSD ports repository Modified files: graphics/libgphoto2 Makefile Log: - Make sure libgphoto_port library is linked with libintl, otherwise non-gettext apps (python) that dl_open libgphoto_port plugins are rather unhappy PR: ports/160508 Reported by: danfe Tested by: danfe Revision Changes Path 1.63 +4 -0 ports/graphics/libgphoto2/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"