[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Re: Compiling TexMacs on OSX
From: |
Henri Lesourd |
Subject: |
Re: [Texmacs-dev] Re: Compiling TexMacs on OSX |
Date: |
Mon, 23 Jun 2008 16:33:06 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 |
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 ?).
- [Texmacs-dev] Re: C++'s frustrations, (continued)
- Re: [Texmacs-dev] Re: C++'s frustrations, Vadim Konovalov, 2008/06/23
- Re: [Texmacs-dev] Re: C++'s frustrations, Henri Lesourd, 2008/06/23
- [Texmacs-dev] Re: C++'s frustrations, Abdelrazak Younes, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Josef Weidendorfer, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Josef Weidendorfer, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX,
Henri Lesourd <=
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Josef Weidendorfer, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/23