Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jan 2001 10:34:51 +0200
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        John Polstra <jdp@polstra.com>
Cc:        ports@FreeBSD.org
Subject:   Re: Strange problems with dynamic linking of libGL.so.1 from  XFree86-4.0.2_5
Message-ID:  <3A6FE52B.AC9970C2@FreeBSD.org>
References:  <3A6C3D19.E1F56291@FreeBSD.org> <200101250417.f0P4HnT29626@vashon.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote:

> 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.

I see exactly what you described, so probably the problem is elsewhere.

max@notebook$ ls -l /usr/lib/libgcc.a /usr/X11R6/lib/libGL.so.1
-rwxr-xr-x  1 root  wheel  435959 Jan 19 16:25 /usr/X11R6/lib/libGL.so.1*
-r--r--r--  1 root  wheel  142544 Jan 16 19:40 /usr/lib/libgcc.a
max@notebook$ gcc -v
Using builtin specs.
gcc version 2.95.3 20010101 (prerelease)
max@notebook$ 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
max@notebook$

-Maxim



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?3A6FE52B.AC9970C2>