I am trying to rebuild CINT 5.15.174 using the Borland Compiler but I am getting the following unresolved externals. I read somewhere about someone else having a similar problem and the solution was to download an updated Microsoft makefile from the VCS. However that would probably not solve the issue using Borland C compiler.
Does anyone have any ideas of how to resolve this issue or should I go back to an earlier version such as 5.15.173 ??
You are missing the linking against the src/bc_*.cxx files.
You may want to try cint 5.17/00 or the head of the svn trunk instead.
Cheers,
Philippe.[/quote]
Hello Philippe,
Where do I find this bit about the missing linking ?? Is it in the make files ??
Also how do I access cint 5.17 and what commands do I need to invoke to retrieve it ??
Also the other issue is why is there a bc_exec.cxx file (which defines G__exec_bytecode function) but no corresponding object file. How does it ever get linked into the main project ??
I can’t work out why it all compiles OK in 5.15.153 but not in 5.15.174.
[quote]Where do I find this bit about the missing linking ?? Is it in the make files ?? [/quote]Yes, it would be in one of the CINT makefiles.
[quote]Also the other issue is why is there a bc_exec.cxx file (which defines G__exec_bytecode function) but no corresponding object file. How does it ever get linked into the main project ?? [/quote]This is the issue . The makefile is ‘forgetting’ to compile and link this file.
or you can also download the trunk:
svn http://root.cern.ch/svn/root/trunk/cint
Cheers,
Philippe.
PS. Can you remind me where you downloaded 5.15.174 from?
Out of curiosity what made you chose to use the Borland compiler (which seems old)? [Note for example that Microsoft is currently give out for free their latest C++ compiler).
I am not familiar with the Borland compiler. To investigate the problem I would first look at the content of C:\Program Files\Borland\CBuilder5\Include\stdlib.h around the lines 434 and 505. (The message is odd, especially since this is a system header … I suspect that this might be due to some mis-placed #define(s)).
Out of curiosity what made you chose to use the Borland compiler (which seems old)? [Note for example that Microsoft is currently give out for free their latest C++ compiler).
I am not familiar with the Borland compiler. To investigate the problem I would first look at the content of C:\Program Files\Borland\CBuilder5\Include\stdlib.h around the lines 434 and 505. (The message is odd, especially since this is a system header … I suspect that this might be due to some mis-placed #define(s)).
Cheers,
Philippe.[/quote]
I’m using the Borland compiler because I have developed an app with it and its Codeguard debugger has detected some resource leakage and mismatch problems with the earlier Cint code so I am trying to see if this is fixed in the later versions of Cint. Without codeguard the resource leakage problems may go undetected and course other side effects.
With regards to the compiler messages I have made some headway. The problem with compiling the cxx files can be fixed if I include the stdlib.h header as the first line of code before the other includes. In fact each cxx file appears to need this change in order to compile properly. I have built the whole project and CINT seems to work. However makecint seems to cause an exception error.
I have got it going again but I am still having resource mismatch problems.
If I declare the following class in UserMain.h and use makecint to add it to the dictionary.
class TestClass {
public:
int X;
TestClass();
TestClass(int _X);
TestClass operator=(TestClass &_J);
~TestClass();
};
extern "C" TestClass foo;[/code]
And the member functions are declared in my app as follows.
[code]TestClass::TestClass()
{
X=0;
}
TestClass::TestClass(int _X)
{
X=_X;
}
TestClass TestClass::operator=(TestClass &_J)
{
X=_J.X;
return(*this);
}
TestClass::~TestClass()
{
X=0;
}[/code]
If I access the external object in a script and assign a value to it then I get a resource mismatch which is caused by a temporary object being created with new and destroyed with free() instead of delete.
[code]void Test(void)
{
foo=TestClass(1);
}
We corrected a similar sounding problem in the svn head of CINT.
If you were able to get CodeGuard to give you more information (i.e. at the least the name of the function), I would be able to cross-check that this is the same problem. (I am guessing you need to build in ‘debug’ mode to see more information).
We corrected a similar sounding problem in the svn head of CINT.
If you were able to get CodeGuard to give you more information (i.e. at the least the name of the function), I would be able to cross-check that this is the same problem. (I am guessing you need to build in ‘debug’ mode to see more information).
Cheers,
Philippe.[/quote]
Actually I’d already tried that but the debugger seemed to be landing in another part so I modded the makefile generated by makecint.exe to include debugging information for all of the G__UserMain files and it has landed the debugger at the call to free() in G__cpp_UserMain.cpp.
[quote]Do I use cygwin ?? [/quote]Yes . We use cygwin’s make (and shell) for running the build and Microsoft’s compiler was actually doing the compilation.
I would like to focus on getting 5.17.00 going using the borland compiler and then I can try the later versions of CINT. So far I have had no luck with any other version except 5.15.153
Looking at the make file settings for the borland compiler on earlier versions could you suggest what I need to add to the configuration file ??
Also once I have the configuration file what is the command to build cint from cygwin ??
To build, you need to do:configure
make
This will ‘guess’ the platform and then build.
To upgrade to using borland, you will need to edit the file named configure add the necessary stuff (see below ) for borland and do:configure --arch=borland
make(See also configure --help).
In configure you will to
edit the ARCHS variable to ‘borland’
creation a function named config_borland whose content would/should be similar to the content of config_msvc7
Regarding the configuration file, which variables are needed and what are the definitions of them ?? I can sort of figure out a few of the obvious ones but maybe you can throw some light on the rest of them. For example COUT and COUTEXE ??
see the beginning of configure: “Lines demonstrating the use of the available variables”. COUT is the compiler compilation unit output filename flag, usually -o. COUTEXE is the linker binary output flag, for GCC still -o, but for MSVC it’s different. You will need the exported variables (referenced by the EXPORTS variable) that are defined in the MSVC section if you build on Windows.
. The makefile is ‘forgetting’ to compile and link this file.
. We use cygwin’s make (and shell) for running the build and Microsoft’s compiler was actually doing the compilation.