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

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,

> > 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

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

> 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

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: