Thanks Axel, This sheds some more light for me on the G__setup* calls, but
I will try to understand them even better, now.
So far my approach has been:
(1) use makecint to generate a simple demonstration makefile
(2) run the makefile, and look at the executed commands
(3) use this information to build my own makefiles.
I did that *once*, a long time ago, and I don't use (or even compile)
makecint ever since. I compile cint(.exe), in order to generate my
dictionaries. Then, I build my own "libMYcint" containing all libcint
sourcefiles, (but without STL, iostream etc, I don't need those), plus my
own classes, plus the dictionaries, plus a few more files I seemed to need,
even though I didn't exactly understand why, such as main/G__setup.c and/or
main/G__main.c. This gives me a single library providing a C++ interpreter
that magically has knowlegde of my own classes.
The problem I had was on windows, using this libMYcint. So this is what I
did. There is no question here, I will first do some more homework. I need
to understand better why it is *supposed* to work in the first place :)
Thanks,
Christoph
On Sun 2001-07-08, Axel Naumann wrote:
> No. I can't see how Christoph's problem is related to this. In principle
> Christoph's set of commands should work, as neither G__init_cint nor
> G__scratch_all call G__remove_setup_func. Instead, they call
> G__reset_setup_funcs, which is requesting a re-init of the dictionary,
> resetting all the G__setup_func_list[i]->inited = 0;. The re-init is then
> done by G__init_cint.
>
> So what you should check (if you can) is when G__remove_setup_func gets
> called and by whom. It should only get called by the destructor of
> G__cpp_setup_initmyfile, which in turn should only be called cleaning up
> globals when exiting.
>
> Sorry, I know that's not much of a help to you, Christoph.
>
> The fix I suggest is a fix to a ROOT-only problem. Cint is just fine; Root
> expects more from Cint than it's supposed to.
>
> Cheers, Axel.
>
> > -----Original Message-----
> > From: Valeri Fine [mailto:fine@bnl.gov]
> > Sent: Sunday, July 08, 2001 11:40 AM
> > To: axel@fnal.gov; rootdev@pcroot.cern.ch
> > Cc: Christoph Bugel
> > Subject: Re: [ROOT] dictionary init - solution?
> >
> >
> > Hello Axel,
> >
> > Great job !!! I guess it took a while to sort things out.
> >
> > Do you think the problem
> > http://root.cern.ch/root/roottalk/roottalk01/2381.html
> > will be fixed with your remedy too ?
> > My best regards, Valeri
> >
> > ----- Original Message -----
> > From: "Axel Naumann" <a.naumann@worldnet.att.net>
> > To: "Rene Brun" <Rene.Brun@cern.ch>; "Masaharu Goto"
> > <MXJ02154@nifty.ne.jp>
> > Cc: "Valeri Fine" <fine@bnl.gov>
> > Sent: Sunday, July 08, 2001 1:23 AM
> > Subject: RE: [ROOT] dictionary init - solution?
> >
> >
> > > Hi,
> > >
> > > once again a summary of the problem:
> > >
> > > It can (and does) happen that during the instatiation of gROOT TROOT
> > > initializes TCint, which calls G__call_setup_funcs BEFORE the
> > > G__cpp_setup... G__cpp_setup_initializer... get instantiated.
> > This results
> > > in a nice G__setup_func_list, but their methods never get called, as the
> > one
> > > and only G__call_setup_funcs call was too early (the list was still
> > empty).
> > >
> > >
> > >
> > > If one would add in the (root)cint generated code
> > > class G__cpp_setup_myfile {
> > > public:
> > > G__cpp_setup_myfile() {
> > > G__add_setup_func("myfile",(G__incsetup)(&G__cpp_setupmyfile));
> > > G__call_setup_funcs(); // new line
> > > }
> > > the dictionary would get re-initialized after every added class
> > (only the
> > > new setup_funcs would get called, the others have inited==1).
> > >
> > > I've tested this solution for my version (where currently gROOT gets
> > > initialized before the G__cpp_setup... objects, which means the
> > dict never
> > > gets initialized), it works perfectly. And I've tested it building the
> > > official root distribution, with patched cint/src/newlink.c. This, too,
> > > works.
> > >
> > > (The official root build never had the problem of initializing gROOT
> > before
> > > the G__cpp_setups. The setups get instantiated before gROOT. I have no
> > clue
> > > how it does that. The reason might be a correct order of
> > libraries on the
> > > link line.)
> > >
> > > So with this patch both the official and selfmade root builds
> > work. It's a
> > > small overhead of about 20 calls to G__call_setup_funcs (for
> > the official
> > > Root build, which makes cint reset all entries in the
> > G__setup_func_list,
> > > setting their inited=0), but it ensures that the G__cpp_setups are not
> > only
> > > added, but get actually executed. I know it screws up the nice
> > > initialization scheme for cint, but one could e.g. add a
> > parameter passed
> > to
> > > cint's main which tells it to add the G__call_setup_funcs() line.
> > >
> > > Cheers, Axel.
> > >
> > > > -----Original Message-----
> > > > From: owner-roottalk@pcroot.cern.ch
> > > > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Valeri Fine
> > > > Sent: Friday, July 06, 2001 6:06 PM
> > > > To: Axel Naumann; Roottalk@Pcroot. Cern. Ch
> > > > Subject: Re: [ROOT] Win + dictionary init
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Let me guess, saying "unknown class TGX11" without saying
> > > > "libTGX not found"
> > > > > before? (Which means it did load the lib, but didn't init the dict?)
> > > >
> > > > Yes it is very our observation.
> > > > Our "observation" there is some memory corruption.
> > > > However we did not find the exact reason and place.
> > > > >
> > > > > :-) Let's try to fix that.
> > > > >
> > > > We have been spending many hours with gdb hunting this problem.
> > > > At least it is clear there is no Windows specific here.
> > > > At the moment we must switch to do something else.
> > > >
> > > > Since we found it works with 3.00/06 we went back to this
> > ROOT version.
> > > > I'll try to come back to hunt the problem latter.
> > > >
> > > > Appreciate any idea
> > > >
> > > > My best regards, Valeri
> > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-roottalk@pcroot.cern.ch
> > > > > > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Valeri Fine
> > > > > > Sent: Friday, July 06, 2001 5:32 PM
> > > > > > To: Axel Naumann; Roottalk@Pcroot. Cern. Ch
> > > > > > Subject: Re: [ROOT] Win + dictionary init
> > > > > >
> > > > > >
> > > > > > We have near the same problem under Linux with ROOT 3.01.05
> > > > > > (There was no such problem with
> > > > > > 3.00/06)
> > > > > >
> > > > > > The ROOT-based code dies calling gROOT-ProcessLineFAst
> > as follows:
> > > > > >
> > > > > >
> > > > > > void TApplication::LoadGraphicsLibs()
> > > > > >
> > > > > > . . .
> > > > > > gROOT->ProcessLineFast("new TGX11("X11", "ROOT interface to
> > > > X11");");
> > > > > >
> > > > > >
> > > > > > Switching ROOTSYS from 3.01/05 to 3.00/06 cures the probem.
> > > > > >
> > > > > > Any idea ?
> > > > > >
> > > > > > My best regards
> > > > > > Valeri
> > > > > > ----- Original Message -----
> > > > > > From: "Axel Naumann" <axel@fnal.gov>
> > > > > > To: "Roottalk@Pcroot. Cern. Ch" <roottalk@pcroot.cern.ch>
> > > > > > Sent: Friday, July 06, 2001 4:23 PM
> > > > > > Subject: [ROOT] Win + dictionary init
> > > > > >
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I still have this persistent problem with win and the
> > > > > > dictionary. Apparently
> > > > > > > the order of the instantiation of the globals is messed up
> > > > > > sometimes. Here
> > > > > > > is what's happening on my machine (which breaks the dictionary)
> > when
> > > > > > > starting a program that links against root libraries:
> > > > > > >
> > > > > > > * a TROOT object is created
> > > > > > > - this calls new TCint, which calls at some point
> > > > > > G__reset_setup_funcs(),
> > > > > > > here's the stack:
> > > > > > > ---
> > > > > > > G__reset_setup_funcs() line 163
> > > > > > > G__scratch_all() line 257
> > > > > > > G__main() line 646
> > > > > > > G__init_cint() line 350 + 19 bytes
> > > > > > > TCint::ResetAll() line 328 + 10 bytes
> > > > > > > TCint::TCint(const char * 0x101fd864, const char *
> > > > 0x101fd84c) line 101
> > > > > > > ---
> > > > > > >
> > > > > > > - now, G__call_setup_funcs() is called. Those are empty, as
> > > > > > none of the
> > > > > > > global G__cpp_setup guys is instantiated yet. Call stack:
> > > > > > > ---
> > > > > > > G__call_setup_funcs() line 129
> > > > > > > G__main() line 703
> > > > > > > G__init_cint() line 350 + 19 bytes
> > > > > > > TCint::ResetAll() line 328 + 10 bytes
> > > > > > > TCint::TCint(const char * 0x101fd864, const char *
> > > > 0x101fd84c) line 101
> > > > > > > TROOT::TROOT(const char * 0x101fd830, const char * 0x101fd818,
> > > > > > void (void)*
> > > > > > > * 0x00000000) line 245 + 40 bytes
> > > > > > > ---
> > > > > > >
> > > > > > > * finally, the G__cpp_setup guys are called. But now it's too
> > > > > > late! TCint
> > > > > > > doesn't care anymore, it thinks it's done with its dictionary
> > > > > > > initialization, so G__call_setup_funcs is not called anymore.
> > > > > > Example for my
> > > > > > > first call of G__add_setup_func:
> > > > > > > ---
> > > > > > > G__add_setup_func() line 65
> > > > > > > LIBCORE!
> > > > G__cpp_setup_initG__Base1::G__cpp_setup_initG__Base1(void) + 22
> > > > > > > bytes
> > > > > > > LIBCORE! G__cpp_setupG__Base1 + 105 bytes
> > > > > > > ---
> > > > > > >
> > > > > > > * and now my main() gets called. And the dictionary is empty.
> > > > > > >
> > > > > > > So THIS is the reason why sometimes even UInt_t was unknown to
> > > > > > Root. How can
> > > > > > > we fix this? How can we make sure all G__cpp_setups "register"
> > > > > > first, before
> > > > > > > cint calls the setup funcs? Or shall we call
> > > > > > G__call_setup_functs directly
> > > > > > > at some point? Or can I circumvent this by some magical
> > > > permutaion on my
> > > > > > > link line?
> > > > > > >
> > > > > > > (Win 2000, Root since 3.00/something)
> > > > > > >
> > > > > > > Cheers, Axel.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:51 MET