Re: libgl1 vs C++ transition, round 2
On Mon, Feb 03, 2003 at 07:03:01PM +1100, Jamie Wilkinson wrote:
> > > Er, okay, let me get this straight: If a program or library (written
> > > totally in C) links against libGLU, then it must link against
> > > libstdc++ too?
> >
> > That's right.
>
> 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.
> > 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.
> And here's the contradiction. In your first sentence (above) you
> claim "That's right." glut *should* link against stdc++. Here you
> say no. Which is it?
See above.
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.
> The problem that the reporter has is that libglut *isn't* linking
> against libstdc++, and this dependency *isn't* being noticed by the
> dynamic linker.
You mean libGLU.
> This is kinda the core of my point; I'm reluctant to link my library
> to libstdc++ because libglut itself doesn't need it. And so:
>
> > > b) the linker (either ld, or the dynamic linker, or both) is broken.
> >
> > I don't know where that follows from.
>
> Thus, if the dynamic linker can't cope that libglut doesn't link
> against libstdc++ (because it doesn't need it) then there's something
> wrong with either the dynamic linker (not looking at the dependency
> tree), or the compile-time linker (linking in all the libraries
> dependencies and their dependencies).
Well, like I have said, there was a screw up at some point. I noticed
it recently when looking thru the build logs of mesa. AFAICS it should
not have affected older versions of the packages, only the ones
corresponding to Mesa 5. It doesn't affect XFree86's versions which is
what most people use.
> I apologise that you've had to be so verbose on the matter. I
> understand what you have done to GLU, I just want to know what effect
> this will have on glut and in particular this annoying bug that I
> have never experienced (although I can replicate the test given).
Looking at the bug... which libGLU are we talking about here? I might
be wrong and the aforementioned screw up might have been present for
longer than I thought. Or the same problem might be present in
XFree86's, but somehow I doubt it, it would have been noticed by more
people and sooner.
--
Marcelo
Reply to: