Henri Lesourd wrote:
Abdelrazak Younes wrote:
Henri Lesourd wrote:
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.
No, I think you can probe the ABI of the dll at runtime.
Wow ! How ?
By stealing Qt's method :-) Or like Joseph recommended by asking the DLL
to identify itself with a string. This string would contain information
such as the compiler, the platform, etc and would be generated
automatically at compile time with #ifdef.
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.
I don't think this is as easy as that, see below.
In case of C DLLs under Windows, I never heard about any
inter-compiler compatibility problems, ever.
As I said, I think the problems can be tricky and I experienced many
times the so called 'dll hell'. I am not an expert so please take what
say with a grain of salt.
Let's take a C toolkit, GTK, and imagine that TexMacs was compiled with
MSVC7 using a MSVC7 compiled GTK. TeXMacs will thus use the msvcr80 C
runtime. Imagine now that plugin A is compiled with Mingw's gcc and
using a gcc compiled GTK. This plugin will thus use and need msvcrt. At
this point, imagine that the plugin exchange a GTK object with
TeXmacs... can't you see the beginning of problems?
Abdel.
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
