I’ve been trying to get some of the old CDF Detector software to run in Scientific Linux 4 (ie RHEL 4). It was created for RedHat 7.3. I was able to get “regular” programs to compile by using the old gcc (2.96) and the old glibc (2.2). Everything seemed fine, until I tried to compile a program in ROOT. I get these really weird errors refering to the math library:
Error: Illegal initialization of __huge_val. Constructor exists FILE:/test/usr/include/bits/huge_val.h LINE:39
Error: Illegal initialization of __huge_valf. Constructor exists FILE:/test/usr/include/bits/huge_val.h LINE:63
Error: Illegal initialization of __huge_vall. Constructor exists FILE:/test/usr/include/bits/huge_val.h LINE:75
Error: Illegal initialization of __nan_union. Constructor exists FILE:/test/usr/include/bits/nan.h LINE:45
The program I’m trying to compile is really simple:
#include <iostream.h>
int main(){
cout<<“Hello World!\n”;
return 0;
}
If you have any ideas, I’d really appreicate it.
David
I am a little confused. You title quote Kai and then you also talk about using gcc 2.96. Then [quote]Everything seemed fine, until I tried to compile a program in ROOT.[/quote] but you example does not refer to ROOT at all.
So I am suspect that are not able to compile anything using KCC on SLC4. This is actually likely since KCC has a series of header than are intending to superseed part of the system header. However since this is only part of the system header, upgrading to a new system header usually requires upgrade to a new version (or patch) of the KAI compiler …
… The KAI compiler is not supported by its owner (now part of Intel Corp.) … so you would have to find the discrepancy and try to patch the existing headers …
I compiled the program in ROOT using gSystem->CompileMacro(“bgAna.cc”,“f”);
I was able to compile the program from the command line in KCC on SL4. It worked. It was happy. I’ve even been able to compile all of the CDF software with KCC on SL4. Again, no problems. I just needed to make sure that I changed where it thought the system headers could be found. So, I’m still using the same headers as in RH 7.3., and KCC’s “extra” headers superseed the same system headers.
However when I try to compile the program (or a more complex one that refers to root libraries) with KAI in ROOT, it fails.
Also, as a sidenote, KCC uses gcc somehow when compiling. I’m not sure why or how, but it does. When I use ROOT though, it doesn’t appear to need gcc. Go figure.
[quote]I just needed to make sure that I changed where it thought the system headers could be found. [/quote]Check $ROOTSYS/include/compiledata.h so see what ACLiC use to compile you may need to change this as well … However this file is created at when gmake runs but you can over-ride using gSystem->SetMakeSharedLibs and other functions.
[quote]Also, as a sidenote, KCC uses gcc somehow when compiling. I’m not sure why or how, but it does. When I use ROOT though, it doesn’t appear to need gcc. Go figure.[/quote]Actually ACLiC simply calls rootcint (which calls the C++ preprocessor) and then calls the compilers it thinks ROOT has been compiled with. You can see the actual command line by setting gDebug to 7.
If I replace the built in (SL4) glibc-devel and glibc-kernheaders packages with those from RH 7.3 , everything compiles correctly. This puts the packages in /usr/include, which makes ROOT happy. However when I point ROOT to the same include files, it comes up with errors. I think this suggests that I’m just not pointing root to the include files in the right way. How can I specify the system include directories to ROOT? Can this hopefully be done without recompiling root itself? Thanks for your help…
If I understood correctly, you just need to manipulate the value used by ACLiC to compile. See TSystem::GetMakeSharedLib and TSystem::SetMakeSharedLib.
Wow, thanks, it worked! I just added -I/path/to/include/files with SetMakeSharedLib.
Any ideas on how I could make this a “universal” thing (e.g, so every user wouldn’t have to have the command in their rootlogon.C file)? I thought about having a system-wide rootlogon.C, but I believe that wouldn’t get looked at if users had their own rootlogon.C’s.
The best would to insure it makes it into compiledata.h.
For that you only need be to recompile base/src/TSystem.o and libCore.so.
First remove include/compiledata.h
Second make sure that the needed -I is added to CXXFLAGS in the file config/Makefile.linux and do a gmake lib/libCore.so
Or just do a ‘gmake lib/libCore.so EXTRA_CXXFLAGS=-I…’
I thought everything was working…however when I use the TString class, problems occur.
These problems only seem to occur when using interpreted (not compiled) mode. I can initialize a TString object, but whenever I try to use some of the methods (i.e. TString::Append()), or even hit tab to see the method names, I get the error:
Error: operator- not defined for basic_ostream<char,char_traits > FILE:_iostream LINE:116
Error: << Illegal operator for pointer 3 FILE:_iostream LINE:116
*** Interpreter error recovered ***
I don’t get this error running RedHat 7 with the same root binary, so it must have to do with the headers that are getting included(?). Any ideas how to fix this? Does root require any headers other than those found in glibc? Thanks again.
Do you know when this change was introduced to the abs/fabs headers? (if I don’t want to recompile root, what’s the latest headers I could use that would work).
I think that he problem can be solved by copying the lastest version of cint/src/expr.c (at least cvs revision 1.61) into your version of ROOT and recompiling.
[quote]Any idea then, why it would work fine in RedHat 7.3 but not with the RedHat 7.3 libraries on SL 4?[/quote]Not really … as it is an issue with how ‘abs’ treat longs (it worked by accident before the fix) and the issue may be in the header file and/or in glibc.