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

Bug#494172: marked as done (libosmesa6: libOSMesa / libGl symbol collision)

Your message dated Tue, 29 Jun 2010 19:33:17 +0100
with message-id <20100629183317.GG10671@radis.liafa.jussieu.fr>
and subject line Re: Bug#494172: libosmesa6: libOSMesa / libGl symbol collision
has caused the Debian Bug report #494172,
regarding libosmesa6: libOSMesa / libGl symbol collision
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
494172: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494172
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
On Tue, Jun 29, 2010 at 11:28:35 -0700, Dan Nicholson wrote:

> On Tue, Jun 29, 2010 at 8:33 AM, Julien Cristau <jcristau@debian.org> wrote:
> > 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.
> 
OK, that matches what I understood from the thread on mesa-dev.

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

Based on this I'll close this bug as invalid.  Josep, please feel free
to follow up if you think this is incorrect.

Thanks a lot for the explanations, Dan!

Cheers,
Julien

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: