Tkinter 8.6 exception

[goatface]

New laptop with a new OS (Manjaro Linux based on Arch).

ROOT is 6.12.04. I rebuilt it to use python2 (2.7.14) since pygui/grut-view.py and others barf with python3.

tk is also installed as version 8.6 which I suspect could be the problem. However, I tried to use tk 8.5 but it couldn't be done without building a lower version of python2 from source, and I spare you the related failures (tk 8.6 is hardcoded into various parts of /usr/lib/python2.7/lib-tk )

When I first open grutinizer I get a couple errors. (The first with color persists even without -g.)

Getline_color/ColorFromName: cannot parse color #CCCC00!
(TFile *) 0x55f11e5e4970
        file hist/check/0059.root opened as _file0
GRizer [0] Error in <TProtoClass::FindDataMember>: data member with index 0 is not found in class thread
Error in <CreateRealData>: Cannot find data member # 0 of class thread for parent StoppableThread!

Here is the further (and to me most suspect) output when I open a session with -g and try to view a histogram by clicking on it:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1541, in __call__
    return self.func(*args)
  File "/home/daid/physics/GRUTinizer/GRUTinizer/pygui/hist_tab.py", line 45, in OnHistClick
    for name in event.widget.selection()}
  File "/home/daid/physics/GRUTinizer/GRUTinizer/pygui/hist_tab.py", line 45, in <dictcomp>
    for name in event.widget.selection()}
  File "/home/daid/physics/GRUTinizer/GRUTinizer/pygui/util.py", line 57, in __getitem__
    (ROOT.TH1D, ROOT.xH1D),
  File "/usr/lib/root/ROOT.py", line 470, in __getattr2
    raise AttributeError( name )
AttributeError: xH1D

I think my install is almost there...

It might not be tk if the TProtoClass::FindDataMember is a meaningful error, but I'm not sure what to make of it. gcc is a bit bleeding edge over here (7.2.1) but with clang these days I'm a bit in a daze which compiler should matter where.

However, with all the various PyROOT errors I got, this one was only showing up near the finish line and always after Tkinter seems to actually be loaded successfully (e.g. GUI is showing, I can open folders, just not view the histograms).

[goatface]

Tried Xubuntu 17.10.1, Artful Aardvark on my second internal drive. However, most of the default software is very similar to the Manjaro defaults and the error is reproduced.

GCC is 7.2.0

ROOT 6.12.04

Python is 2.7.14 (python3 is installed but not set as default)

TKinter version is 8.6

$ grutinizer -g /tmp/0059.root 
Getline_color/ColorFromName: cannot parse color #CCCC00!
(TFile *) 0x55cae90c2ed0
	file /tmp/0059.root opened as _file0
GRizer [0] Error in <TProtoClass::FindDataMember>: data member with index 0 is not found in class thread
Error in <CreateRealData>: Cannot find data member # 0 of class thread for parent StoppableThread!
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1544, in __call__
    return self.func(*args)
  File "pygui/hist_tab.py", line 45, in OnHistClick
    for name in event.widget.selection()}
  File "pygui/hist_tab.py", line 45, in <dictcomp>
    for name in event.widget.selection()}
  File "pygui/util.py", line 57, in __getitem__
    (ROOT.TH1D, ROOT.xH1D),
  File "/usr/local/lib/ROOT.py", line 470, in __getattr2
    raise AttributeError( name )
AttributeError: xH1D

Will try a more stable Xubuntu that hopefully has a different software chain.

[goatface]

Xubuntu Linux (16.04, Xenial Xerus)

gcc-5.4.0

python 2.7.12

Tk is 8.6 (cannot get away from it)

ROOT again 6.12.04

daid@nightmare:~/Downloads/GRUTinizer$ grutinizer -g /mnt/manjaro/home/daid/physics/analysis_code/nscl15151/hist/crdc_y_calib/raw/0061.root 
Getline_color/ColorFromName: cannot parse color #CCCC00!
(TFile *) 0x33694e0
	file /mnt/manjaro/home/daid/physics/analysis_code/nscl15151/hist/crdc_y_calib/raw/0061.root opened as _file0
GRizer [0] Error in <TProtoClass::FindDataMember>: data member with index 0 is not found in class thread
Error in <CreateRealData>: Cannot find data member # 0 of class thread for parent StoppableThread!
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1540, in __call__
    return self.func(*args)
  File "pygui/hist_tab.py", line 45, in OnHistClick
    for name in event.widget.selection()}
  File "pygui/hist_tab.py", line 45, in <dictcomp>
    for name in event.widget.selection()}
  File "pygui/util.py", line 57, in __getitem__
    (ROOT.TH1D, ROOT.xH1D),
  File "/home/daid/Downloads/root_bin12/lib/ROOT.py", line 470, in __getattr2
    raise AttributeError( name )
AttributeError: xH1D

Distro and install suggestions for OS welcome.

[brandonelman]

I just installed it for windows bash (which is Ubuntu 16.04.3 LTS) on the root6 branch using:

Root 6.12.04
gcc 5.4.0
python 2.7.12

I just download python-tk from the package manager. I also have python3 installed as well, but it's python2 I have linked against root.

I get a similar error when I use grutinizer on histogram files:

GRizer [0] Error in <TProtoClass::FindDataMember>: data member with index 0 is not found in class thread 
Error in <CreateRealData>: Cannot find data member # 0 of class thread for parent StoppableThread!
pure virtual method called
terminate called without an active exception
Aborted (core dumped)

However, I can successfully open histograms. It only terminates with the exception if I close all open canvases after opening the first one. I do not receive the xH1D error.

I don't have this same issue on my work computer using a slightly older version of ROOT (6.06.08). Might be worth downgrading to this version of root instead.

[goatface]

Sorry this information is all wrong! I made a dumb mistake. Ignore contents as it is an unrelated issue of hadd.cxx which can be resolved. I had a relic version from a newer version of ROOT lurking inside GRUTinizer.

Thanks for the suggestion concerning ROOT versions. I went ahead and made a trial of it, with null results.

It turns out that downgrading ROOT below 6.12 is not possible with the current GRUTinizer. You will get this error during compile:

Compiling .build/util/hadd.o                  [ERROR]
util/hadd.cxx:74:10: fatal error: ROOT/TIOFeatures.hxx: No such file or directory
 #include "ROOT/TIOFeatures.hxx"
          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [makefile:146: .build/util/hadd.o] Error 1

See for example TIOFeatures.cxx source code where the creation time is 09/2017. Thus, this required feature is not present in ROOT 6.10 and earlier.

I expect you cannot build GRUTinizer on your work computer if you were to sync with github.

[brandonelman]

One thing I should point out is that if you download the ROOT version I recommended (6.06.08) you may need to downgrade your GCC version, because I've found on my home computer that installing ROOT version previous to 6.08.10 fails for the most recent versions of GCC. The version of GCC on my work computer is 4.9.2.

[goatface]

I tried ROOT 6.08/06 and while some of the early errors are averted the basic issue of Tkinter remains.

daid@nightmare ~/physics/analysis_code/nscl15151 % ./view.sh hist/crdc_y_calib/check/0032.root
(TFile *) 0x55c5cb423ca0
        file hist/crdc_y_calib/check/0032.root opened as _file0
GRizer [0] Warning in <TClass::TClass>: no dictionary for class thread is available

GRizer [0] Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1541, in __call__
    return self.func(*args)
  File "/home/daid/physics/GRUTinizer/GRUTinizer/pygui/hist_tab.py", line 45, in OnHistClick
    for name in event.widget.selection()}
  File "/home/daid/physics/GRUTinizer/GRUTinizer/pygui/hist_tab.py", line 45, in <dictcomp>
    for name in event.widget.selection()}
  File "/home/daid/physics/GRUTinizer/GRUTinizer/pygui/util.py", line 57, in __getitem__
    (ROOT.TH1D, ROOT.xH1D),
  File "/usr/local/lib/ROOT.py", line 449, in __getattr2
    raise AttributeError( name )
AttributeError: xH1D

I chose that because ROOT 6.06/08 wasn't displayed on the ROOT download page.

I can say that I did successfully get ROOT 6.08/06 to compile with GCC 7.

I can try a 6.04 or 6.06 series.

[goatface]

ROOT 6.04/18 indeed fails to compile with GCC 7.2.1.

Should still have Xubuntu 16.04 with gcc-5 installed on another partition, so I will try one of these lower ROOT versions over there later tonight if I can.

[goatface]

From Xubuntu 16.04 I cannot build ROOT 6.04/18.

[ 62%] Building CXX object math/mathmore/CMakeFiles/MathMore.dir/src/GSLRootFinder.cxx.o
[ 62%] Building CXX object math/mathmore/CMakeFiles/MathMore.dir/src/GSLNLSMinimizer.cxx.o
In file included from /home/daid/Downloads/root-6.04.18/math/mathmore/src/GSLNLSMinimizer.cxx:19:0:
/home/daid/Downloads/root-6.04.18/math/mathmore/src/GSLMultiFit.h: In member function ‘const double* ROOT::Math::GSLMultiFit::Gradient() const’:
/home/daid/Downloads/root-6.04.18/math/mathmore/src/GSLMultiFit.h:146:38: error: ‘struct gsl_multifit_fdfsolver’ has no member named ‘J’
       gsl_multifit_gradient(fSolver->J, fSolver->f,fVec);
                                      ^
/home/daid/Downloads/root-6.04.18/math/mathmore/src/GSLMultiFit.h: In member function ‘const double* ROOT::Math::GSLMultiFit::CovarMatrix() const’:
/home/daid/Downloads/root-6.04.18/math/mathmore/src/GSLMultiFit.h:157:45: error: ‘struct gsl_multifit_fdfsolver’ has no member named ‘J’
       int ret = gsl_multifit_covar(fSolver->J, kEpsrel, fCov);
                                             ^
