GNOME Bugzilla – Bug 310263
_gst.so fails to load on freebsd/sparc64 due (libxml)
Last modified: 2017-07-26 17:49:26 UTC
Distribution/Version: sparc64 1) use FreeBSD/sparc64 2) extract Istanbul source 3) ./configure of course I have python gstreamer module 0.8.2, configure: configuring istanbul for release checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether gmake sets $(MAKE)... yes configure: Storing library files in /usr/X11R6/lib configure: Storing data files in /usr/X11R6/share configure: Storing configuration files in /usr/X11R6/etc configure: Using localstatedir /usr/X11R6/var checking build system type... sparc64-portbld-freebsd5.4 checking host system type... sparc64-portbld-freebsd5.4 checking for style of include used by gmake... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking dependency style of cc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to run the C++ preprocessor... c++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether f77 accepts -g... yes checking the maximum length of command line arguments... (cached) 65536 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for correct ltmain.sh version... yes checking if cc static flag works... yes checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... freebsd5.4 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by c++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking for c++ option to produce PIC... -fPIC checking if c++ PIC flag -fPIC works... yes checking if c++ supports -c -o file.o... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd5.4 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd5.4 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes configure: Looking for Python version >= 2.3 checking for python... /usr/local/bin/python checking "/usr/local/bin/python":... okay checking local Python configuration... looks good checking for python version... 2.4 checking for python platform... freebsd5 checking for python script directory... ${prefix}/lib/python2.4/site-packages checking for python extension module directory... ${exec_prefix}/lib/python2.4/site-packages checking for headers required to compile python extensions... found configure: Using pythondir /usr/X11R6/lib/python2.4/site-packages checking for pkg-config... /usr/local/bin/pkg-config checking for gstreamer-0.8 >= 0.8.10... yes checking GST_CFLAGS... -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/X11R6/include/gstreamer-0.8 checking GST_LIBS... -Wl,--export-dynamic -pthread -L/usr/X11R6/lib -lgstreamer-0.8 checking for pygtk-2.0 >= 2.6.0... yes checking PYGTK_CFLAGS... -I/usr/local/include/pygtk-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include checking PYGTK_LIBS... configure: Using pygtk installed in /usr/local/lib/python2.4/site-packages checking for pygtk codegen... /usr/local/bin/python /usr/local/share/pygtk/2.0/codegen/codegen.py checking for pygtk defsdir... /usr/local/share/pygtk/2.0/defs checking for gtk+-2.0... yes checking GTK_CFLAGS... -DXTHREADS -DXUSE_MTSAFE_API -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/X11R6/include/pango-1.0 -I/usr/local/include/freetype2 -I/usr/local/include checking GTK_LIBS... -Wl,--rpath -Wl,/usr/local/lib -L/usr/X11R6/lib -lgtk-x11-2.0 checking for gtk.glade... found checking for gst-python-0.8 >= 0.8.0... yes checking PYGST_CFLAGS... -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/include/gst-python-0.8 -I/usr/local/include/pygtk-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/X11R6/include/gstreamer-0.8 checking PYGST_LIBS... -Wl,--export-dynamic -pthread configure: Using gstreamer-python installed in /usr/local/lib/python2.4/site-packages checking for python module gst... not found configure: error: Maybe you forgot to set your PYTHONPATH?
What is python -c "import gst" saying?
>>> import gst Traceback (most recent call last):
+ Trace 61729
from _gst import *
symbol "libxml_xmlDocPtrWrap" This happens on FreeBSD alpha/sparc64/amd64, but not on i386.
i've seen this before, try re-installing libxml then gstreamer then gst-python
do you still have the same problem?
Yes, the problem is still here. py-gst seems to be broken on 64bit archs :(
Reopening, i don't have a 64bit arch so i can't test.. have you tried to re-install libxml,gstreamer,gst-python as zaheer told you?
Yes, this problem happens always on my FreeBSD sparc64 box. I have seen this also once on my i386 box but I couldn't reproduce it after that. One thing I would note is that FreeBSD uses 64-bit userlands on machines that have a 64-bit cpu, like sparc64.
I'll add a check in configure for libXml, and only wrap the xml stuff if it's present. Might be tricky though...
I have a 64 bit machine with 64 bit userland and it works just fine. I think the problem is probably a portability problem with RTLD_GLOBAL and python. The problem is that _gst.so requires symbols from the libxml wrappers but it can't link to them, instead has to rely on runtime dynamic symbol resolution. This probably needs a dlopen freebsd guru to look at it. Changing the subject accordingly. Koop can you look at it, or find someone that can?
This ties in with importing changes to CVS yesterday. I can't see any reason it would change the extant behaviour, but it's a change right in the heart of it: * configure.ac: * gst/Makefile.am: Link against Gst Data protocol libraries. * gst/__init__.py: Restore dlopenflags after importing gst. Closes #329110 c.f. bug 329110
Koop, ping?
Any update on this one?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
A similar bug report with more explanations: https://bugzilla.gnome.org/show_bug.cgi?id=398567