solving c++ Linkage/binary compatibility problems
Uwe Pachler
uwe.pachler@jk.uni-linz.ac.at
Tue Dec 19 02:37:00 GMT 2000
Mike Stump wrote:
>
[...]
>
> I am left wondering when you think the ERL will run. To answer that,
> lets say someone produces a program called staroffice. They have a
> binary up on their ftp server that was compiled with an older version
> of the GTK+ library than you have on your system. You download it,
> and run it. A few possibilities exist, either their program is linked
> against their older GTK+ and when you run it, there is no interaction
> with the newer GTK+ on your system, or there is some interaction with
> the newer GTK+ on your system. If there is, then this interaction
> (let's call it library resolution) must happen at runtime, no? If not
> then, then when? For the purposes of this use of the term runtime,
> I'm talking about the time that starts immediately after you hit
> return, just after you type staroffice at a shell, and the time when
> staroffice exits.
If staroffice is statically linked to GTK+ (that's what you mean in your
first example).
I'm interested in your second example: staroffice is linked dynamically
against the older GTK+, and when starting it on my system with the newer
GTK+, this library is dynamically linked against staroffice.
But to be honest, I don't think GTK+ is a good example, since it's a C
library, and the ERL wouldn't be active on C code (well, there's nothing
to do for it, since there are no classes and no dynamic method
resolution in C). However, for the following example I assume GTK+ being
a C++ library (or, assume I'm using a C++ binding like GTK-- in a
dynamic library).
ERL will 'run' (meaning resolve the extended symbol table I was talking
about in my earlier posting) when staroffice is loaded. Let's split the
lifetime of staroffice in four parts:
1) load time: the program's image is loaded into main memory and
relocated
2) library link time: The memory image's sybols are resolved against the
library.
3) program runtime
4) termination & cleanup
the ERL would only run in 2) library link time. That's why it doesn't
affect runtime. At Runtime (3), everything works as usual, like in an
ordinarily linked executable.
Cheers,
Uwe
--
Uwe Pachler
VR/Graphics Developer
ABATEC GMBH
c/o FIM, University of Linz
TNF Tower, Rm 665
Altenbergerstr. 69
4040 Linz
AUSTRIA
phone: +43 732 2468 8433
More information about the Gcc
mailing list