math/mathmore/CMakeFiles/MathMore.dir/build.make:776: recipe for target 'math/mathmore/CMakeFiles/MathMore.dir/src/GSLNLSMinimizer.cxx.o' failed
make[2]: *** [math/mathmore/CMakeFiles/MathMore.dir/src/GSLNLSMinimizer.cxx.o] Error 1
CMakeFiles/Makefile2:12961: recipe for target 'math/mathmore/CMakeFiles/MathMore.dir/all' failed
make[1]: *** [math/mathmore/CMakeFiles/MathMore.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
daid@nightmare:~/Downloads/root-6.04.18/build$ 

The above error might be solvable by poking at GSL or similar but it is not promising for the 6.04 series.

How about ROOT 6.06/08:

daid@nightmare:~/Downloads/root-6.06.08/build$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The Fortran compiler identification is GNU 5.4.0
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- Found GCC. Major version 5, minor version 4
-- Performing Test CXX_SUPPORTS_OLD_ABI
-- Performing Test CXX_SUPPORTS_OLD_ABI - Failed
CMake Error at cmake/modules/CheckCompiler.cmake:61 (message):
  Found GCC compiler with new ABI.  Cling does not support the GCC 5 ABI yet
Call Stack (most recent call first):
  CMakeLists.txt:35 (include)


-- Configuring incomplete, errors occurred!
See also "/home/daid/Downloads/root-6.06.08/build/CMakeFiles/CMakeOutput.log".
See also "/home/daid/Downloads/root-6.06.08/build/CMakeFiles/CMakeError.log".
daid@nightmare:~/Downloads/root-6.06.08/build$ 

This case at least explicitly manages to complain about the compiler version before getting too far along.

Downgrading to GCC-4 is liable to break this (or another) system, so I have to consider what I could do.

So far I was staying away from Gentoo Linux to (supposedly) save myself time, but it's a distro which is very capable of having lots of GCC versions installed at the same time. Going to Ubuntu 2014 seems backwards, and I got a new computer because my old laptop had 2013-era software and everything was slowly breaking.

Will try with

sudo apt-get install gcc-4.9 g++-4.9

And see if it is easy to use or not.

(Rather than trying in Xubuntu, I went back to Arch linux to try a similar option. In my Manjaro (Arch), the kernel and userspace are more sane at the moment. But also I'm favorable to Xubuntu when it uses the base software but not as much a fan for the hacking business over there. Updates as and when!)

[goatface]

Well, that didn't go so well. I had exported CC and CXX as the gcc-4.9 and g++-4.9 etc, and it was recognized by cmake as such.

I set it up like this (after installing the gcc 4.9)

daid@nightmare ~/downloads/root-6.06.08/cmake % which gcc-4.9
/usr/bin/gcc-4.9
daid@nightmare ~/downloads/root-6.06.08/cmake % which g++-4.9
/usr/bin/g++-4.9
daid@nightmare ~/downloads/root-6.06.08/cmake % export CC=/usr/bin/gcc-4.9
daid@nightmare ~/downloads/root-6.06.08/cmake % export CXX=/usr/bin/g++-4.9
daid@nightmare ~/downloads/root-6.06.08/cmake % cmake -D PYTHON_EXECUTABLE=/usr/bin/python2 ..
-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is GNU 4.9.3
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-4.9
-- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at cmake/modules/RootNewMacros.cmake:8 (cmake_policy):
  The OLD behavior for policy CMP0022 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all 
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW 
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:34 (include)


-- The Fortran compiler identification is GNU 7.2.1
-- Check for working Fortran compiler: /usr/bin/gfortran

True, that gfortran version (it sees gcc-7) is suspicious and could cause chaos, but I'm really not sure we're gonna be using fortran anyway. Everything else looked okay to me.

Eventually a nasty error occurs, and it spools for several pages but I just quote the top and bottom...

Scanning dependencies of target RLDAP
[ 82%] Building CXX object net/ldap/CMakeFiles/RLDAP.dir/G__LDAP.cxx.o
[ 82%] Building CXX object net/ldap/CMakeFiles/RLDAP.dir/src/TLDAPAttribute.cxx.o
[ 82%] Building CXX object net/ldap/CMakeFiles/RLDAP.dir/src/TLDAPEntry.cxx.o
[ 82%] Building CXX object net/ldap/CMakeFiles/RLDAP.dir/src/TLDAPResult.cxx.o
[ 82%] Building CXX object net/ldap/CMakeFiles/RLDAP.dir/src/TLDAPServer.cxx.o
[ 82%] Linking CXX shared library ../../lib/libRLDAP.so
[ 82%] Built target RLDAP
Scanning dependencies of target NetxNG
[ 82%] Building CXX object net/netxng/CMakeFiles/NetxNG.dir/G__NetxNG.cxx.o
[ 82%] Building CXX object net/netxng/CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o
[ 82%] Building CXX object net/netxng/CMakeFiles/NetxNG.dir/src/TNetXNGFileStager.cxx.o
[ 82%] Building CXX object net/netxng/CMakeFiles/NetxNG.dir/src/TNetXNGSystem.cxx.o
[ 82%] Linking CXX shared library ../../lib/libNetxNG.so
CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `XrdCl::XRootDStatus::ToStr() const':
/usr/include/xrootd/XrdCl/XrdClXRootDResponses.hh:261: undefined reference to `XrdCl::Status::ToString() const'
/usr/include/xrootd/XrdCl/XrdClXRootDResponses.hh:261: undefined reference to `XrdCl::Status::ToString() const'
CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `TNetXNGFile::ReOpen(char const*)':
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:350: undefined reference to `XrdCl::File::Open(std::string const&, XrdCl::OpenFlags::Flags, XrdCl::Access::Mode, unsigned short)'
CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `XrdCl::XRootDStatus::ToStr() const':
/usr/include/xrootd/XrdCl/XrdClXRootDResponses.hh:261: undefined reference to `XrdCl::Status::ToString() const'
CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `TNetXNGFile::GetVectorReadLimits()':
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:715: undefined reference to `XrdCl::File::GetProperty(std::string const&, std::string&) const'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:717: undefined reference to `XrdCl::URL::URL(std::string const&)'
CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `TNetXNGFile::SetEnv()':
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:771: undefined reference to `XrdCl::Env::PutInt(std::string const&, int)'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:776: undefined reference to `XrdCl::Env::PutInt(std::string const&, int)'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:781: undefined reference to `XrdCl::Env::PutInt(std::string const&, int)'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:786: undefined reference to `XrdCl::Env::PutInt(std::string const&, int)'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:791: undefined reference to `XrdCl::Env::PutInt(std::string const&, int)'
CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o:/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGFile.cxx:796: more undefined references to `XrdCl::Env::PutInt(std::string const&, int)' follow

inserted garbage spool

::PrepareFlags::Flags, unsigned char, XrdCl::Buffer*&, unsigned short)'
CMakeFiles/NetxNG.dir/src/TNetXNGSystem.cxx.o: In function `TNetXNGSystem::Locate(char const*, TString&)':
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGSystem.cxx:331: undefined reference to `XrdCl::URL::URL(std::string const&)'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGSystem.cxx:335: undefined reference to `XrdCl::FileSystem::Locate(std::string const&, XrdCl::OpenFlags::Flags, XrdCl::LocationInfo*&, unsigned short)'
/home/daid/downloads/root-6.06.08/net/netxng/src/TNetXNGSystem.cxx:343: undefined reference to `XrdCl::URL::URL(std::string const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [net/netxng/CMakeFiles/NetxNG.dir/build.make:195: lib/libNetxNG.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:16168: net/netxng/CMakeFiles/NetxNG.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

It should be worth confirming on the Xubuntu 16.04 system in the future (or checking if the build errors look obvious, didn't even google.)

That's it for me just now. Any ideas? Thanks!

Updates: This is a known issue so it seems I may need to compile xrootd (or other dependencies) with GCC4 as well. I'm not sure how far down the rabbit hole I have to go (I don't even remember how / if xrootd is installed).

From /var/log/pacman.log

[2018-01-16 13:31] [PACMAN] Running 'pacman --color auto -U --asdeps /tmp/yaourt-tmp-daid/PKGDEST.nhM/xrootd-4.7.1-3-x86_64.pkg.tar.xz'
[2018-01-16 13:31] [ALPM] transaction started
[2018-01-16 13:31] [ALPM] installed xrootd (4.7.1-3)

Trying to compile XROOTD with gcc-4.9 series yields a cmake error.

==> Starting prepare()...
  -> Configuring...
CMake Deprecation Warning at CMakeLists.txt:7 (CMAKE_POLICY):
  The OLD behavior for policy CMP0022 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is GNU 4.9.3
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- broken
CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
  The C compiler

    "/usr/bin/gcc-4.9"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/daid/distfiles/xrootd/src/build/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/bin/make" "cmTC_d7da6/fast"
    /usr/bin/make -f CMakeFiles/cmTC_d7da6.dir/build.make CMakeFiles/cmTC_d7da6.dir/build
    make[1]: Entering directory '/home/daid/distfiles/xrootd/src/build/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_d7da6.dir/testCCompiler.c.o
    /usr/bin/gcc-4.9   -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt    -o CMakeFiles/cmTC_d7da6.dir/testCCompiler.c.o   -c /home/daid/distfiles/xrootd/src/build/CMakeFiles/CMakeTmp/testCCompiler.c
    gcc-4.9: error: unrecognized command line option ‘-fno-plt’
    make[1]: *** [CMakeFiles/cmTC_d7da6.dir/build.make:66: CMakeFiles/cmTC_d7da6.dir/testCCompiler.c.o] Error 1
    make[1]: Leaving directory '/home/daid/distfiles/xrootd/src/build/CMakeFiles/CMakeTmp'
    make: *** [Makefile:126: cmTC_d7da6/fast] Error 2

We can check this, but basically the fno-plt compiler flag is for gcc6 and higher so I have to find a work around.

The package builder was using my system flags so I stripped fno-plt out of CFLAGS and CXXFLAGS. This was very sloppy in the bash-style package build instruction, but it can work:

    export CFLAGS=$(echo "$CFLAGS" | sed 's/-fno-plt//')
    export CXXFLAGS=$(echo "$CXXFLAGS" | sed 's/-fno-plt//')

It's probably why we cannot have nice things in life because we break them. Still, we can hope it propagates/works/something. (This debugging process is brought to you by someone who has forcibly downgraded glibc and crashed the entire boot sequence in his life.)

I get a build error anyway:

[ 19%] Linking CXX shared library libXrdUtils.so
[ 19%] Built target XrdUtils
Scanning dependencies of target XrdCephPosix
[ 19%] Building CXX object src/CMakeFiles/XrdCephPosix.dir/XrdCeph/XrdCephPosix.cc.o
/home/daid/distfiles/xrootd/src/xrootd-4.4.0/src/XrdCeph/XrdCephPosix.cc:68:13: error: ‘ObjectIterator’ in namespace ‘librados’ does not name a type
   librados::ObjectIterator m_iterator;
             ^
/home/daid/distfiles/xrootd/src/xrootd-4.4.0/src/XrdCeph/XrdCephPosix.cc: In function ‘DIR* ceph_posix_opendir(XrdOucEnv*, const char*)’:
/home/daid/distfiles/xrootd/src/xrootd-4.4.0/src/XrdCeph/XrdCephPosix.cc:1095:8: error: ‘struct DirIterator’ has no member named ‘m_iterator’
   res->m_iterator = ioctx->objects_begin();
        ^

I had tried to match XROOTD version to a release date similar with ROOT 6.06/08. Okay well it couldn't work, so I try instead the latest XROOTD:

Scanning dependencies of target python_target
[100%] Generating python_bindings
XRootD library dir:     /home/daid/distfiles/xrootd/src/build/src
XRootD src include dir: /home/daid/distfiles/xrootd/src/xrootd-4.8.1/src
XRootD bin include dir: /home/daid/distfiles/xrootd/src/build/src
Version:                v4.8.1
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/pyxrootd
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/src/__init__.py -> build/lib.linux-x86_64-2.7/pyxrootd
creating build/lib.linux-x86_64-2.7/XRootD
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/__init__.py -> build/lib.linux-x86_64-2.7/XRootD
creating build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/filesystem.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/utils.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/file.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/responses.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/flags.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/copyprocess.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/__init__.py -> build/lib.linux-x86_64-2.7/XRootD/client
copying /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/libs/client/url.py -> build/lib.linux-x86_64-2.7/XRootD/client
running build_ext
building 'pyxrootd.client' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/home
creating build/temp.linux-x86_64-2.7/home/daid
creating build/temp.linux-x86_64-2.7/home/daid/distfiles
creating build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd
creating build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd/src
creating build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd/src/xrootd-4.8.1
creating build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings
creating build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python
creating build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/src
/usr/bin/gcc-4.9 -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIC -I/home/daid/distfiles/xrootd/src/xrootd-4.8.1/src -I/home/daid/distfiles/xrootd/src/build/src -I/usr/include/python2.7 -c /home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/src/PyXRootDCopyProcess.cc -o build/temp.linux-x86_64-2.7/home/daid/distfiles/xrootd/src/xrootd-4.8.1/bindings/python/src/PyXRootDCopyProcess.o -g
gcc-4.9: error: unrecognized command line option ‘-fno-plt’
error: command '/usr/bin/gcc-4.9' failed with exit status 1
make[2]: *** [bindings/python/CMakeFiles/python_target.dir/build.make:62: bindings/python/python_bindings] Error 1
make[1]: *** [CMakeFiles/Makefile2:2901: bindings/python/CMakeFiles/python_target.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

It's stuck in the -fno-plt flag again at a later stage. An automatically generated setup.py is doing this. I have extracted and simplified the relevant code, and I can see somehow python knows what compiler flags it was compiled with, and it insists we have to use them too. Example file:

from __future__ import print_function

from distutils.core import setup, Extension
from distutils import sysconfig
from os import getenv, walk, path
import subprocess

# Remove the "-Wstrict-prototypes" compiler option, which isn't valid for C++.
cfg_vars = sysconfig.get_config_vars()
opt = cfg_vars["OPT"]
cfg_vars["OPT"] = " ".join( flag for flag in opt.split() if flag not in ['-Wstrict-prototypes'  ] ) 

cflags = cfg_vars["CFLAGS"]
cfg_vars["CFLAGS"] = " ".join( flag for flag in cflags.split() if flag not in ['-Wstrict-prototypes'  ] ) 

py_cflags = cfg_vars["PY_CFLAGS"]
cfg_vars["PY_CFLAGS"] = " ".join( flag for flag in py_cflags.split() if flag not in ['-Wstrict-prototypes'  ] ) 

print(cflags)

An example of using the above pseudo-code is as:

daid@nightmare /tmp % python2 setup.py
-fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong

In this above example, we can see the -fno-plt flag being output by a python2 call. So we can begin to modify the system and check it directly rather than waiting for the compile crash. I kick the system with a combination of sudo, grep, python documentation, and google, until I get an output without fno-plt, described presently.

So I have to modify the distutils.core sysconfig. I forcibly delete all instances of the -fno-plt flag from /usr/lib/python2.7/_sysconfigdata.py but I don't really suggest this as a safe policy. (NB: WE SHOULD REALLY BE USING pythonz AT THIS POINT!! I CONTINUE SMASHING MY FACE AGAINST THESE FUNDAMENTAL ISSUES TO ALSO TEST SYSTEM STABILITY.)

Continuing along freshly compiling ROOT 6.06/08, but it fails at a linking stage now against Pythia which I'll have to also recompile from source:

Scanning dependencies of target EGPythia8
[ 95%] Building CXX object montecarlo/pythia8/CMakeFiles/EGPythia8.dir/G__Pythia8.cxx.o
[ 95%] Building CXX object montecarlo/pythia8/CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o
[ 95%] Building CXX object montecarlo/pythia8/CMakeFiles/EGPythia8.dir/src/TPythia8Decayer.cxx.o
[ 95%] Linking CXX shared library ../../lib/libEGPythia8.so
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `TPythia8::TPythia8()':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:100: undefined reference to `Pythia8::Pythia::Pythia(std::string, bool)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `TPythia8::TPythia8(char const*)':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:117: undefined reference to `Pythia8::Pythia::Pythia(std::string, bool)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `TPythia8::ReadString(char const*) const':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:299: undefined reference to `Pythia8::Pythia::readString(std::string, bool)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `TPythia8::ReadConfigFile(char const*) const':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:307: undefined reference to `Pythia8::Pythia::readFile(std::string, bool, int)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `Pythia8::Settings::listAll()':
/usr/include/Pythia8/Settings.h:225: undefined reference to `Pythia8::Settings::list(bool, bool, std::string)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `Pythia8::Settings::listChanged()':
/usr/include/Pythia8/Settings.h:226: undefined reference to `Pythia8::Settings::list(bool, bool, std::string)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `TPythia8::Initialize(int, int, double)':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:149: undefined reference to `Pythia8::Settings::mode(std::string, int, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:150: undefined reference to `Pythia8::Settings::mode(std::string, int, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:151: undefined reference to `Pythia8::Settings::mode(std::string, int, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:152: undefined reference to `Pythia8::Settings::parm(std::string, double, bool)'
CMakeFiles/EGPythia8.dir/src/TPythia8.cxx.o: In function `TPythia8::Initialize(int, int, double, double)':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:167: undefined reference to `Pythia8::Settings::mode(std::string, int, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:168: undefined reference to `Pythia8::Settings::mode(std::string, int, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:169: undefined reference to `Pythia8::Settings::mode(std::string, int, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:170: undefined reference to `Pythia8::Settings::parm(std::string, double, bool)'
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8.cxx:171: undefined reference to `Pythia8::Settings::parm(std::string, double, bool)'
CMakeFiles/EGPythia8.dir/src/TPythia8Decayer.cxx.o: In function `TPythia8Decayer::TPythia8Decayer()':
/home/daid/downloads/root-6.06.08/montecarlo/pythia8/src/TPythia8Decayer.cxx:32: undefined reference to `Pythia8::Pythia::readString(std::string, bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [montecarlo/pythia8/CMakeFiles/EGPythia8.dir/build.make:175: lib/libEGPythia8.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:19654: montecarlo/pythia8/CMakeFiles/EGPythia8.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Time delay. Already backed up the old pythia install as a binary package, but may leave off the root hacking for today.

[brandonelman]

I am still unsure why your first attempt (with newer GCC and most recent ROOT) did not work due to TKinter. It worked for me on a relatively similar system and I was unable to reproduce your xH1D error. My installation of tkinter was also extremely simple, I just downloaded python-tk from the package manager.

While I did get the TProtoClass error that somehow leads to crashing GRUTinizer if I close certain canvases, I was still able to open histogram files and do anything else I wanted with them,

[goatface]

Thanks again for your help. Sorry I was a bit busy with other work in the mean time.

I never got around to going further with gcc-4.9 but I think my system would have ended up a bit funky.

I, too, just installed python-tk from package manager, etc. I only had to customize ROOT re: python2 (on this install) which was really no big deal.

I went through and did things again with the most recent versions of code (gcc-7, root 6.12). Although I cannot use the GUI panel, it seems I can analyze and view the data on this computer.

By the way, if you would like to rule out the Tkinter version, here is how I was checking.

daid@nightmare ~ % python2
Python 2.7.14 (default, Sep 20 2017, 01:25:59) 
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> Tkinter.TkVersion
8.6
>>> quit()

There were some other minor issues I documented and found workarounds for. Some of them are likely known to you all at NSCL, for example with libraries/TLoops/TFilterLoop.cxx make_unique gets overloaded because recent GCC provides it. (Workaround was pretty easy.)

Let me get on with things a bit, and then if there were any useful solutions to simple problems I can raise and close that weren't covered elsewhere, I will make individual issues with solutions.

[brandonelman]

I think I figured out the issue you are having.

Are you attempting to compile the master branch or the root6 branch?

If you are attempting to compile the master branch, things will never quite work because you are on root6. If you are using root6 you must use the root6 branch and ignore the master branch.

If you prefer the master branch, you must use root5.

[goatface]

I am using master branch. Until you said so, I did not realize there are SO MANY BRANCHES.

I will give a try with root6 branch.

Thanks again!