Building cint on windows

[Severin Ecker-2]

Hi,

I'm trying to build a statically linked version of cint on windows
(using msvc8).
I can successfully build the whole root package but this only leaves me
with a dynamically linked version.
I tried ./configure and make for the cint package (because i found the
LINKSTATIC option which is probably what i want) but make fails due to a
'missing rule for target "cint/src/v6_winnt.obj" error.
I found a reference to v6_winnt.cxx in the README file but haven't found
that file in the package nor has it been genereted automagically by some
of the tools and scripts that are running during the build.

can anyone point me into the direction what's going on and what
settings... i probably missed specifically needed for cint only builds?

thanks in advance.
cheers,
severin

[Axel Naumann]

Hi Severin,

I have fixed a few issues with the standalone CINT build on windows
(./configure && make). "make static" still fails because of an issue with the
dictionary for CINT itself; we are working on solving that. We (Philippe or I)
will let you know when it's done!

Cheers, Axel.

On 2008-12-16 13:46, Severin Ecker wrote:

> Hi,
>
> I'm trying to build a statically linked version of cint on windows
> (using msvc8).
> I can successfully build the whole root package but this only leaves me
> with a dynamically linked version.
> I tried ./configure and make for the cint package (because i found the
> LINKSTATIC option which is probably what i want) but make fails due to a
> 'missing rule for target "cint/src/v6_winnt.obj" error.
> I found a reference to v6_winnt.cxx in the README file but haven't found
> that file in the package nor has it been genereted automagically by some
> of the tools and scripts that are running during the build.
>
> can anyone point me into the direction what's going on and what
> settings... i probably missed specifically needed for cint only builds?
>
> thanks in advance.
> cheers,
> severin
>
>

[Severin Ecker-2]

Hi Axel,

thanks for the quick reply.
hmm, could you be a bit more specific what the issue with the dictionary
is, because I've changed a few things and I've managed to create a
static library and link the cint tool against it. A quick test showed
that it seems to work but I haven't done intensive testing so I'm not
sure if there are some things that are then known to not work.

cheers,
severin


Axel Naumann wrote:

> Hi Severin,
>
> I have fixed a few issues with the standalone CINT build on windows
> (./configure && make). "make static" still fails because of an issue with the
> dictionary for CINT itself; we are working on solving that. We (Philippe or I)
> will let you know when it's done!
>
> Cheers, Axel.
>
> On 2008-12-16 13:46, Severin Ecker wrote:
>  
>> Hi,
>>
>> I'm trying to build a statically linked version of cint on windows
>> (using msvc8).
>> I can successfully build the whole root package but this only leaves me
>> with a dynamically linked version.
>> I tried ./configure and make for the cint package (because i found the
>> LINKSTATIC option which is probably what i want) but make fails due to a
>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>> I found a reference to v6_winnt.cxx in the README file but haven't found
>> that file in the package nor has it been genereted automagically by some
>> of the tools and scripts that are running during the build.
>>
>> can anyone point me into the direction what's going on and what
>> settings... i probably missed specifically needed for cint only builds?
>>
>> thanks in advance.
>> cheers,
>> severin
>>
>>
>>    

[Axel Naumann]

Hi Severin,

> could you be a bit more specific what the issue with the dictionary is

I get
cd cint/src/dict && LD_LIBRARY_PATH=../../../lib:$LD_LIBRARY_PATH
DYLD_LIBRARY_PATH=../lib:.:$DYLD_LIBRARY_PATH\
          ../../../bin/cint_tmp.exe -nApiif.cxx -NG__API -Z0 -D__MAKECINT__ \
          -c-1 -I../../inc -I../../../reflex/inc -I.. Api.h
Error: cannot open file "math.h"  ../../inc\G__ci.h(474)
!!!Removing Apiif.cxx Apiif.h !!!
make: *** [cint/src/dict/Apiif.cxx] Error 1

> static library and link the cint tool against it. A quick test showed
> that it seems to work but I haven't done intensive testing so I'm not
> sure if there are some things that are then known to not work.

good! Did you checkout the latest SVN version of which version are we talking
about?

Cheers, Axel.

On 2008-12-16 16:50, Severin Ecker wrote:

> Hi Axel,
>
> thanks for the quick reply.
> hmm, could you be a bit more specific what the issue with the dictionary
> is, because I've changed a few things and I've managed to create a
> static library and link the cint tool against it. A quick test showed
> that it seems to work but I haven't done intensive testing so I'm not
> sure if there are some things that are then known to not work.
>
> cheers,
> severin
>
>
> Axel Naumann wrote:
>> Hi Severin,
>>
>> I have fixed a few issues with the standalone CINT build on windows
>> (./configure && make). "make static" still fails because of an issue
>> with the
>> dictionary for CINT itself; we are working on solving that. We
>> (Philippe or I)
>> will let you know when it's done!
>>
>> Cheers, Axel.
>>
>> On 2008-12-16 13:46, Severin Ecker wrote:
>>  
>>> Hi,
>>>
>>> I'm trying to build a statically linked version of cint on windows
>>> (using msvc8).
>>> I can successfully build the whole root package but this only leaves me
>>> with a dynamically linked version.
>>> I tried ./configure and make for the cint package (because i found the
>>> LINKSTATIC option which is probably what i want) but make fails due to a
>>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>>> I found a reference to v6_winnt.cxx in the README file but haven't found
>>> that file in the package nor has it been genereted automagically by some
>>> of the tools and scripts that are running during the build.
>>>
>>> can anyone point me into the direction what's going on and what
>>> settings... i probably missed specifically needed for cint only builds?
>>>
>>> thanks in advance.
>>> cheers,
>>> severin
>>>
>>>
>>>    
>
>

[Severin Ecker-2]

Hi Axel,

I have used the latest development release (5.12/06) and changed the
makefile there. so this was a misunderstanding.
Using the SVN version i did get the same error once. But I've compiled
the shared version just to test whether a version that i did compile
myself worked or not, and since then i can't reproduce the problem with
the static linkage (i did clean the build, reran ./configure but still
the build works ;/ )
Still I'll keep looking into it and let you know if i find the problem.

cheers,
severin


Axel Naumann wrote:

> Hi Severin,
>
>  
>> could you be a bit more specific what the issue with the dictionary is
>>    
>
> I get
> cd cint/src/dict && LD_LIBRARY_PATH=../../../lib:$LD_LIBRARY_PATH
> DYLD_LIBRARY_PATH=../lib:.:$DYLD_LIBRARY_PATH\
>           ../../../bin/cint_tmp.exe -nApiif.cxx -NG__API -Z0 -D__MAKECINT__ \
>           -c-1 -I../../inc -I../../../reflex/inc -I.. Api.h
> Error: cannot open file "math.h"  ../../inc\G__ci.h(474)
> !!!Removing Apiif.cxx Apiif.h !!!
> make: *** [cint/src/dict/Apiif.cxx] Error 1
>
>  
>> static library and link the cint tool against it. A quick test showed
>> that it seems to work but I haven't done intensive testing so I'm not
>> sure if there are some things that are then known to not work.
>>    
>
> good! Did you checkout the latest SVN version of which version are we talking
> about?
>
> Cheers, Axel.
>
> On 2008-12-16 16:50, Severin Ecker wrote:
>  
>> Hi Axel,
>>
>> thanks for the quick reply.
>> hmm, could you be a bit more specific what the issue with the dictionary
>> is, because I've changed a few things and I've managed to create a
>> static library and link the cint tool against it. A quick test showed
>> that it seems to work but I haven't done intensive testing so I'm not
>> sure if there are some things that are then known to not work.
>>
>> cheers,
>> severin
>>
>>
>> Axel Naumann wrote:
>>    
>>> Hi Severin,
>>>
>>> I have fixed a few issues with the standalone CINT build on windows
>>> (./configure && make). "make static" still fails because of an issue
>>> with the
>>> dictionary for CINT itself; we are working on solving that. We
>>> (Philippe or I)
>>> will let you know when it's done!
>>>
>>> Cheers, Axel.
>>>
>>> On 2008-12-16 13:46, Severin Ecker wrote:
>>>  
>>>      
>>>> Hi,
>>>>
>>>> I'm trying to build a statically linked version of cint on windows
>>>> (using msvc8).
>>>> I can successfully build the whole root package but this only leaves me
>>>> with a dynamically linked version.
>>>> I tried ./configure and make for the cint package (because i found the
>>>> LINKSTATIC option which is probably what i want) but make fails due to a
>>>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>>>> I found a reference to v6_winnt.cxx in the README file but haven't found
>>>> that file in the package nor has it been genereted automagically by some
>>>> of the tools and scripts that are running during the build.
>>>>
>>>> can anyone point me into the direction what's going on and what
>>>> settings... i probably missed specifically needed for cint only builds?
>>>>
>>>> thanks in advance.
>>>> cheers,
>>>> severin
>>>>        

[Philippe Canal]

Hi,

The windows build on the head of the SVN trunk is now fully functional.

Cheers,
Philippe.

Severin Ecker wrote:

> Hi Axel,
>
> I have used the latest development release (5.12/06) and changed the
> makefile there. so this was a misunderstanding.
> Using the SVN version i did get the same error once. But I've compiled
> the shared version just to test whether a version that i did compile
> myself worked or not, and since then i can't reproduce the problem
> with the static linkage (i did clean the build, reran ./configure but
> still the build works ;/ )
> Still I'll keep looking into it and let you know if i find the problem.
>
> cheers,
> severin
>
>
> Axel Naumann wrote:
>> Hi Severin,
>>
>>  
>>> could you be a bit more specific what the issue with the dictionary is
>>>    
>>
>> I get
>> cd cint/src/dict && LD_LIBRARY_PATH=../../../lib:$LD_LIBRARY_PATH
>> DYLD_LIBRARY_PATH=../lib:.:$DYLD_LIBRARY_PATH\
>>           ../../../bin/cint_tmp.exe -nApiif.cxx -NG__API -Z0
>> -D__MAKECINT__ \
>>           -c-1 -I../../inc -I../../../reflex/inc -I.. Api.h
>> Error: cannot open file "math.h"  ../../inc\G__ci.h(474)
>> !!!Removing Apiif.cxx Apiif.h !!!
>> make: *** [cint/src/dict/Apiif.cxx] Error 1
>>
>>  
>>> static library and link the cint tool against it. A quick test showed
>>> that it seems to work but I haven't done intensive testing so I'm not
>>> sure if there are some things that are then known to not work.
>>>    
>>
>> good! Did you checkout the latest SVN version of which version are we
>> talking
>> about?
>>
>> Cheers, Axel.
>>
>> On 2008-12-16 16:50, Severin Ecker wrote:
>>  
>>> Hi Axel,
>>>
>>> thanks for the quick reply.
>>> hmm, could you be a bit more specific what the issue with the
>>> dictionary
>>> is, because I've changed a few things and I've managed to create a
>>> static library and link the cint tool against it. A quick test showed
>>> that it seems to work but I haven't done intensive testing so I'm not
>>> sure if there are some things that are then known to not work.
>>>
>>> cheers,
>>> severin
>>>
>>>
>>> Axel Naumann wrote:
>>>    
>>>> Hi Severin,
>>>>
>>>> I have fixed a few issues with the standalone CINT build on windows
>>>> (./configure && make). "make static" still fails because of an issue
>>>> with the
>>>> dictionary for CINT itself; we are working on solving that. We
>>>> (Philippe or I)
>>>> will let you know when it's done!
>>>>
>>>> Cheers, Axel.
>>>>
>>>> On 2008-12-16 13:46, Severin Ecker wrote:
>>>>  
>>>>      
>>>>> Hi,
>>>>>
>>>>> I'm trying to build a statically linked version of cint on windows
>>>>> (using msvc8).
>>>>> I can successfully build the whole root package but this only
>>>>> leaves me
>>>>> with a dynamically linked version.
>>>>> I tried ./configure and make for the cint package (because i found
>>>>> the
>>>>> LINKSTATIC option which is probably what i want) but make fails
>>>>> due to a
>>>>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>>>>> I found a reference to v6_winnt.cxx in the README file but haven't
>>>>> found
>>>>> that file in the package nor has it been genereted automagically
>>>>> by some
>>>>> of the tools and scripts that are running during the build.
>>>>>
>>>>> can anyone point me into the direction what's going on and what
>>>>> settings... i probably missed specifically needed for cint only
>>>>> builds?
>>>>>
>>>>> thanks in advance.
>>>>> cheers,
>>>>> severin
>>>>>        
>

[Severin Ecker-2]

Hi again,

First of all, thanks for your efforts they're greatly appreciated.
configure and make now indeed work smoothly and correct but there's
still another problem (at least for me).
I'm not sure which compiler you're using so:
I have msvc8 (--> msvs 2005) here on my machine and the build works
fine, but something's greatly amiss nonetheless.
Whenever i try to use cint with anything 'more complicated' than printf  
i get a segmentation  violation (signal(11)).  I think this has
something to do with #includes, because the same happens if i use
makecint (or cint -c-1) and my header has any #include directive in
there. so, with my own compiled cint (whether it's statically or
dynamically linked doesn't matter) I can't interpret and 'useful' code
(e.g.: the simple examples in the demo directory don't work for the same
reason).

Did you come across that problem?
If you need anymore details, just shout.

cheers,
severin



Philippe Canal wrote:

> Hi,
>
> The windows build on the head of the SVN trunk is now fully functional.
>
> Cheers,
> Philippe.
>
> Severin Ecker wrote:
>> Hi Axel,
>>
>> I have used the latest development release (5.12/06) and changed the
>> makefile there. so this was a misunderstanding.
>> Using the SVN version i did get the same error once. But I've
>> compiled the shared version just to test whether a version that i did
>> compile myself worked or not, and since then i can't reproduce the
>> problem with the static linkage (i did clean the build, reran
>> ./configure but still the build works ;/ )
>> Still I'll keep looking into it and let you know if i find the problem.
>>
>> cheers,
>> severin
>>
>>
>> Axel Naumann wrote:
>>> Hi Severin,
>>>
>>>  
>>>> could you be a bit more specific what the issue with the dictionary is
>>>>    
>>>
>>> I get
>>> cd cint/src/dict && LD_LIBRARY_PATH=../../../lib:$LD_LIBRARY_PATH
>>> DYLD_LIBRARY_PATH=../lib:.:$DYLD_LIBRARY_PATH\
>>>           ../../../bin/cint_tmp.exe -nApiif.cxx -NG__API -Z0
>>> -D__MAKECINT__ \
>>>           -c-1 -I../../inc -I../../../reflex/inc -I.. Api.h
>>> Error: cannot open file "math.h"  ../../inc\G__ci.h(474)
>>> !!!Removing Apiif.cxx Apiif.h !!!
>>> make: *** [cint/src/dict/Apiif.cxx] Error 1
>>>
>>>  
>>>> static library and link the cint tool against it. A quick test showed
>>>> that it seems to work but I haven't done intensive testing so I'm not
>>>> sure if there are some things that are then known to not work.
>>>>    
>>>
>>> good! Did you checkout the latest SVN version of which version are
>>> we talking
>>> about?
>>>
>>> Cheers, Axel.
>>>
>>> On 2008-12-16 16:50, Severin Ecker wrote:
>>>  
>>>> Hi Axel,
>>>>
>>>> thanks for the quick reply.
>>>> hmm, could you be a bit more specific what the issue with the
>>>> dictionary
>>>> is, because I've changed a few things and I've managed to create a
>>>> static library and link the cint tool against it. A quick test showed
>>>> that it seems to work but I haven't done intensive testing so I'm not
>>>> sure if there are some things that are then known to not work.
>>>>
>>>> cheers,
>>>> severin
>>>>
>>>>
>>>> Axel Naumann wrote:
>>>>  
>>>>> Hi Severin,
>>>>>
>>>>> I have fixed a few issues with the standalone CINT build on windows
>>>>> (./configure && make). "make static" still fails because of an issue
>>>>> with the
>>>>> dictionary for CINT itself; we are working on solving that. We
>>>>> (Philippe or I)
>>>>> will let you know when it's done!
>>>>>
>>>>> Cheers, Axel.
>>>>>
>>>>> On 2008-12-16 13:46, Severin Ecker wrote:
>>>>>  
>>>>>    
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to build a statically linked version of cint on windows
>>>>>> (using msvc8).
>>>>>> I can successfully build the whole root package but this only
>>>>>> leaves me
>>>>>> with a dynamically linked version.
>>>>>> I tried ./configure and make for the cint package (because i
>>>>>> found the
>>>>>> LINKSTATIC option which is probably what i want) but make fails
>>>>>> due to a
>>>>>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>>>>>> I found a reference to v6_winnt.cxx in the README file but
>>>>>> haven't found
>>>>>> that file in the package nor has it been genereted automagically
>>>>>> by some
>>>>>> of the tools and scripts that are running during the build.
>>>>>>
>>>>>> can anyone point me into the direction what's going on and what
>>>>>> settings... i probably missed specifically needed for cint only
>>>>>> builds?
>>>>>>
>>>>>> thanks in advance.
>>>>>> cheers,
>>>>>> severin

[Philippe Canal]

Hi,

The library (.dll) are not  created in $CINTSYSDIR/bin as  one  would
expect on windows.
To work around the problem (which should be solve in  the next couple of
days), you should
only have to add $CINTSYSDIR/lib  to your PATH environment variable.

Cheers,
Philippe

Severin Ecker wrote:

> Hi again,
>
> First of all, thanks for your efforts they're greatly appreciated.
> configure and make now indeed work smoothly and correct but there's
> still another problem (at least for me).
> I'm not sure which compiler you're using so:
> I have msvc8 (--> msvs 2005) here on my machine and the build works
> fine, but something's greatly amiss nonetheless.
> Whenever i try to use cint with anything 'more complicated' than
> printf  i get a segmentation  violation (signal(11)).  I think this
> has something to do with #includes, because the same happens if i use
> makecint (or cint -c-1) and my header has any #include directive in
> there. so, with my own compiled cint (whether it's statically or
> dynamically linked doesn't matter) I can't interpret and 'useful' code
> (e.g.: the simple examples in the demo directory don't work for the
> same reason).
>
> Did you come across that problem?
> If you need anymore details, just shout.
>
> cheers,
> severin
>
>
>
> Philippe Canal wrote:
>> Hi,
>>
>> The windows build on the head of the SVN trunk is now fully functional.
>>
>> Cheers,
>> Philippe.
>>
>> Severin Ecker wrote:
>>> Hi Axel,
>>>
>>> I have used the latest development release (5.12/06) and changed the
>>> makefile there. so this was a misunderstanding.
>>> Using the SVN version i did get the same error once. But I've
>>> compiled the shared version just to test whether a version that i
>>> did compile myself worked or not, and since then i can't reproduce
>>> the problem with the static linkage (i did clean the build, reran
>>> ./configure but still the build works ;/ )
>>> Still I'll keep looking into it and let you know if i find the problem.
>>>
>>> cheers,
>>> severin
>>>
>>>
>>> Axel Naumann wrote:
>>>> Hi Severin,
>>>>
>>>>  
>>>>> could you be a bit more specific what the issue with the
>>>>> dictionary is
>>>>>    
>>>>
>>>> I get
>>>> cd cint/src/dict && LD_LIBRARY_PATH=../../../lib:$LD_LIBRARY_PATH
>>>> DYLD_LIBRARY_PATH=../lib:.:$DYLD_LIBRARY_PATH\
>>>>           ../../../bin/cint_tmp.exe -nApiif.cxx -NG__API -Z0
>>>> -D__MAKECINT__ \
>>>>           -c-1 -I../../inc -I../../../reflex/inc -I.. Api.h
>>>> Error: cannot open file "math.h"  ../../inc\G__ci.h(474)
>>>> !!!Removing Apiif.cxx Apiif.h !!!
>>>> make: *** [cint/src/dict/Apiif.cxx] Error 1
>>>>
>>>>  
>>>>> static library and link the cint tool against it. A quick test showed
>>>>> that it seems to work but I haven't done intensive testing so I'm not
>>>>> sure if there are some things that are then known to not work.
>>>>>    
>>>>
>>>> good! Did you checkout the latest SVN version of which version are
>>>> we talking
>>>> about?
>>>>
>>>> Cheers, Axel.
>>>>
>>>> On 2008-12-16 16:50, Severin Ecker wrote:
>>>>  
>>>>> Hi Axel,
>>>>>
>>>>> thanks for the quick reply.
>>>>> hmm, could you be a bit more specific what the issue with the
>>>>> dictionary
>>>>> is, because I've changed a few things and I've managed to create a
>>>>> static library and link the cint tool against it. A quick test showed
>>>>> that it seems to work but I haven't done intensive testing so I'm not
>>>>> sure if there are some things that are then known to not work.
>>>>>
>>>>> cheers,
>>>>> severin
>>>>>
>>>>>
>>>>> Axel Naumann wrote:
>>>>>  
>>>>>> Hi Severin,
>>>>>>
>>>>>> I have fixed a few issues with the standalone CINT build on windows
>>>>>> (./configure && make). "make static" still fails because of an issue
>>>>>> with the
>>>>>> dictionary for CINT itself; we are working on solving that. We
>>>>>> (Philippe or I)
>>>>>> will let you know when it's done!
>>>>>>
>>>>>> Cheers, Axel.
>>>>>>
>>>>>> On 2008-12-16 13:46, Severin Ecker wrote:
>>>>>>  
>>>>>>    
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to build a statically linked version of cint on windows
>>>>>>> (using msvc8).
>>>>>>> I can successfully build the whole root package but this only
>>>>>>> leaves me
>>>>>>> with a dynamically linked version.
>>>>>>> I tried ./configure and make for the cint package (because i
>>>>>>> found the
>>>>>>> LINKSTATIC option which is probably what i want) but make fails
>>>>>>> due to a
>>>>>>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>>>>>>> I found a reference to v6_winnt.cxx in the README file but
>>>>>>> haven't found
>>>>>>> that file in the package nor has it been genereted automagically
>>>>>>> by some
>>>>>>> of the tools and scripts that are running during the build.
>>>>>>>
>>>>>>> can anyone point me into the direction what's going on and what
>>>>>>> settings... i probably missed specifically needed for cint only
>>>>>>> builds?
>>>>>>>
>>>>>>> thanks in advance.
>>>>>>> cheers,
>>>>>>> severin
>

[Axel Naumann]

Hi,

libCint.dll (note the new capitalization of Cint which is now symmetric
with libReflex and libCint's use in ROOT) is now in bin/; libCint.so
stays in lib/. So setting PATH to include bin/ should be sufficient.

Cheers, Axel.

Philippe Canal wrote:

> Hi,
>
> The library (.dll) are not  created in $CINTSYSDIR/bin as  one  would
> expect on windows.
> To work around the problem (which should be solve in  the next couple of
> days), you should
> only have to add $CINTSYSDIR/lib  to your PATH environment variable.
>
> Cheers,
> Philippe
>
> Severin Ecker wrote:
>> Hi again,
>>
>> First of all, thanks for your efforts they're greatly appreciated.
>> configure and make now indeed work smoothly and correct but there's
>> still another problem (at least for me).
>> I'm not sure which compiler you're using so:
>> I have msvc8 (--> msvs 2005) here on my machine and the build works
>> fine, but something's greatly amiss nonetheless.
>> Whenever i try to use cint with anything 'more complicated' than
>> printf  i get a segmentation  violation (signal(11)).  I think this
>> has something to do with #includes, because the same happens if i use
>> makecint (or cint -c-1) and my header has any #include directive in
>> there. so, with my own compiled cint (whether it's statically or
>> dynamically linked doesn't matter) I can't interpret and 'useful' code
>> (e.g.: the simple examples in the demo directory don't work for the
>> same reason).
>>
>> Did you come across that problem?
>> If you need anymore details, just shout.
>>
>> cheers,
>> severin
>>
>>
>>
>> Philippe Canal wrote:
>>> Hi,
>>>
>>> The windows build on the head of the SVN trunk is now fully functional.
>>>
>>> Cheers,
>>> Philippe.
>>>
>>> Severin Ecker wrote:
>>>> Hi Axel,
>>>>
>>>> I have used the latest development release (5.12/06) and changed the
>>>> makefile there. so this was a misunderstanding.
>>>> Using the SVN version i did get the same error once. But I've
>>>> compiled the shared version just to test whether a version that i
>>>> did compile myself worked or not, and since then i can't reproduce
>>>> the problem with the static linkage (i did clean the build, reran
>>>> ./configure but still the build works ;/ )
>>>> Still I'll keep looking into it and let you know if i find the problem.
>>>>
>>>> cheers,
>>>> severin
>>>>
>>>>
>>>> Axel Naumann wrote:
>>>>> Hi Severin,
>>>>>
>>>>>  
>>>>>> could you be a bit more specific what the issue with the
>>>>>> dictionary is
>>>>>>    
>>>>>
>>>>> I get
>>>>> cd cint/src/dict && LD_LIBRARY_PATH=../../../lib:$LD_LIBRARY_PATH
>>>>> DYLD_LIBRARY_PATH=../lib:.:$DYLD_LIBRARY_PATH\
>>>>>           ../../../bin/cint_tmp.exe -nApiif.cxx -NG__API -Z0
>>>>> -D__MAKECINT__ \
>>>>>           -c-1 -I../../inc -I../../../reflex/inc -I.. Api.h
>>>>> Error: cannot open file "math.h"  ../../inc\G__ci.h(474)
>>>>> !!!Removing Apiif.cxx Apiif.h !!!
>>>>> make: *** [cint/src/dict/Apiif.cxx] Error 1
>>>>>
>>>>>  
>>>>>> static library and link the cint tool against it. A quick test showed
>>>>>> that it seems to work but I haven't done intensive testing so I'm not
>>>>>> sure if there are some things that are then known to not work.
>>>>>>    
>>>>>
>>>>> good! Did you checkout the latest SVN version of which version are
>>>>> we talking
>>>>> about?
>>>>>
>>>>> Cheers, Axel.
>>>>>
>>>>> On 2008-12-16 16:50, Severin Ecker wrote:
>>>>>  
>>>>>> Hi Axel,
>>>>>>
>>>>>> thanks for the quick reply.
>>>>>> hmm, could you be a bit more specific what the issue with the
>>>>>> dictionary
>>>>>> is, because I've changed a few things and I've managed to create a
>>>>>> static library and link the cint tool against it. A quick test showed
>>>>>> that it seems to work but I haven't done intensive testing so I'm not
>>>>>> sure if there are some things that are then known to not work.
>>>>>>
>>>>>> cheers,
>>>>>> severin
>>>>>>
>>>>>>
>>>>>> Axel Naumann wrote:
>>>>>>  
>>>>>>> Hi Severin,
>>>>>>>
>>>>>>> I have fixed a few issues with the standalone CINT build on windows
>>>>>>> (./configure && make). "make static" still fails because of an issue
>>>>>>> with the
>>>>>>> dictionary for CINT itself; we are working on solving that. We
>>>>>>> (Philippe or I)
>>>>>>> will let you know when it's done!
>>>>>>>
>>>>>>> Cheers, Axel.
>>>>>>>
>>>>>>> On 2008-12-16 13:46, Severin Ecker wrote:
>>>>>>>  
>>>>>>>  
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to build a statically linked version of cint on windows
>>>>>>>> (using msvc8).
>>>>>>>> I can successfully build the whole root package but this only
>>>>>>>> leaves me
>>>>>>>> with a dynamically linked version.
>>>>>>>> I tried ./configure and make for the cint package (because i
>>>>>>>> found the
>>>>>>>> LINKSTATIC option which is probably what i want) but make fails
>>>>>>>> due to a
>>>>>>>> 'missing rule for target "cint/src/v6_winnt.obj" error.
>>>>>>>> I found a reference to v6_winnt.cxx in the README file but
>>>>>>>> haven't found
>>>>>>>> that file in the package nor has it been genereted automagically
>>>>>>>> by some
>>>>>>>> of the tools and scripts that are running during the build.
>>>>>>>>
>>>>>>>> can anyone point me into the direction what's going on and what
>>>>>>>> settings... i probably missed specifically needed for cint only
>>>>>>>> builds?
>>>>>>>>
>>>>>>>> thanks in advance.
>>>>>>>> cheers,
>>>>>>>> severin
>>
>
>

[Severin Ecker-2]

hi,

just a quick question.

sample.h

extern void Log(const char* fmt, ...);
#define printf Log


does this code look suspicious to you or should i be able to run
makecint and create interpreter code? at least on my system it crashes
with some heap corruption error and i haven't found any obvious bug so
I'm wondering if this is known not to work, or it should work and just
doesn't on my system for some reason.

thanks in advance and cheers,
severin

[Philippe Canal]

Hi Severin,

I can not reproduce this problem.  (however note that printf is handled
'natively'/'specially' and thus you might have to idea this code from CINT.

Cheers,
Philippe

Severin Ecker wrote:

> hi,
>
> just a quick question.
>
> sample.h
>
> extern void Log(const char* fmt, ...);
> #define printf Log
>
>
> does this code look suspicious to you or should i be able to run
> makecint and create interpreter code? at least on my system it crashes
> with some heap corruption error and i haven't found any obvious bug so
> I'm wondering if this is known not to work, or it should work and just
> doesn't on my system for some reason.
>
> thanks in advance and cheers,
> severin
>

[Severin Ecker-2]

hi,

please find attached a patch for the problem of generated source code
including iterators only worked with _HAS_ITERATOR_DEBUGGING = 1 in VS
 >= 2005 (see mail from 15th of jan. 14:53: issues with
vector::const_iterator)

I don't have any VS7 (I guess that's _MSC_VER 1300 right?) so i'm not a
100% sure that the macro checks work for VS 7 so you might need to check
that but I'd think that the vector header hasn't changed in quite some time.

cheers,
severin


Index: cint7/lib/prec_stl/vector
===================================================================
--- cint7/lib/prec_stl/vector (revision 27194)
+++ cint7/lib/prec_stl/vector (working copy)
@@ -118,10 +118,10 @@
  typedef const_reference reference;
 
  const_iterator();
-#if (G__MSC_VER>=1310) && (G__MSC_VER<1400)
+#if (G__MSC_VER>=1310) && !_HAS_ITERATOR_DEBUGGING && !_SECURE_SCL
  //const_iterator(pointer _Ptr);
  const_iterator(T *const  _Ptr);
-#elif (G__MSC_VER>=1400)
+#elif _HAS_ITERATOR_DEBUGGING ||_SECURE_SCL
  const_iterator(T *const  _Ptr, const vector<T>* _Pvector );
 #endif
 

[Severin Ecker-2]

hi,

i was wondering if you've come to a decision yet which version of cint
will survive and receive ongoing development.

thanks in advance.

cheers,
severin

[Axel Naumann]

Hi Severin,

On 2009-02-02 11:09, Severin Ecker wrote:
> i was wondering if you've come to a decision yet which version of cint
> will survive and receive ongoing development.

Sort of. We decided to move our development focus to another project. CINT7
will still be actively developed for the next few months, but I expect that we
will continue to maintain CINT5 for the next two years at least.

So I believe that for your project (whatever it is :-) CINT5 is the way to go.

Cheers, Axel.

[Zelzer Sascha]

Hi,

I was wondering if you could elaborate a little bit more about your
plans of CINT (I saw some CINT8 and cling stuff...). Since I am
considering to introduce C++ scripting into a rather large codebase, I
would appreciate any hints about an optimal strategy of adopting CINT.
Would it be better to wait a couple of weeks/months for a newer version
or is using CINT7 or CINT5 "safe" in terms of only minimal changes on
the user side when moving to a newer CINT version.

Further, what are the main differences between CINT5 and CINT7 from a
users point of view (user meaning developer integrating CINT support
into his own libraries)?

Thanks,
Sascha
 
> Sort of. We decided to move our development focus to another project.
> CINT7
> will still be actively developed for the next few months, but I expect
> that we
> will continue to maintain CINT5 for the next two years at least.
>
> So I believe that for your project (whatever it is :-) CINT5 is the
way
> to go.
>
> Cheers, Axel.

[Axel Naumann]

Hi Sascha,

On 2009-02-03 9:51, Zelzer Sascha wrote:
> I was wondering if you could elaborate a little bit more about your
> plans of CINT (I saw some CINT8 and cling stuff...). Since I am
> considering to introduce C++ scripting into a rather large codebase, I
> would appreciate any hints about an optimal strategy of adopting CINT.
> Would it be better to wait a couple of weeks/months for a newer version
> or is using CINT7 or CINT5 "safe" in terms of only minimal changes on
> the user side when moving to a newer CINT version.

that's what I was trying to answer :-) CINT5 should be safe: I expect that we
will commit patches that you send in at least for the next two years. We will
fix bugs that you find at least for the next two years.

On the other hand moving to CINT7 would only mean minimal changes in your code
(actually I cannot think of any right now). The only changes I am aware of are
build-system related. We will ensure that patches are propagated from CINT5 to
CINT7 so you should be fine with using CINT5 for now, even if in the end we
decide to go for CINT7.

Everything else is still years away; "CINT8" was a layout for a C++ interpreter
API which we will probably also use for the new interpreter project.

> Further, what are the main differences between CINT5 and CINT7 from a
> users point of view (user meaning developer integrating CINT support
> into his own libraries)?

CINT7 is slower (by factors 1.5 to 10 depending on what you do) and it is not
as well tested. Its major advantage is its use of the reflection library Reflex
which allows much nicer access to C++ reflection data than CINT's C++ API.

Cheers, Axel.

>  
>> Sort of. We decided to move our development focus to another project.
>> CINT7
>> will still be actively developed for the next few months, but I expect
>> that we
>> will continue to maintain CINT5 for the next two years at least.
>>
>> So I believe that for your project (whatever it is :-) CINT5 is the
> way
>> to go.
>>
>> Cheers, Axel.
>
>

[Philippe Canal]

Hi,

No firm decision has been made yet.   The likely scenario is that for
the long
term we will be developing Cling as a replacement for Cint (formely the
plan was to
come with a version 8 of Cint with a much improved C++ interface).

In the meantime we will be actively supporting one version of Cint.  
That version is likely
to be Cint7 (which _if_ its performance issues can be resolved quickly
would represent
a net gain for the Hep experiments which are already using Reflex).  If
we do decide to
go with Cint7, this would mean that we would only fix 'show stoppers'
problems with
Cint5.

Cint7's major advantage is its use of the reflection library Reflex
which allows much
nicer access to C++ reflection data than Cint5's API.

Cint7 is API backward compatible with Cint5 and migrating from Cint5 to
Cint7 should
be seamless (except for adding one additional library to the link
line).   Cling will not be
backward compatible with either Cint5 nor Cint7.   However Cling will
also use Reflex.

Cheers,
Philippe.


Zelzer Sascha wrote:

> Hi,
>
> I was wondering if you could elaborate a little bit more about your
> plans of CINT (I saw some CINT8 and cling stuff...). Since I am
> considering to introduce C++ scripting into a rather large codebase, I
> would appreciate any hints about an optimal strategy of adopting CINT.
> Would it be better to wait a couple of weeks/months for a newer version
> or is using CINT7 or CINT5 "safe" in terms of only minimal changes on
> the user side when moving to a newer CINT version.
>
> Further, what are the main differences between CINT5 and CINT7 from a
> users point of view (user meaning developer integrating CINT support
> into his own libraries)?
>
> Thanks,
> Sascha
>  
>  
>> Sort of. We decided to move our development focus to another project.
>> CINT7
>> will still be actively developed for the next few months, but I expect
>> that we
>> will continue to maintain CINT5 for the next two years at least.
>>
>> So I believe that for your project (whatever it is :-) CINT5 is the
>>    
> way
>  
>> to go.
>>
>> Cheers, Axel.
>>    
>
>  

[Rene Brun]

Philippe,

I don't think that anybody right now can make announcements outside our
domain before
we have a clear understanding of the manpower that will be available for
our new project with the LLVM guys and before we are ourselves sure that
it is the way to go.
If we go LLVM/CLING, for sure CERN will not invest one cent in CINT7 and
we will only maintain the old CINT waiting for the new product. If FNAL
wants to go on a different road, it will be your choice.
In case some people do not understand what we are talking about, we want
to make sure to offer the most elegant and secure C++ interpreter
compliant with the new C++ standards as soon as possible.

Rene Brun

Philippe Canal wrote:

> Hi,
>
> No firm decision has been made yet.   The likely scenario is that for
> the long
> term we will be developing Cling as a replacement for Cint (formely
> the plan was to
> come with a version 8 of Cint with a much improved C++ interface).
>
> In the meantime we will be actively supporting one version of Cint.  
> That version is likely
> to be Cint7 (which _if_ its performance issues can be resolved quickly
> would represent
> a net gain for the Hep experiments which are already using Reflex).  
> If we do decide to
> go with Cint7, this would mean that we would only fix 'show stoppers'
> problems with
> Cint5.
>
> Cint7's major advantage is its use of the reflection library Reflex
> which allows much
> nicer access to C++ reflection data than Cint5's API.
>
> Cint7 is API backward compatible with Cint5 and migrating from Cint5
> to Cint7 should
> be seamless (except for adding one additional library to the link
> line).   Cling will not be
> backward compatible with either Cint5 nor Cint7.   However Cling will
> also use Reflex.
>
> Cheers,
> Philippe.
>
>
> Zelzer Sascha wrote:
>> Hi,
>>
>> I was wondering if you could elaborate a little bit more about your
>> plans of CINT (I saw some CINT8 and cling stuff...). Since I am
>> considering to introduce C++ scripting into a rather large codebase, I
>> would appreciate any hints about an optimal strategy of adopting CINT.
>> Would it be better to wait a couple of weeks/months for a newer version
>> or is using CINT7 or CINT5 "safe" in terms of only minimal changes on
>> the user side when moving to a newer CINT version.
>>
>> Further, what are the main differences between CINT5 and CINT7 from a
>> users point of view (user meaning developer integrating CINT support
>> into his own libraries)?
>>
>> Thanks,
>> Sascha
>>  
>>  
>>> Sort of. We decided to move our development focus to another project.
>>> CINT7
>>> will still be actively developed for the next few months, but I expect
>>> that we
>>> will continue to maintain CINT5 for the next two years at least.
>>>
>>> So I believe that for your project (whatever it is :-) CINT5 is the
>>>    
>> way
>>  
>>> to go.
>>>
>>> Cheers, Axel.
>>>    
>>
>>  
>

[Philippe Canal]

Hi Rene,

I completely agree that no decision has yet been made.


Cheers,
Philippe.

Rene Brun wrote:

> Philippe,
>
> I don't think that anybody right now can make announcements outside
> our domain before
> we have a clear understanding of the manpower that will be available
> for our new project with the LLVM guys and before we are ourselves
> sure that it is the way to go.
> If we go LLVM/CLING, for sure CERN will not invest one cent in CINT7
> and we will only maintain the old CINT waiting for the new product. If
> FNAL wants to go on a different road, it will be your choice.
> In case some people do not understand what we are talking about, we
> want to make sure to offer the most elegant and secure C++ interpreter
> compliant with the new C++ standards as soon as possible.
>
> Rene Brun
>
> Philippe Canal wrote:
>> Hi,
>>
>> No firm decision has been made yet.   The likely scenario is that for
>> the long
>> term we will be developing Cling as a replacement for Cint (formely
>> the plan was to
>> come with a version 8 of Cint with a much improved C++ interface).
>>
>> In the meantime we will be actively supporting one version of Cint.  
>> That version is likely
>> to be Cint7 (which _if_ its performance issues can be resolved
>> quickly would represent
>> a net gain for the Hep experiments which are already using Reflex).  
>> If we do decide to
>> go with Cint7, this would mean that we would only fix 'show stoppers'
>> problems with
>> Cint5.
>>
>> Cint7's major advantage is its use of the reflection library Reflex
>> which allows much
>> nicer access to C++ reflection data than Cint5's API.
>>
>> Cint7 is API backward compatible with Cint5 and migrating from Cint5
>> to Cint7 should
>> be seamless (except for adding one additional library to the link
>> line).   Cling will not be
>> backward compatible with either Cint5 nor Cint7.   However Cling will
>> also use Reflex.
>>
>> Cheers,
>> Philippe.
>>
>>
>> Zelzer Sascha wrote:
>>> Hi,
>>>
>>> I was wondering if you could elaborate a little bit more about your
>>> plans of CINT (I saw some CINT8 and cling stuff...). Since I am
>>> considering to introduce C++ scripting into a rather large codebase, I
>>> would appreciate any hints about an optimal strategy of adopting CINT.
>>> Would it be better to wait a couple of weeks/months for a newer version
>>> or is using CINT7 or CINT5 "safe" in terms of only minimal changes on
>>> the user side when moving to a newer CINT version.
>>>
>>> Further, what are the main differences between CINT5 and CINT7 from a
>>> users point of view (user meaning developer integrating CINT support
>>> into his own libraries)?
>>>
>>> Thanks,
>>> Sascha
>>>  
>>>  
>>>> Sort of. We decided to move our development focus to another project.
>>>> CINT7
>>>> will still be actively developed for the next few months, but I expect
>>>> that we
>>>> will continue to maintain CINT5 for the next two years at least.
>>>>
>>>> So I believe that for your project (whatever it is :-) CINT5 is the
>>>>    
>>> way
>>>  
>>>> to go.
>>>>
>>>> Cheers, Axel.
>>>>    
>>>
>>>  
>>
>

[Severin Ecker-2]

Hi,

continuing the work with cint I stumbled over an issue with the byte
code compiler.

The following class is compiled into an interpreter (although any class
that allocates dynamic memory and deletes this memory in the destructor
causes the same issue):

str.h

struct Str {
    Str(const char *);
    ~Str();
   
    char* stringMember;
};


str.cpp

Str::Str(const char* str) {
    stringMember = new char[strlen(str) + 1];
    strcpy(stringMember, str);
    stringMember[strlen(str) - 1] = '\0';
}

Str::~Str() {
    delete[] stringMember;
}


In the interpreted version (G__asm_loopcompile <= 3) everything works
fine and as intended. if G__asm_loopcompile is set to a value >= 4, the
function G__compile_bytecode() is invoked in ifunc.cxx ~ line 5577,
which results in bytecode that never calls the destructor, therefore
leaking the memory.
The problem is, that the performance boost gained through the bytecode
compilation is desperately needed, but the leaks aren't desirable
especially since these happen in compiled loops where the leaks quickly
accumulate.

Can someone please point me to where the issue might be? (what i found
out that it's not a bytecode optimization problem, since commenting out
all bytecode optimization after compilation still results in leaks so I
suppose the problem is somewhere in the compilation)

Do I have to take special care when using new/delete within a class used
within an interpreted function that's called in a loop or is this really
an issue and if so, can someone please help me since I'm kind of lost in
the bytecode code.

Many thanks in advance.

cheers,
severin