Re: libgl1 vs C++ transition, round 2
This one time, at band camp, Marcelo E. Magallon wrote:
>On Wed, Jan 29, 2003 at 09:47:04PM +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.
> > That seems totally broken to me.
>
> Why?
A dependency on C++ for a C only program. But you talk about this later,
so...
> > I'm currently sitting on #134262 because of this.
>
> After a cursory reading...
>
> Richard's observation is correct, but the conclusion isn't.
>
> I concur with Martin.
>
> 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.
> I can't understand this:
>
> | libglut is linked against a shared library (linked against
> | libstdc++), but doesn't explicitely link against libstdc++.
> |
> | this results in symbols like __dynamic_cast be defined in libglut.
"libglut is currently linked against a shared library (libGLU) that is
linked against libstdc++, but libglut isn't explicitly linked against
libstdc++."
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 this is wrong:
>
> | You either have to link libglut using g++ (which appends -lstdc++ as
> | a library), or append -lstdc++ to the link libraries. The former
> | method is preferred.
> |
> | Each application, which links against libgnut has to do the same.
>
> I find it hard to beleive that this comes from Matthias.
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?
> > My reasoning is that glut is written in C and for ages now has been
> > compiled with just gcc, and hasn't linked against libstdc++, and I've
> > had no problems with it. I don't see why I should be forced to
> > explicitly link glut and any programs that use glut against
> > libstdc++. It's not very intuitive.
>
> Your application doesn't have to link against libstdc++, libGLU does.
> It's in its list of depencencies. The dynamic linker will notice that
> and map libstdc++ into your application's space.
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.
> The othe issue someone rised, linking multiple libstdc++ libraries to
> te same binary... take as an example dynamic_cast. In libstdc++.so.5
> it's a versioned symbol and in libstdc++.so.3 it's not. Symbol
> resolution is sensitive to the order in which the required libraries
> are stored in the object, that's one of the reasons for introducing
> versioned symbols. You have this situation:
>
> libGLU.so.1
> libstdc++.so.5
> libFoo.so.1
> libstdc++.so.3
> libstdc++.so.3
>
> that means libGLU.so.1's dynamic_cast is resolved using
> libstdc++.so.5's because it's versioned. libFoo.so.1 wants an
> unversioned one and at this point there are two symbols in the symbol
> table, a versioned one and an unversioned one. My understanding of the
> code is that the _unversioned_ symbol will be used as global definition
> so everything is ok (IOW, the effect is that requests for unversioned
> symbols get resolved by unversioned symbols). Furthermore, if you are
> resolving an _unversioned_ symbol and all the definitions are
> _versioned_, the oldest version will be used.
>
> You have a problem if and only if you load two libstdc++ libraries and
> both have unversioned symbols. In that case, the loading order
> matters which is -- as far as I can see -- the problem in the OP's
> case.
>
> > a) GLU is broken and needs to have its ABI fixed so that programs
> > don't need to link against libstdc++ when they themselves are not
> > written in C++.
>
> It is aesthetically unpleasant to have a C program link to the standard
> C++ library. Aesthetics aside, it's ok.
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).
Now I'm not familiar with C++ linking, so I've been speculating the whole
time and it's quite probable that I'm making an arse of myself.
> > I concede that there may be one other source, and that is my naivety
> > that a C API should in fact behave like one, and I would dearly love
> > someone to explain and/or resolve this problem.
>
> That's the reason why I have spelled this out several times already:
> libGLU exports C functions and nothing else. The C++ functions are
> marked as private -- the package that gets this (hopefully) right is
> sitting in incoming awaiting for ftp-master approval.
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).
--
jaq@debian.org http://people.debian.org/~jaq
Reply to: