Re: root -p [or +P -P +p]

From: Martin Purschke (purschke@bnl.gov)
Date: Sat Mar 13 1999 - 15:09:55 MET


Hi Tony,

a few weeks ago, I had a similar problem with rootcint, which would choke on
the header files which had to be taken through the C++ preprocessor. On
Solaris, the preprocessed system header files would actually lead to
different definitions than what's in root's include files, and give a
zillion of errors. Masaharu's advice was to make the header files in such a
way that they would not need to be taken through the external preprocessor
at all, that's what we were able to do, and that worked. The problem is that
the internal Cint preprocessor can't handle arbitrary definitions (that's
the error you see)  but can deal with ifdef's and simple things.

Now a piece of good news is that on Linux, the g++ preprocessor happens to
give you Cint-compatible results (that's why our problem showed up only when
I tried it on Solaris). You might try to run it through the g++ preprocessor
by hand and feed root the results of that. Should give you a solution for
the time being until you figure out a better way. I append what Masaharu
told me:

> Martin,
>
> Concerned about using preprocessor with rootcint,
>
> >Now if I pretend to need some definitions and run with -p, I get
> >
> >> $ rootcint gheader.cc -c -p header.h LinkDef.h
> >> Error: No symbol
> >#"/export/software/pub/root/root_v2.20.06/cint/include/stdio.h"#"typedeflongf
> pos_t in current scope  FILE:TROOT.h LINE:4
>
> As far as I know, rootcint can not be used with preprocessor because
>  1) ROOT header files uses special macro and comments which are essential to
>    sharedlib integration. Using the preprocessor strips those important
>    information.
>  2) As you observed with Soraris2.6, some preprocessor generates unexpected
>    lines in the output file.
>
> >We tried to fiddle around with running the preprocessor manually on the
> >files and feeding the processed files to rootcint, trying to avoid the
> >need for preprocessing in rootcint, but that creates more problems than
> >it solves.
>
> This does not help. The situation is the same.
>
> Will you inform the development team why you need to use preprocessor?
> What expression do you need preprocessing?  We might be able to suggest
> something then.
>
> Masaharu Goto
>
Good luck
    Martin

Tony Peden wrote:

> I am trying to load the headers for a shared library but the root
> preprocessor can't handle
> some of the macros in them.  So I tried using the -p option but get a
> similar message
> as without:
>    Processing FGFDMExec.h...
>    Limitation: can not handle macro __STL_CATCH_ALL if(false) Use +P or
> -p option
>    FILE:/usr/include/g++/stl_config.h LINE:236
>    *** Interpreter error recovered ***
>    NULL
> I have tried this with  .x, and root -p FGFDMExec.h; all give the same
> result.
> This has lead me to believe that root isn't actually trying to use the
> g++ preprocessor
> after all.  I believe my $ROOTSYS/cint/MAKEINFO file is set up
> correctly, it sets
> CPPPREP = g++ -E, and is unchanged from the binary distribution.  I have
> also
> wondered if this problem is related to ROOT's STL limitations.
>
> This source is an active part of a larger project (see
> http://www.flightgear.org ) so changing
> it to accomodate ROOT is undesirable, but doable.
>
> I am using root 2.20/06 on RedHat Linux 5.1.
>
> Does anyone know how to get this to work (or a way to figure out why it
> doesn't) ?
>
> --
> Tony Peden
> apeden@nwlink.com
> "Core dumping fscks tend to make me nervous" -- Linus Torvalds

--
Martin L. Purschke               ;   purschke@bnl.gov
                                 ;   http://www.phenix.bnl.gov/~purschke
                                 ;
Brookhaven National Laboratory   ;   phone: +1-516-344-5244
Physics Department Bldg 510 C    ;   fax:   +1-516-344-3253
Upton, NY 11973-5000             ;
-----------------------------------------------------------------------



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:30 MET