Re: libgl1 vs C++ transition, round 2
This one time, at band camp, Marcelo E. Magallon wrote:
> > You seem to contradict yourself later, see below.
>
> In the sense that after doing
>
> $ ldd ./foo
>
> you'll see libstdc++ in the output, and not in the sense:
>
> $ gcc -o foo ... -lstdc++
>
> Hopefully that makes things less muddy.
Yep, that makes sense.
> > > I can't understand Becko's observation (is glut force-linking
> > > against libstdc++ or something like that?)
> >
> > glut currently isn't linking against libstdc++ at all.
>
> Then I really don't understand what he meant.
>
> > I believe he means that symbols like __dynamic_cast are visible in
> > libglut, but the lack of a dependency on libstdc++ means the symbols
> > are undefined.
>
> And where are the references to __dynamic_cast coming from? If someone
> can provide a simple example that reproduces the problem _with the
> current setup_ I'd be happy to investigate.
There was a test case given with the bug that I was able to reproduce. This
was with the current version of glut (3.7-17) and xlibmesa3 (4.2.1-4 and
earlier)
> libGLU.so.1 contains enough information about the shared libraries it
> needs. There _was_ some screw up which hid some of those requirements,
> but everything should be working now. Said screw up was very short
> lived and only recent (as in, last couple of weeks or so). Just using
> gcc to link your program against libGLU should be enough.
Yep, that's what I've thought all along. I am going to recompile glut
against the new xlibmesa-glu package, and close the bug; if the problem *is*
caused by some screwup somewhere, rebuilding with the new compiler against
the new GLU ought to clean everything up. (touch wood). I have never
experienced this bug, although I have been able to reproduce the results
from the example given near the end of the bug report, so I'll just harass
the original submitter to see if they still experience the bug after the
upload.
--
jaq@debian.org http://people.debian.org/~jaq
Reply to: