we have a large number of #ifdef conditions throughout the code, which
must work on many platforms (and some of the code on realtime systems
such as VxWorks.) In addition, there are situations where actual
keywords such as inline, const, or static are #define'd to allow
compilation especially with cross-compilers.
Sun-Solaris is the only platform where rootcint has problems; on Linux,
SGI, and I believe on DEC Unix (where I didn't do the test myself) it
works fine with the -p option. Now if I had to work around that for the
benefit of the Sun compiler that would be a lot of work.
I wonder. So Cint in the end calls compiled code. But if the
rootcint-generated glue code uses a different set of header files for
its thing, isn't there the possibility of a mismatch between how
rootcint believes a function is prototyped and what the compiler thinks?
Maybe I got lucky and rootcint's headers are basically the same for GNU
on Linux so that it doesn't show? Again, I build the shared libs fine
with preprocessing there.
That's the situation... Did I mention that Sun/Solaris is one the two
main computing platforms in the PHENIX experiment (the other one is
Linux)? I hope there is a somewhat simple solution.
Cheers,
Martin
Masaharu Goto wrote:
>
> 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