Rootcint missing system include path?

ROOT
1

Hi,

I’m invoking rootcint via a Makefile to generate several dictionaries for a large project. This works fine on several different operating systems with different libraries and gcc versions, but I’ve run into one setup that is giving me weird errors. On Lubuntu 12.04, using gcc 4.6.3 and root 5.32 or 5.34, when I get to the rootcint call, I get:

rootcint -v -f Dictionaries.cc -c -I/home/bloer/darkside/daqman/daq/include -I/home/bloer/darkside/daqman/include -I/home/bloer/darkside/daqman/cuts/include -I/home/bloer/darkside/daqman/analysis/include -I/home/bloer/darkside/daqman/CAENVMElib/include -I/home/bloer/darkside/daqman/ConfigHandler/include -I/home/bloer/darkside/daqman/modules/include -I/home/bloer/darkside/daqman/mc/include -I/home/bloer/darkside/daqman -I/sw/include -I/home/bloer/darkside/daqman  -I/usr/include/malloc -I/usr/include/mysql -I/usr/include/mysql++ -I/usr/local/include/mysql -I/usr/local/include/mysql++ doc/mainpage.h analysis/include/LightYieldCorrection.hh analysis/include/RunDB.hh analysis/include/utilities.hh analysis/include/LightYield.hh modules/include/Spe.hh modules/include/Roi.hh modules/include/ChannelData.hh modules/include/PulseFit.hh modules/include/Baseline.hh modules/include/EventData.hh modules/include/Pulse.hh mc/include/MCOpticalEvent.hh LinkDef.h 
Error: cannot open file "bits/predefs.h"  /usr/include/features.h:325:
Error: cannot open file "gnu/stubs.h"  /usr/include/features.h:390:
Error: cannot open file "bits/wchar.h"  /usr/include/stdint.h:28:
Error: cannot open file "bits/wordsize.h"  /usr/include/stdint.h:29:
Note: File "modules/include/Spe.hh" already loaded
Note: File "modules/include/Roi.hh" already loaded
Note: File "modules/include/ChannelData.hh" already loaded
Note: File "modules/include/PulseFit.hh" already loaded
Note: File "modules/include/Baseline.hh" already loaded
Note: File "modules/include/Pulse.hh" already loaded
Warning: Error occurred during reading source files
Warning: Error occurred during dictionary source generation
!!!Removing Dictionaries.cc Dictionaries.h !!!
Error: rootcint: error loading headers...

A few of my classes include the “stdint.h” header, which includes some of the other system headers mentioned in the error list. The “bits” and “gnu” folders referenced are under /usr/include/i386-linux-gnu , which is included in gcc’s default search path:

bloer@lubuntuvm:~$ gcc -v -x c++ -E - <snip> ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.6/../../../../i686-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.6 /usr/include/c++/4.6/i686-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/i686-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/i686-linux-gnu/4.6/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list.

It seems most of the time the “bits” and “gnu” folders are under /usr/include directly, so rootcint may just not find them where it expects?

So, is this expected behavior for what may be a slightly non-standard include path setup, or is something weird? I would expect that rootcint would get the system include path from gcc somehow…

Thanks,
~Ben

2

Hi Ben,

A priori rootcint should not be looking nor parsing the bits and gnu headers. Do not pass any -I/usr/include to rootcint.

If you find that those are seemingly necessary, you need instead to use the external preprocessor when running rootcint (by passing the -p option).

Cheers,
Philippe.

3

Hi Philippe,

Thanks for the feedback. I confess this sounds like a workaround to me. My reasoning is this:
Take this simple class:

#include "Rtypes.h"
#include <stdint.h>

class MyClass{
public:
  MyClass() {}
  virtual ~MyClass() {}
private:
  uint64_t bitmask;

  ClassDef(MyClass,1)
};

stdint.h is a system header that happens to reference some other headers in the “bits” and “gnu” subfolders.

I can compile that class without specifying any additional include ("-I") directives:

Now if I try to call rootcint without specifying anything extra:

This succeeds if the “bits” and “gnu” folders are under /usr/include (or symlinked), but not if they happen to be in some other path, even though gcc clearly knows about that path.

So clearly rootcint knows something about the most common system directories, since it can find them in /usr/include; I was surprised to hear that it didn’t have some more automatic mechanism to search all the default include directories.

Cheers,
~Ben

4

Hi,

[quote]This succeeds if the “bits” and “gnu” folders are under /usr/include (or symlinked), but not if they happen to be in some other path, even though gcc clearly knows about that path … all the default include directories. [/quote]Arguably, only ‘/usr/include’ is the default location. CINT could indeed have been upgraded to also interrogate the currently available version of gcc to ask where its header files are stored. However since we are no longer adding new feature to CINT (instead we are focusing on its successor, Cling), you have to rely on the current CINT implementation of making sure it looks in the correct header file location … which is to use the external preprocessor (by passing the -p option).

Cheers,
Philippe.