Joosep Pata | 27 Apr 18:11 2015

ROOT 6.02.08 compilation fails on osx 10.10.3

Dear ROOT devs,

On OSX 10.10.3 with Xcode 6.3.1, the compilation of the latest source tarball fails with the following error:

> bin/rmkdepend -R -fcore/base/src/TRegexp.d -Y -w 1000 -- -m64 -std=c++11 -pipe -Wshadow -W -Wall
-Woverloaded-virtual -fsigned-char -fno-common -Iinclude    -stdlib=libc++ -pthread
-Icore/base/src -D__cplusplus -- /Users/joosep/Documents/root-6.02.08/core/base/src/TRegexp.cxx
> clang++ -O2 -DNDEBUG -m64 -std=c++11 -pipe -Wshadow -W -Wall -Woverloaded-virtual -fsigned-char
-fno-common -Iinclude    -stdlib=libc++ -pthread -Icore/base/src -o core/base/src/TRegexp.o -c /Users/joosep/Documents/root-6.02.08/core/base/src/TRegexp.cxx
> /Users/joosep/Documents/root-6.02.08/core/base/src/TRegexp.cxx:146:4: error: thread-local
storage is not supported for the current target
>    thread_local char buf[fgMaxpat];
>    ^
> /Users/joosep/Documents/root-6.02.08/core/base/src/TRegexp.cxx:200:11: warning: address of
stack memory associated with local variable 'buf' returned
>       [-Wreturn-stack-address]
>    return buf;
>           ^~~
> 1 warning and 1 error generated.

I have seen the JIRA thread, however, it seems to refer to an older version of osx. Is anyone else seeing this error?

> $ clang++ --version
> Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.3.0
> Thread model: posix

> $ sw_vers -productVersion
> 10.10.3

(Continue reading)

Bakur Parsamyan | 26 Apr 19:55 2015

Re: TMultiGraph in 3D

Hi Smbat,

indeed, the problem was that, by chance, I had quite old version of the ROOT (5.32/04) installed on the laptop.
It seems this 3D-option was implemented somewhat later.
Anyway, at the end I used TH2F which appeared to be more "flexible" choice.

Thanks and Best regards,

On 26/04/2015 14:02, Smbat Grigoryan wrote:
P {margin-top:0;margin-bottom:0;}
Hi Bakur,
probably it is due to a problem in your ROOT installation.
Your macro in my ROOT 5.34/28 gives the expected result.
Cheers, Smbat
From: Bakur Parsamyan
Sent: Sunday, April 26, 2015 12:53
To: roottalk (Mailing list for ROOT users.)
Subject: TMultiGraph in 3D

Dear Rooters,

I would like to produce something similar to the first example quoted here:

but even provided simple macro gives strange result:

Bakur Parsamyan | 26 Apr 12:53 2015

TMultiGraph in 3D

Dear Rooters,

I would like to produce something similar to the first example quoted here:

but even provided simple macro gives strange result:

Do I need some additional libraries to make it work or what do I miss?

Thanks and Best regards,
   c0 = new TCanvas("c1","multigraph L3",200,10,700,500);

   TMultiGraph *mg = new TMultiGraph();

   TGraph *gr1 = new TGraph(); gr1->SetLineColor(kBlue);
   TGraph *gr2 = new TGraph(); gr2->SetLineColor(kRed);
   TGraph *gr3 = new TGraph(); gr3->SetLineColor(kGreen);
   TGraph *gr4 = new TGraph(); gr4->SetLineColor(kOrange);

   Double_t dx = 6.28/100;
   Double_t x  = -3.14;

   for (int i=0; i<=100; i++) {
      x = x+dx;

   mg->Add(gr4); gr4->SetTitle("Cos(x*x*x)"); gr4->SetLineWidth(3);
   mg->Add(gr3); gr3->SetTitle("Cos(x*x)")  ; gr3->SetLineWidth(3);
   mg->Add(gr2); gr2->SetTitle("Cos(x)")    ; gr2->SetLineWidth(3);
   mg->Add(gr1); gr1->SetTitle("2*Sin(x)")  ; gr1->SetLineWidth(3);

   mg->Draw("a fb l3d");
   return c0;
Joosep Pata | 24 Apr 23:11 2015

cling llvm::TargetTriple segfault

Dear Cling experts,

I’m embedding ROOT6/cling in a project that uses it’s own internal llvm. When I link against the
external llvm, but call no external functions, simple ROOT calls crash with a segfault resulting from an
uninitialized TargetTriple in BackendPass.cpp:420

Here’s the stack trace
> * thread #1: tid = 0x3623a5, 0x0000000106fabd5b`llvm::DenseMapBase<llvm::DenseMap<void const*, llvm::PassInfo const*,
llvm::DenseMapInfo<void const*> >, void const*, llvm::PassInfo const*, llvm::DenseMapInfo<void
const*> >::insert(std::__1::pair<void const*, llvm::PassInfo const*>&&) + 75, queue =
'', stop reason = EXC_BAD_ACCESS (code=1, address=0x1fd5bbfe)
>   * frame #0: 0x0000000106fabd5b`llvm::DenseMapBase<llvm::DenseMap<void const*,
llvm::PassInfo const*, llvm::DenseMapInfo<void const*> >, void const*, llvm::PassInfo const*,
llvm::DenseMapInfo<void const*> >::insert(std::__1::pair<void const*, llvm::PassInfo
const*>&&) + 75
>     frame #1: 0x0000000106fab5de`llvm::PassRegistry::registerPass(llvm::PassInfo
const&, bool) + 78
>     frame #2: 0x0000000106e7dda1`llvm::initializeTargetLibraryInfoPass(llvm::PassRegistry&) + 161
>     frame #3: 0x0000000106e7dee0`initialize(llvm::TargetLibraryInfo&, llvm::Triple
const&, char const**) + 48
>     frame #4: 0x0000000105ad3a0b`cling::BackendPass::CreatePasses(this=0x0000000103027390,
LangOpts=0x00000001032240a0, CodeGenOpts=0x0000000104028250) + 843 at BackendPass.cpp:420

And the uninitialized TargetTriple that gets passed to TargetLibraryInfo
> (llvm::Triple) TargetTriple = (Data = "", Arch = UnknownArch, SubArch = NoSubArch, Vendor =
UnknownVendor, OS = UnknownOS, Environment = UnknownEnvironment, ObjectFormat = ELF)

>     PMBuilder.LibraryInfo = new TargetLibraryInfo(TargetTriple);

Now I wonder what could cause the cling input module TargetTriple to get polluted and why is it causing a
segfault in map insert.

I thought it’s worth a shot to ask if anyone has an idea…

Best wishes,
Vyacheslav Krutelyov | 24 Apr 17:09 2015

double precision in interactive sesion


I noticed that in ROOT 6 the interactive math double precision values
show up in single precision.
Double precision variables and literals are treated correctly, they are
just not printed as doubles.

Is this configurable or can be controlled?

Please advise

Thank you

P.S. here are a few snippets
[using   ROOT 6.02/05   ]

root [3] Double_t xd = 1
(Double_t) 1.000000e+00
root [4] xd +=1e-12
(Double_t) 1.000000e+00
root [5] if (xd == 1.0) cout<< "aa"<<endl;
root [6] Double_t xdo = 1
(Double_t) 1.000000e+00
root [7] xdo +=1e-12
(Double_t) 1.000000e+00
root [9] if (xd == xdo) cout<< "aa"<<endl;


 Vyacheslav (Slava) Krutelyov
 TAMU: Physics Dept Texas A&M MS4242, College Station, TX 77843-4242
 CERN: 42-R-027
 AIM/Skype: siava16              googleTalk: slava77 <at>
 (630) 291-5128  Cell (US)       +41 76 275 7116 Cell (CERN)


Timur Pocheptsov | 23 Apr 22:16 2015

RE: Unsubscribe

From: Ajinkya Kamat [ask1710 <at>]
Sent: 23 April 2015 22:00
To: roottalk (Mailing list for ROOT users.)
Subject: Unsubscribe

Pere Mato Vila | 23 Apr 14:43 2015

ROOT development 6.03/04 has been released

Dear All,

The development release of ROOT v6.03/04 is now available. The Git tag for this version is v6-03-04. This is the second of two development releases before the next production release 6.04/00 scheduled for 2015-05-26

See the release notes for the most relevant changes since 6.02/00. 

The 6.03/04 binaries for different platforms and compilers can be found at:

   —> /afs/

Pere Mato
on behalf of the ROOT Team

Pere Mato  CERN, PH Department, CH 1211 Geneva 23, Switzerland
e-mail: pere.mato <at> tel:   +41 22 76 78696
fax:  +41 22 76 68792 gsm: +41 76 48 70855

André Miguel Monteiro | 16 Apr 11:41 2015

Associate entries to a given pixel

Dear Root users,

I have concluded a MC simulation of a CT scan, which generated a ROOT file.

To analyze the simulation I have already made an histogram that gives me the number of detected photons according to the X and Y position of the detector with this:

Double_t const PIXELSIZE = 0.508;
Int_t const RAW = 475;
Int_t const COLUMN = 379;
// Energy bounds in MeV
Float_t const EMIN = 0.01;
Float_t const EMAX = 0.04;

TTree* singlesTree = (TTree*)file->Get( "Singles" );
// Global Position in X, Y and Z
Float_t globalPosX, globalPosY, globalPosZ, energy;
Int_t runID, pixelID;
singlesTree->SetBranchAddress( "globalPosX", &globalPosX );
singlesTree->SetBranchAddress( "globalPosY", &globalPosY );
singlesTree->SetBranchAddress( "globalPosZ", &globalPosZ );
singlesTree->SetBranchAddress( "energy", &energy );
singlesTree->SetBranchAddress( "runID", &runID );
singlesTree->SetBranchAddress( "pixelID", &pixelID );

// Number of entries in the single tree
Int_t entriesSingleTree = (Int_t)singlesTree->GetEntries();

Double_t const RAW_BOUND =  PIXELSIZE * RAW / 2;
TH2F* run_0 = new TH2F( "runID = 0", "projection during the first run",

for( Int_t i = 0; i != entriesSingleTree; ++i )
singlesTree->GetEntry( i );
if( runID == 0 )
                        run_0->Fill( globalPosX, globalPosY );  

run_0->Draw( "COLZ" );

What I need now is to get a matrix of the number of photons detected from pixel (-96.266, -120.65) to pixel (96.266, 120.65).

What do I need to do to store that in a .txt file for example?

Thank you.

Best regards,

André Miguel Monteiro

MSc Student in Biomedical and Biophysics Engineering at Faculty of Sciences of the University of Lisbon

Institute of Biophysics and Biomedical Engineering
Faculty of Sciences, University of Lisbon
Campo Grande
1749-016 Lisbon

Room Office: 1.02
Extension: 20509
Email: ammonteiro <at>
Axel Naumann | 14 Apr 17:25 2015

ROOT patch 6.02/08 has been released

Dear All,

The patch release of ROOT v6.02/08 is available. The Git tag for this 
version is v6-02-08.

For what is fixed in this patch release see the patch release notes

Stand-alone binaries for several platforms can be downloaded from
<>. The AFS
version of 6.02/08 can be found at

In case you wonder what happened to 6.02/06 and /07: we have skipped 
them. The numbering scheme of patch releases has now changed; the patch 
level is even for tags and odd in between.

We are aware that 6.02/08 does not work with XCode 6.3; a new patch 
release will follow soon.

Best regards,

Axel Naumann
on behalf of the ROOT team

Marc Escalier | 14 Apr 15:07 2015

problem to create a shared library (.so)


i try to create a shared library using :

root -l

.L HSG1Selector.cxx+

but i occur the error message :

error: 'vector' is not a member of 'HSG1Selector'

Would you have an idea ?

thank you

SIZUN Patrick | 14 Apr 08:51 2015

ROOT6, rootcint and namespaces


I was checking whether a code written for ROOT5 could be built with ROOT 6 (v6-02-05),
and the dictionary generation seems to have an issue with namespaces named "get" (and "set", and "map", but
I do not mind so much).

Here is a minimal example:

>>>>>>>>>>>>>>>>>> MyClass.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
#ifndef get_MyClass_h
#define get_MyClass_h

namespace get {

class MyClass {


<<<<<<<<<<<<<<<< MyClass.h <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>> LinkDef.h >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
#ifdef __CINT__

#pragma link off all globals;
#pragma link off all classes;
#pragma link off all functions;

//#pragma link C++ namespace get;
#pragma link C++ class get::MyClass;


With ROOT5, the command "rootcint -f MyDict.cxx -c -p MyClass.h LinkDef.h" returns successfully.
With ROOT6, it complains:
ERROR in CloseStreamerInfoROOTFile(): cannot find class get::MyClass

Is it expected? For backward compatibility, I would prefer not to have to rename my namespace.