Re: [Texmacs-dev] Re: Compiling TexMacs on OSX

[Josef Weidendorfer]

On Monday 23 June 2008, Henri Lesourd wrote:
> >When both a Texmacs binary and an independently compiled
> >plugin want to use a given class, it should be enough to
> >pass pointers between.
> >
> Not if you want to directly call the methods from
> inside the surrounding code (i.e., the one which
> loads the DLL).

Let's stay with the example for this discussion, ie. texmacs & plugin.
Makes it easier to talk about.

> > For this, you use factory methods
> >in the plugin, and the created objects can be used in the
> >texmacs binary without any need for recompilation.
> >
> It seems to amount to the fact that any direct
> method call should happen inside the plugin code,
> thus it amounts to the need of exporting the C++
> methods thru a C API (i.e.: wrapping each one of
> the methods behind an exported C function).

This unfortunately is platform dependent. It depends on whether
shared libraries (DLLs) loaded via dlopen are added to the list
of libraries searched by the dynamic linker for regular symbol
resolution. AFAIK, you can not rely on it.

However, this is also true for C functions: to be reliable, all
direct calls have to be via function pointers, be it pointers of C
functions returned by dlsym (after dlopen), or via C++ V-tables.

> >E.g. when texmacs defines a C++ class Button, the plugin is
> >free to derive from this class and define a MySuperButton,
> >and can pass such objects to the texmacs binary via a factory
> >method. As long as texmacs is only storing the object pointer
> >or calling methods from the base class Button, all goes well.
>
> It seems to me that this technique would only work
> if you use the same compiler for compiling TeXmacs
> and the DLL.

Most compilers for a given platform adhere to a defacto standard
today. This is driven by the ubiquitousness of GCC, at least on
Unix. As there is no real C++ ABI standard, in the past, GCC changed
its ABI even between its own versions.

So e.g. for texmacs compiled for Linux/x86, you probably have 2 defacto
C++ ABIs: One adhering to GCC 4 versions, and one for GCC 3.x, x>=3
(AFAIK, GCC 3.0/3.1/3.2 each had their own ABI, but these should be
considered obsololete).
And (again AFAIK) modern commercial compilers (Intel, PGI etc) adhere to
GCC 4, to be able link against object code produced by GCC.

But IMHO there is no problem to include a compiler check when loading
a plugin... However, if someone wants to distribute binary versions of his
texmacs plugin, he has to provide plugins for GCC3 and GCC4. But he already
has the burden to provide separate versions for Linux/x86, Linux/x86-64,
Windows/x86 etc.

> Or am I wrong here ? How can you have a method call
> using the dispatch of the compiler A, while having
> the vtables and the body of the method using the
> dispatch technique of the compiler B ?

Yes, the compilers have to agree on the layout of vtables (and you should do
a runtime check when loading a C++ plugin to keep texmacs from arbitrarly 
crashing).

But the compilers also have to agree on parameter passing convention, object
file layout (ELF/PE/COFF), 32 vs. 64bit architecture and so on. The latter 
dependencies
are also true for C functions.
You simple cannot compile a source on linux and hope that you can use the 
resulting object
file e.g. with MSVS on Windows.

> >No. For this, you have to use _one single_ C function which
> >can be searched for in dl_open. This C function can
> >return a function pointer to a C++ factory method, which itself
> >can pass created C++ objects around.
> >
> >By the way, this is also the method used by Qt itself for its
> >plugins. But it is really simple to implement, and there is no
> >need to use Qt plugins for this. texmacs itself does not
> >need to be linked with Qt.
> >
> >  
> >
> How do you do this with compilers which do not
> generate compatible method dispatch code ?

You do not do it at all. When the user wants to load a plugin compiled with
an incompatible compiler, you give an error message.
Again, Qt does it the same.

Would this be a serious obstacle your using C++ plugins with texmacs?
I seriously doubt this.

> Is there a standard for this (even if it is
> only de-facto) ?

See above.

The C++ ABI compatibility of a compiler to other compilers should be mentioned
in the documentation of the compiler (e.g. for Intel compiler something like
"can be used with C++ libraries provided with Linux distributions X, Y, and Z": 
it
implicitly talks about the C++ ABI compatibility to the GCC version used in 
given
distributions).

And yes, as your quote from above says: for a lot of platforms, there is no C++ 
ABI which
all compilers adhere to. I even do not know exactly which standard institution 
should
be responsible for this. E.g., is the "Linux/x86/ELF" C ABI "standard" not 
derived
historically from some SVR4 implementation, and documented by some Redhat 
document?
(this smells like a "de-facto standard", too).

So nowadays, I really do not see more issues with dynamically using C++ plugin 
code
than with C plugin code. Even more so when both sides (texmacs & the plugin) 
internally
use C++ anyway.

Cheers,
Josef