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

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.


Reply to: