ROOT v6.06.00 on Ubuntu 14.04

Here’s my “report” from building ROOT v6.06.00 on Ubuntu 14.04.3 LTS / x86_64 (gcc 4.8.4) using cmake (2.8.12.2).

To my surprise, cmake driven configuration enabled “builtin_ftgl” and “builtin_glew” (though I have all required system default packages installed).

The cmake driven configuration enabled also “r”, even though it explicitly noticed that “RInside” package was not found (I did have the system default “R 3.0.2” and “Rcpp 0.11.0” installed, but Ubuntu does not provide the “RInside” package). Several hours later, “cmake --build” died with an error that “RInside.h” was not found. :-&

So, I installed the “RInside” (“0.2.13”) package from “cran”, and restarted everything from scratch again. And again, “r” was enabled (this time without reporting any problems). Several hours later, “cmake --build” died with a compile time error related to “Rcpp”. :-&
Ubuntu 14.04 provides the “r-cran-rcpp” package version “0.11.0-1”, which was fine for “RInside”, but apparently ROOT breaks on it.

So, I purged the system default r-cran-rcpp" package and installed “Rcpp” (“0.12.2”) from “cran” and restarted everything from scratch again. After additional several hours … I finally got the new ROOT built. =D>

Afterwards, I tried “–target install” and it did copy files to the required place, but I noticed I needed to fix permissions: cd /Where/I/Installed/ROOT chmod a+x bin/rootbrowse bin/rootcp bin/rooteventselector bin/rootls \ bin/rootmkdir bin/rootmv bin/rootprint bin/rootrm chmod a-x bin/setxrd.* bin/thisroot.*
Moreover, the “bin/memprobe” script seems to be broken. The very first line contains just “#!”.

Hi Pepe,

The permission problem for rootbrowse and co. has been solved in the patch branch.

Can you fill a separate JIRA report for each of the 5 other issues (“builtin_ftgl” incorreclty used, “builtin_glew” incorreclty used, RInside missing not detected, “r-cran-rcpp” package version “0.11.0-1” not supported (and not dectected as such), “bin/memprobe” script seems to be broken) ?

Thanks,
Philippe.

Thanks very much for the report.

It is true that “builtin_ftgl” and “builtin_glew” are enabled by default (as it was in the classic configure.make). Can you make test for me and see if you disable them if you manage to build correctly.

Is not clear to me if you need to do something for R in order to improve building the dependent ROOT components.

The permissions for the new command line tools when installing have already been fixed.

For memprobe I have created a JIRA ticket sft.its.cern.ch/jira/browse/ROOT-7867

I have forgotten to mention another problem. I believe that, when cmake is used, the original source code should not be touched. However, I have found that the cmake configuration step creates the following files in the original source code subdirectories:

Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: componentinfo.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: configutil.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: init.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: main.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: util.pyc

BTW. Note that it’s not only “a+x” for “the new command line tools” but also “a-x” for some old scripts.

I added “-Dbuiltin_ftgl=OFF -Dbuiltin_glew=OFF” to the cmake configuration step.
It did find my FTGL, reporting:
– Found FTGL: /usr/include
I could NOT find any trace of searching for my GLEW (but the “builtin_glew” was NOT built).
ROOT seems to be built fine (I tried to draw a TH2 with “glbox” and “glsurf” and both seem to work fine, too).

[quote] have forgotten to mention another problem. I believe that, when cmake is used, the original source code should not be touched. However, I have found that the cmake configuration step creates the following files in the original source code subdirectories:

Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: componentinfo.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: configutil.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: init.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: main.pyc
Only in root-6.06.00/interpreter/llvm/src/utils/llvm-build/llvmbuild: util.pyc[/quote]

This is sort of normal. When executing python scripts, the Python interpreter tries to cache the bytecode in .pyc files if permissions allow.

So, you should either prevent python from doing it or you should copy these files to the cmake “build tree” and let it modify them there.

BTW. The new ROOT building instructions seem to require a cmake “build tree” which is separate from the “source tree”. There is nothing in cmake that requires it, I think. So, it should be possible to build it “in place”, as well.

The .pyc files are only created if they can be created, otherwise Python can work without them normally. We cannot copy these files to another place because we use the LLVM build instructions based on CMake directly without modification for obvious reasons (maintenance). If this is still a problem for you, you can set the variable PYTHONDONTWRITEBYTECODE to avoid it (see docs.python.org/3.4/using/cmdline.html)

We have disabled building in sources because is not recommended by CMake although is possible, and indeed creates problems when creating an environment for running in the source directory. I addition buildin for multiple compiler/platforms makes just a mess.

To the best of my knowledge, python bytecode is portable across platforms, but not really across python versions.
To me that means that if you allow one python to create it in the cmake “source tree” then that “source tree” should be deleted afterwards, as it is not safe to reuse it.
It’s the responsibility of llvm maintainers to add protections in their building procedure (so that the “source tree” is not modified at all).

I’ve found another problem.
When I use “–all”, when calling the “configure” script, I get the “geocad” enabled (Ubuntu’s OpenCASCADE “oce-0.15-4”, include files in “/usr/include/oce”, libraries in “/usr/lib/x86_64-linux-gnu”).
This is NOT the case when I use “-Dall=ON”, when using the cmake based configuration (i.e. “geocad” remains “OFF” and is NOT tried at all).
Moreover, when I manually add “-Dgeocad=ON”, it breaks with a message:

– Could NOT find OCC (missing: OCC_INCLUDE_DIR)
– OpenCascade libraries not found. Set variable CASROOT to point to your OpenCascade installation
– For the time being switching OFF ‘geocad’ option

So, one needs to add yet another flag: "-DOCC_INCLUDE_DIR=/usr/include/oce"
Note: this was supposed to be fixed: sft.its.cern.ch/jira/browse/ROOT-7480