Re: libgl1 vs C++ transition, round 2
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.
> That seems totally broken to me.
Why?
> 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?)
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.
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.
> 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 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.
> b) the linker (either ld, or the dynamic linker, or both) is broken.
I don't know where that follows from.
> 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.
--
Marcelo
Reply to: