[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#494172: libosmesa6: libOSMesa / libGl symbol collision



Package: libosmesa6
Version: 7.1~rc3-1
Severity: normal



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libosmesa6 depends on:
ii  libc6                         2.7-13     GNU C Library: Shared libraries

libosmesa6 recommends no packages.

libosmesa6 suggests no packages.

-- no debconf information

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?


Thanks,

Josep



Reply to: