Hi Damir,
The feature of executing static objects when loading a shared lib is
working on all the other systems (even old-fashioned systems).
I would be a mistake if the MacOSX development team is not addressing
this question seriously. Also I do don't like very much these dylib
files.
Rene Brun
On
Fri, 6
Jun 2003, Damir Buskulic wrote:
> Hi Rene,
>
> I fully agree on this one, and I've searched very extensively
> solutions, since it also bothers me. The problem is the way the OSX
> loader works. It doesn't execute global variables constructors if these
> variables are not referenced anywhere in the code, which is the case
> for the cint global initializers.
> There was a very long thread on Darwin dev lists and basically, the
> Darwin/Apple developpers consider that there is no reason to execute
> global variables constructors which are in no way accessed by the main
> or derived code. This works on other platforms but there is nothing
> mandatory in any C/C++ standard.
> They say this kind of programming should not happen and is not good,
> but Masa told me he cannot do anything about that.
> Though it seems Darwin developpers are in principle right, I believe
> Masa when he says he cannot change anything. I'm not sure I exactly
> understood both statements.
> The net result is : yes, this is an ugly solution, but we unfortunately
> have to live (a long time ?) with it.
>
> Cheers
>
> Damir
>
> Le vendredi, 6 juin 2003, à 10:46 Europe/Zurich, Rene Brun a écrit :
>
> > Hi Damir,
> >
> > Your solution works but cannot be a long term solution.
> > I hope that the MacOSX development team will fix this loader problem.
> >
> > Rene Brun
> >
> > On
> > Fri, 6 Jun 2003,
> > Damir Buskulic wrote:
> >
> >> Hi,
> >>
> >> I had the same kind of errors while building our software. The
> >> solution
> >> was to add an option to the compiler to tell it that a symbol was
> >> undefined, forcing the immediate loading of the corresponding library,
> >> and executing the static initializers in the rootcint generated code.
> >> For example, if you do an
> >>
> >> nm $ROOTSYS/lib/libTree.dylib | more
> >>
> >> you will notice a symbol _G__cpp_setup_initializerG__Tree (there
> >> should
> >> always be a _G__cpp_setup_initializerXXXXX in a library with
> >> rootcinted
> >> classes)
> >> try to add to your linker command line (I don't exactly remenber if
> >> after or before the -lTree)
> >>
> >> -u _G__cpp_setup_initializerG__Tree
> >>
> >> This should help. This should be repeated for all libraries concerned,
> >> i.e. the ones giving problems.
> >>
> >> Let me know if it solves something
> >>
> >> Cheers
> >>
> >> Damir
> >>
> >> Le vendredi, 6 juin 2003, à 01:21 Europe/Zurich, Jeffrey J. Early a
> >> écrit :
> >>
> >>> I'm having the exact same problem that Brian was having (read below)
> >>> and I
> >>> wanted to find out if anyone managed to find a work around (Brian
> >>> says
> >>> that
> >>> he did not).
> >>>
> >>> I'm running Root 3.05/03 on MacOSX 10.2.6 with the latest developer
> >>> tools
> >>> including gcc3 -- and the newest version of dlcompat.
> >>>
> >>> I created a simplified version of the problem (which works just fine
> >>> when
> >>> run with the interpreter).
> >>>
> >>> http://darkwing.uoregon.edu/~jearly/HEP/
> >>>
> >>> The example program 'treesimple' compiles and runs just fine. It
> >>> creates a
> >>> tree and writes it to a root file without a hitch. The example
> >>> program
> >>> 'treeread' compiles just fine but then spits out the same error
> >>> message
> >>> Brian was getting when reading the file.
> >>>
> >>> I tried Rene's suggestion but that didn't change anything -- same
> >>> results.
> >>>
> >>> Any other ideas?
> >>>
> >>> Thanks for any help,
> >>> Jeffrey
> >>>
> >>>> Hi Brian,
> >>>>
> >>>> This looks like a dynamic loading problem on MacOS.
> >>>> To see if this is the case, add in your main program
> >>>>
> >>>> #include <TApplication.h>
> >>>>
> >>>>
> >>>> int main(int argc, char **argv)
> >>>> {
> >>>> TApplication theApp("App", &argc, argv);
> >>>> .. your own code
> >>>> ..
> >>>> }
> >>>>
> >>>> Rene Brun
> >>>>
> >>>> On Fri, 14 Feb 2003,
> >>>> Brian Kurt Fujikawa wrote:
> >>>>
> >>>>> Hello
> >>>>>
> >>>>> I'm running root v3.04.02 (source installation) on MacOSX 10.2.3 (X
> >>>>> Public
> >>>>> Beta 0.2). I am having trouble running a standalone program that
> >>>>> loads
> >>>>> trees. Specifically, my program includes the lines:
> >>>>>
> >>>>> TFile* EventFile=
> >>>>> new TFile("/Users/bkf/emiT/data/Data1_20021209_15477.root");
> >>>>> TTree* CoincidenceEventTree=
> >>>>> (TTree*)EventFile->Get("Event/CoincidenceEventTree");
> >>>>> TBranch* CoincidenceEventBranch=
> >>>>> CoincidenceEventTree->GetBranch("CoincidenceEventBranch");
> >>>>>
> >>>>> and when I run it, I get the following error messages:
> >>>>>
> >>>>> Warning in <TClass::TClass>: no dictionary for class TTree is
> >>>>> available
> >>>>> Warning in <TClass::TClass>: no dictionary for class TBranchElement
> >>>>> is
> >>>>> available
> >>>>> Warning in <TClass::TClass>: no dictionary for class TBranch is
> >>>>> available
> >>>>> Warning in <TClass::TClass>: no dictionary for class TLeafElement
> >>>>> is
> >>>>> available
> >>>>> Warning in <TClass::TClass>: no dictionary for class TLeaf is
> >>>>> available
> >>>>> Error in <TBuffer::CheckByteCount>: object of class TNamed read too
> >>>>> few
> >>>>> bytes: 26 instead of 821615
> >>>>> Warning in <TBuffer::CheckByteCount>: TNamed::Streamer() not in
> >>>>> sync
> >>>>> with
> >>>>> data on file, fix Streamer()
> >>>>>
> >>>>> *** Break *** bus error
> >>>>> Abort
> >>>>>
> >>>>>
> >>>>> This programs DOES run when I execute it as a script in root and it
> >>>>> also
> >>>>> runs on a linux box.
> >>>>>
> >>>>> I am using the following commands to build this program ("myprog"):
> >>>>>
> >>>>> g++ -O -Wall -pipe -I/Users/bkf/include/DAT/
> >>>>> -I/Users/bkf/root/include -c
> >>>>> myprog.cc
> >>>>> g++ -O -Xlinker -bind_at_load -flat_namespace -o myprog myprog.o
> >>>>> -L/Users/bkf/lib/ -lDATEvent -L/Users/bkf/root/lib -lCore -lCint
> >>>>> -lHist
> >>>>> -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix
> >>>>> -lPhysics
> >>>>> -lm
> >>>>> -ldl
> >>>>>
> >>>>> Any ideas?
> >>>>>
> >>>>> Best Regards
> >>>>>
> >>>>> Brian
> >>>
> >>>
> >> ====================================
> >> Damir Buskulic, Universite de Savoie/LAPP
> >> Chemin de Bellevue, B.P. 110, F-74941 Annecy-le-Vieux Cedex, FRANCE
> >> Tel : +33 (0)450091600
> >> e-mail: buskulic@lapp.in2p3.fr
> >> ====================================
> >>
> >
> >
> ====================================
> Damir Buskulic, Universite de Savoie/LAPP
> Chemin de Bellevue, B.P. 110, F-74941 Annecy-le-Vieux Cedex, FRANCE
> Tel : +33 (0)450091600
> e-mail: buskulic@lapp.in2p3.fr
> ====================================
>
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:12 MET