Is it exists method to work with ROOT using Borland C++ ?
I try`d to use VC++ version but found big problem with
C++ name mangling in .dll and .lib files
Hi Alexey, AFAIK no.
If you will have success with BC makefiles, let us know.
Regards. Valeriy
++
btw, does it mean (from yours message) that BC
no t using mangling ? strange …
The reason - the name mangling is not compatible. It can be
simple shown by aply tdump.exe on BC created .obj and ROOTs .dll
In my opinion ROOT sources has not good structure - direct output
C++ class method into .dll is not good idea.
I don`t wont make full ROOT build using BC. In theory, if name
magling problem will be resolved, i think that we will can work
with any normal Win32 compiler without full build from sources.
Hi Alexey,
in theory “magling problem” can not be resolved without
recompiling all ROOT dlls with BC compiler.
Regards. Valeriy
BTW. What is bad in “direct output C++ class method into .dll”?
I agree, it can not be resolved without recompiling. 
But, in general, exist method to change ROOT sources with aim
to make .dll proc names fully compatible with other compilers.
For example it can look like WinAPI dll`s. Later, we can use
any win32 compiler. I dont know - may be exists some VC compiler
options to manipulate mangling?
Direct output C++ class method into .dll bad because it is compiler
depended. Very difficult to use such .dll elsewhere.
PS. Interesting, what mangling type used in GCC ROOT version? In spite,
i can`t download it now because have slow modem connection.
Hi Alexey,
it might surprise you, but in "GCC world"
mangling is different between different versions of compiler,
even though only “micro version” is changed.
For example, gcc 2.95 vs gcc 2.96 vs gcc 3.01 etc…
That means ROOT dll (binaries) compiled with these compilers
are not compatible.
Regards. Valeriy
++
This is one of the main disadvantages of C++ in general.
There are few ways to overcome this:
- provide binaries for each version and each compiler (ROOT way)
- use C in “C++ way”, like gdk (gnome) does it
- “COM approach” from M$
- etc … e.g. Java’s way
Ok. It seems that i found method to solve this problem.
At first, we have only one missoin goal - construct appropriate .lib file
wich map BC mangling to VС .dll (by Ordinals).
BC have IMPDEF utility wich produce .def file from .dll file and
insert demangled functions names into comments:
MangledExportFuncName @Ordinal ; ExportFuncName
If VC also have utility like IMPDEF or can produce .def file like
shown, then we can use this .def file to replace VC mangling
to BC mangling. (Possible we can partial automatize this)
Next, IMPLIB make .lib file from .def . Next we can use this .lib
to link ROOT in BC projects.
Ok. It seems that I found method to solve this problem.
At first, we have only one mission goal - construct appropriate .lib file
which map BC mangling to VС .dll (by Ordinals).
BC have IMPDEF utility which produce .def file from .dll file and
insert demangled functions names into comments:
MangledExportFuncName @Ordinal ; ExportFuncName
If VC also have utility like IMPDEF or can produce .def file like
shown, then we can use this .def file to replace VC mangling
to BC mangling. (Possible we can partial automatize this)
Next, IMPLIB make .lib file from .def . Next we can use this .lib
to link ROOT in BC projects.
Hi Alexey,
interesting …
Could you keep me informed about progress?
Thanks. Regards. Valeriy
I want try to make this. Unfortunaly I have not VC and ROOT
sources. But I need only VC .def files or demangling table. If
anyone help to get it…
Alexey,
you’ve got mail (check the link on top of this page, next to the log out link - you didn’t submit your email address when registering). I can get you the .def and mangled -> demangled symbol names for the exports of all libs.
Axel.
it’s OK
Let me call your attention
ROOT is shipped a its own utility to create “DEF” file.
I thhink it should work for Borland as soon as Borland object files are ion COFF format.
Check $ROOTSYS/build/win/bindexplib directory
could you do what you do?
Ok. Now I have demangling table. Thanks to Axel.
I found new problem - all VC class method has “thiscall” calling
convention. BC++ can`t generate such call. Therefore we need
to write some stub code to generate method call. I wil try to
write dll with export table containing all ROOT method with
BC mangling style(with _stdcall calling). Every exported name will
be point to a small asm function which only execute POP ECX
and then call ROOT dll.
There are same an other unsolved questions:
- RTTI compatibility. (For example, using dynamic_cast)
- Exceptions.
- VTM compatibility.
- Class members alignment.
To many ploblems. May be easy to compile ROOT from sources 
Hi Alexey,
yes, better compile root from sources. I think I remember people had that working, about 2 years ago - so it should be possible. And Cint supports Borland, too. So just give it a try - it’s far more straight forward than the wrappers you suggest. Look in the roottalk archives; there might be pointers to Borland implementations, and who was doing/using it back then.
Axel.
Hi,
If you want to test ROOT with Borland compilers, note that CINT can already
be compiled with Borland.
You will have to add the borland case in the makefile. See the config directory.
Then look at include RConfig.h,
and class TWinNtSystem.
Let us know if you are planning to start this exercise.
Rene
Don’t you think one should simply recompile the entire ROOT with BC?
I expect very few correction.
At least it should be feasible to re-compile WIN32 version because BC supports WIN32 API and Qt version as well as soon as QT supprt BC.
(within CYGWIN env one needs a few corrections for $ROOTSYS/build/win
)
I tried to simple BC compile file TROOT.cxx
Some key errors:
TObject.h 147: Ambiguity between ‘ofstream’ and 'std::ofstream’
TMath.h 424: Only one of a set of overloaded functions can be "C"
TMath.h 451: Ambiguity between ‘std::sin(double)’ and ‘sin(double)’ in function TMath::Sin(double)
Does it mean that I must manual correct .h files?
Hi,
You are going to have to update the file base/inc/RConfig.h,
in particular the section:
[code]#ifdef BORLAND
define MSDOS /* Windows will always stay MSDOS */
define ANSICPP
define R__INT16
define R__BYTESWAP
#endif[/code]
In particular, try adding
Cheers,
Philippe