Date: Wed, 24 Jan 2001 20:17:49 -0800 (PST) From: John Polstra <jdp@polstra.com> To: ports@freebsd.org Cc: sobomax@freebsd.org Subject: Re: Strange problems with dynamic linking of libGL.so.1 from XFree86-4.0.2_5 Message-ID: <200101250417.f0P4HnT29626@vashon.polstra.com> In-Reply-To: <3A6C3D19.E1F56291@FreeBSD.org> References: <3A6C3D19.E1F56291@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3A6C3D19.E1F56291@FreeBSD.org>,
Maxim Sobolev <sobomax@FreeBSD.ORG> wrote:
> Hi,
>
> I have a strange problems with building py-opengl package on fairly recent
> -current system (gcc 2.95.3). This package builds a shared module, links it
> with various stuff including libGL.so.1 from the XFree86-4.0.2_5 port and then
> tries to register this module with tcl interpreter. Previously this worked like
> a charm, but now I see the following error message probably indicating that tcl
> can't dlopen() this module:
> [...]
> ===> Generating temporary packing list
> /usr/local/bin/tclsh8.3 /mnt/py-opengl/work/PyOpenGL-1.5.6/register.tcl
> warning: error while loading Togl.so: couldn't load file "./Togl.so":
> /usr/X11R6/lib/libGL.so.1: Undefined symbol "pthread_getspecific"
> ===> Registering installation for py-opengl-1.5.6
> [...]
>
> I tried all possible means - linked Togl.so module with -pthread, -Wl,-E and
> -lgcc; recompiled/reinstalled python/tcl/tk etc., but it did not help. If
> someone does have any fresh ideas about what could be wrong please let me know.
>
> -Maxim
> P.S. I suspected that libGL.so.1 is being linked without -pthread somehow, but
> according to bento's logs it is not true:
> [from XFree86-4.0.2_5.log buildlog on -current]
> + LD_LIBRARY_PATH=../../exports/lib cc -o ./libGL.so.1.2~ -shared -rpath
> /usr/X11R6/lib -Wl,-soname,libGL.so.1 glx/clientattrib.o glx/compsize.o
> glx/dispatch.o glx/eval.o glx/g_render.o glx/g_single.o glx/g_vendpriv.o
> glx/glapi.o glx/glapi_x86.o glx/glapinoop.o glx/glthread.o glx/glxcmds.o
> glx/glxext.o glx/indirect_init.o glx/pixel.o glx/pixelstore.o glx/render2.o
> glx/renderpix.o glx/single2.o glx/singlepix.o glx/vertarr.o glx/xfont.o
> dri/XF86dri.o dri/dri_glx.o -pthread
Thanks for sending me the debugging output from the dynamic linker.
Even though bento's logs show the "-pthread" option, libGL is in
fact _not_ being linked with the threads library. That's because
"-pthread" has (almost) no effect when building shared libraries.
I think the actual problem may be in the "/usr/lib/libgcc.a" which
was used to build libGL.so. Try this on the machine where libGL was
built:
wall$ objdump --syms /usr/lib/libgcc.a | grep pthread
00000000 w *UND* 00000000 pthread_create
00000000 w *UND* 00000000 pthread_getspecific
00000000 w *UND* 00000000 pthread_key_delete
00000000 w *UND* 00000000 pthread_once
00000000 w *UND* 00000000 pthread_key_create
00000000 w *UND* 00000000 pthread_mutex_unlock
00000000 w *UND* 00000000 pthread_mutex_lock
00000000 w *UND* 00000000 pthread_mutex_trylock
00000000 w *UND* 00000000 pthread_setspecific
00000000 w *UND* 00000000 pthread_create
00000000 w *UND* 00000000 pthread_getspecific
00000000 w *UND* 00000000 pthread_key_delete
00000000 w *UND* 00000000 pthread_once
00000000 w *UND* 00000000 pthread_key_create
00000000 w *UND* 00000000 pthread_mutex_unlock
00000000 w *UND* 00000000 pthread_mutex_lock
00000000 w *UND* 00000000 pthread_mutex_trylock
00000000 w *UND* 00000000 pthread_setspecific
If you don't get the output above (including the "w" characters)
then libgcc is out of date. I think if you update the system to the
latest and then rebuild libGL it ought to work.
John
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101250417.f0P4HnT29626>