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

[Henri Lesourd]

Josef Weidendorfer wrote:

> > > 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.
"Most" of the compilers is not sufficient for
a reliable solution, which should *always* work.


> This is driven by the ubiquitousness of GCC, at least on
> Unix.
UNIX is not the only game in town.


> And (again AFAIK) modern commercial compilers (Intel, PGI etc) adhere to
> GCC 4, to be able link against object code produced by GCC.
>
>  
OK, thus there is perhaps hope for a real
standard somewhere in the future...


> But IMHO there is no problem to include a compiler check when loading
> a plugin...
You need to be able to capture this information in
the makefile. This is not infeasible, but still it's
one more thing to do.


> 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.
>
>  
The problem is not to distribute binary versions: it
is that the users should be able to donwnload and compile
the source code of a plugin *only*, and then be able to
load the object file inside a binary-installed TeXmacs
such as an RPM-installed one for example.


> > 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
That's what I expected ;-(...


> 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.
>  
As far as I know, e.g. under Windows, you can compile
a DLL with *ANY* compiler, and it is always supposed
to be loadeable an callable without any problems.

That's the difference with this whole ABI stuff...


> You simple cannot compile a source on linux and hope that you can use the 
> resulting object
> file e.g. with MSVS on Windows.
>
>  
I was not expecting this.


> > 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.
>
>  
Okay, then I would tend to consider it the
state of the art.


> Would this be a serious obstacle your using C++ plugins with texmacs?
> I seriously doubt this.
>
>  
Under Windows, it's annoying. But at least, if
you can test the bad configurations, then it's
quite okay.


> 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).
>
>  
That's incredible that such a thing could not be
made part of the standard !


> So nowadays, I really do not see more issues with dynamically using C++ plugin 
> code
> than with C plugin code.
>
>  
There are definitely more issues, for as I said,
you never have this problem when mixing code from
different C DLLs from different compilers, at least
under Windows (or am I wrong on this count ?).