Bug#494172: libosmesa6: libOSMesa / libGl symbol collision
On Tue, Jun 29, 2010 at 8:33 AM, Julien Cristau <jcristau@debian.org> wrote:
> [Josep, sorry for the very late answer]
>
> Hi Dan,
>
> Josep reported the following bug against libOSMesa in Debian (see
> http://bugs.debian.org/494172), and I'm not quite sure how it's supposed
> to work, so I was hoping you'd know a bit more:
>
> On Thu, Aug 7, 2008 at 17:52:56 +0200, Josep wrote:
>
>> I'm integrating osmesa with an application that use Qt/OpenGl to do
>> Off Screen rendering.
>>
>> But there is somthing that fails.
>> First something strange happends in the link proces. The linking proces is:
>>
>> g++ -o qgreco release/com.o release/crono.o release/dbas.o release/dbasv2.o
>> release/error.o release/fam.o release/full_rt_rcs.o release/gid.o
>> release/grabar.o release/grecoPost.o release/ideas.o release/iges.o
>> release/image.o release/init.o release/input.o release/mialloc.o
>> release/neutral.o release/octree.o release/oiges.o release/param.o
>> release/po_rcs.o release/ptd_rcs.o release/qt_win.o release/rcs.o
>> release/reflexiones.o release/rt_rcs.o release/teselar.o
>> release/vertex_arrays.o release/xogdibuj.o release/glwidget.o
>> release/glwindow.o release/logowidget.o release/twindow.o release/gwindow.o
>> release/initrcs.o release/memoryrc.o release/moc_glwidget.o
>> release/moc_glwindow.o release/moc_logowidget.o release/moc_twindow.o
>> release/moc_gwindow.o release/moc_initrcs.o -L/usr/X11R6/lib -L/usr/lib
>> -lOSMesa -lXext -lX11 -lm -lQtXml -lQtOpenGL -lQtGui -lQtCore -lQtUiTools
>> -lGLU -lGL -lpthread
>>
>> The important part are the linked libraries, first I noticied that depending
>> on the order of the libraries the program fails with segmentation fault
>> (linking GL after OSMesa ) or drawing bad images (linking OSMesa after GL).
>>
>> Then I found that if I link with the Mesa Libraries compiled from the
>> original sources my program run well.
>>
>> The difference I noticied:
>> Using:
>> nm -D /usr/lib/libOSMesa.so (from Debian Packages)
>> Returns a lot of symbols included gl*
>> And ldd.
>> linux-vdso.so.1 => (0x00007fff1e7fe000)
>> libm.so.6 => /lib/libm.so.6 (0x00007fad15f38000)
>> libpthread.so.0 => /lib/libpthread.so.0 (0x00007fad15d1c000)
>> libc.so.6 => /lib/libc.so.6 (0x00007fad159c8000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007fad16640000)
>>
>>
>>
>> nm -D mycompiledlibOSMesa.so (compiled from sources)
>> Returns only some symbols without gl*
>> And ldd.
>> linux-vdso.so.1 => (0x00007fff467fe000)
>> -> libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f6a3e297000)
>> libc.so.6 => /lib/libc.so.6 (0x00007f6a3df44000)
>> libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f6a3dc37000)
>> libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f6a3da26000)
>> libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f6a3d821000)
>> libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f6a3d61e000)
>> libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f6a3d519000)
>> libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f6a3d310000)
>> libm.so.6 => /lib/libm.so.6 (0x00007f6a3d08c000)
>> libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6a3ce70000)
>> libdl.so.2 => /lib/libdl.so.2 (0x00007f6a3cc6c000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f6a3e742000)
>> libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00007f6a3ca6a000)
>> libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f6a3c84e000)
>> libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f6a3c64c000)
>> libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f6a3c446000)
>>
>>
>> I think that libOSMesa.so have compiled in the same libgl code and then
>> there are symbols colision.
>>
>> Can you make the libOSMesa package didn't link libGL static?
>> Otherwise, can you explain myself how to build the package from Debian
>> sources but linking GL libraries dynamically?
>> There ara any other workarrounds to prevent this?
>>
> Is libOSMesa supposed to conflict with libGL?
OSMesa standalone has all the GL entrypoints, so it "conflicts" in a
sense. On prior releases of Mesa an optimization was made that OSMesa
was linked to GL to save space on the internal libraries when
--with-driver!=osmesa. Later hidden symbol visibility was used and
OSMesa started having resolution problems when it tried to use
internal mesa functions. So, we changed always making OSMesa
standalone.
It looks like debian has built the standalone OSMesa. If you grab
mesa-7.8.2, this is also how you'll get OSMesa regardless of the other
options you throw at configure.
> Josep, do you really need to link with -lGL in addition to -lOSMesa?
I would suggest not linking an app to both -lGL and -lOSMesa. If
you're going to use OSMesa, it either has the GL symbols already or
will pull in GL. I.e., just link against `pkg-config --libs osmesa` or
`pkg-config --libs --static osmesa` if necessary.
--
Dan
Reply to: