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