CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Installation

Compile Error of OpenFOAM-2.2.0 on RedHat EL5

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree5Likes
  • 5 Post By wyldckat

Reply
 
LinkBack Thread Tools Display Modes
Old   March 6, 2013, 21:22
Default Compile Error of OpenFOAM-2.2.0 on RedHat EL5
  #1
Member
 
Masashi Ohbuchi
Join Date: Oct 2009
Posts: 72
Rep Power: 7
Ohbuchi is on a distinguished road
Hi, foamers.

I downloaded OpenFOAM-2.2.0, and tried to compile on my RedHat EL5 system. But building process for libOpenFOAM was failed with following error message;

primitives/triad/triad.C:36: error: expected initializer before '<' token
primitives/triad/triad.C:39: error: expected initializer before '<' token

What's the problem?
Any comments welcome.
Ohbuchi is offline   Reply With Quote

Old   March 6, 2013, 22:41
Default
  #2
Member
 
Masashi Ohbuchi
Join Date: Oct 2009
Posts: 72
Rep Power: 7
Ohbuchi is on a distinguished road
When I removed the 'triad ::' from line 36 and line 39 of triad.C, the compilation was successful.
Ohbuchi is offline   Reply With Quote

Old   March 8, 2013, 07:07
Default
  #3
Member
 
Pekka Pasanen
Join Date: Feb 2012
Location: Finland
Posts: 38
Rep Power: 5
zordiack is on a distinguished road
I experienced similar error in Xubuntu 12.10, i did the same fix and it compiled. However I'm a little concerned about removing triad:: from lines 36 and 39, could someone more C++ involved person inspect this and make a comment?
zordiack is offline   Reply With Quote

Old   March 8, 2013, 11:02
Default
  #4
Senior Member
 
Olivier
Join Date: Jun 2009
Location: France, grenoble
Posts: 235
Rep Power: 9
olivierG is on a distinguished road
hello,

Same here. Compilation work with gcc 4.5 and 4.6, not with gcc 4.7.2

Regards,
olivier
olivierG is offline   Reply With Quote

Old   March 9, 2013, 21:21
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,258
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings to all!

I'm not exactly an expert on C++ (there is a lot about C++ that I don't know and don't even care to understand ), but I believe I understand what's happening in this case.

The short answer is
: it doesn't matter what hack you use. You can even comment out those lines and it will still build (well, at least "libOpenFOAM.so" did).
Reason: The "triad" class is only used by the "triadField" field type definition and there is no clear indication that this particular "triadField" definition is used anywhere else. But it should appear some time in the future of OpenFOAM, so beware!
Keep in mind that Gcc 4.5 is now the minimum version required for OpenFOAM 2.2: http://www.openfoam.org/mantisbt/view.php?id=765

In case you want to be prepared right away, if using RHEL/CentOS/SL 6, you can get Gcc 4.5 and more recent versions from the EPEL repositories: http://fedoraproject.org/wiki/EPEL - edit: apparently it's not present for RHEL/CentOS/SL 6 either
Unfortunately, the EPEL repositories don't have Gcc 4.5 and above for RHEL/CentOS/SL 5
Nonetheless, instructions on how to build your own Gcc 4.6 for OpenFOAM can be found on a nearby thread: Installation Procedure of OF220 on Ubuntu 10.04LTS - keep in mind that those are for Ubuntu 10.04, so you'll need to adapt accordingly.

_______________
Now for the long answer:
  1. The code that Gcc 4.4 breaks at is this:
    Code:
    template<>
    const char* const triad::Vector<vector>::typeName = "triad";
    
    template<>
    const char* triad::Vector<vector>::componentNames[] = {"x", "y", "z"};
  2. Breaking down what this translates to:
    • This indicates that it's a specific template specialization:
      Code:
      template<>
      In essence, it means that the specification on the next line relates to a specific template implementation. For more information: http://www.cplusplus.com/doc/tutorial/templates/ - scroll down to the section "Template specialization"
    • This indicates that the definitions made here are specific to the class from which "triad" derives from:
      Code:
      triad::Vector<vector>
    • If you have a look at the class template "Vector", you'll find this declaration in the file "Vector.H":
      Code:
          // Static data members
      
              static const char* const typeName;
              static const char* componentNames[];
              static const Vector zero;
              static const Vector one;
              static const Vector max;
              static const Vector min;
      As you can see, the two conflicting lines are in fact defining the values for the declared "typeName" and "componentNames" variables.
  3. In comparison, if we look at the code in "vector2D.C", you can find this piece of code:
    Code:
    template<>
    const char* const vector2D::typeName = "vector2D";
    
    template<>
    const char* vector2D::componentNames[] = {"x", "y"};
    • This is perfectly fine to Gcc 4.4, because of the declaration in "vector2D.H":
      Code:
      typedef Vector2D<scalar> vector2D;
      In other words, vector2D is a type definition and not a class that derives from "Vector2D<scalar>".
  4. In conclusion, Gcc 4.4 has issues with the "triad" code because of the complex referencing used. And it's not possible to convert "triad" to a type definition, because of all of the methods and constructors that it has got.
Problems with the hack suggested in post #2:
  1. By removing the "triad::" code from the two lines that Gcc 4.4 has problems with, this means that the definition is made directly to "Vector<vector>", instead of "triad::Vector<vector>".
  2. Currently, this might not have any side-effect, as long as there is no other class that derives from "Vector<vector>".
  3. But a problem will arise if, for example, a class "triadRPY" were to be created and would derive from "Vector<vector>" as well. If it then required the following definition:
    Code:
    template<>
    const char* const triadRPY::Vector<vector>::typeName = "triadRPY";
    
    template<>
    const char* triadRPY::Vector<vector>::componentNames[] = {"r", "p", "y"};
    Then the hack from post #2 would lead to a double definition of "componentNames" and "typeName" for "Vector<vector>", which would probably lead the compiler or linker to give out an error message about object collision or something similar.
Problem with simply commenting out those lines, as I suggested in the short answer:
  1. The variables "componentNames" and "typeName" for "triad" would remain undefined.
  2. If and when those variables were to be accessed by the source code somewhere else, either:
    • the compiler/linker would complain about the missing objects;
    • or it would crash at run time;
    • or it would give out some gibberish byte data from a undefined memory space.

I think this explains most of the details on this topic

Best regards,
Bruno
Ohbuchi, nsf, yanxiang and 2 others like this.

Last edited by wyldckat; April 26, 2013 at 19:47. Reason: edit: apparently it's not present for RHEL/CentOS/SL 6 either
wyldckat is offline   Reply With Quote

Old   March 10, 2013, 04:39
Default
  #6
Member
 
Masashi Ohbuchi
Join Date: Oct 2009
Posts: 72
Rep Power: 7
Ohbuchi is on a distinguished road
Hello, Mr.Santos.
Thank you for your detail explanation of this problem.
I will setup gcc4.6 and re-compile OF2.2 on my system.
Ohbuchi is offline   Reply With Quote

Old   July 18, 2013, 03:08
Default
  #7
Senior Member
 
Illya Shevchuk
Join Date: Aug 2009
Location: Darmstadt, Germany
Posts: 174
Rep Power: 7
linch is on a distinguished road
Hi,

I have the same problem even after updating gcc to version gcc (Debian 4.6.3-14).

Maybe, OF still uses the old gcc version? How could I check it?

Cheers,
Ilya

P.S. linux:
Quote:
Linux 2.6.32-5-amd64
Debian GNU/Linux 6.0.7 (squeeze)

Last edited by linch; July 18, 2013 at 08:01.
linch is offline   Reply With Quote

Old   July 21, 2013, 05:27
Default
  #8
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,258
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Ilya,

Don't forget to check if both gcc and g++ are 4.6:
Code:
gcc --version
g++ --version
Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   July 22, 2013, 07:39
Default
  #9
Senior Member
 
Illya Shevchuk
Join Date: Aug 2009
Location: Darmstadt, Germany
Posts: 174
Rep Power: 7
linch is on a distinguished road
Hi Bruno,

you're right: g++ was still 4.4.

Thanks,
Ilya
linch is offline   Reply With Quote

Old   August 9, 2013, 09:11
Default
  #10
Member
 
Robertas N.
Join Date: Mar 2009
Location: Kaunas, Lithuania
Posts: 52
Rep Power: 8
r08n is on a distinguished road
So far, I tried the following gcc/g++ versions: 4.5.4, 4.6.0, 4.7.1, 4.8.1, with OF 2.2.0 and 2.2.x (from github). They all produce the same error in triad.C. OS=RocksCluster 6.1, based on CentOS 6.3, and the said compilers were compiled from sources. The funny thing is, I have compiled OF 2.2.0 a few months ago on Debian 7.0, and I had the same error at first (I saved the compiler outputs), but then somehow I succeeded... and now I don't remember how...
Can somebody plz share their success stories? Some compiler switches, maybe?
r08n is offline   Reply With Quote

Old   August 10, 2013, 15:03
Default
  #11
Member
 
Robertas N.
Join Date: Mar 2009
Location: Kaunas, Lithuania
Posts: 52
Rep Power: 8
r08n is on a distinguished road
Ooops... I installed different versions of compilers in different folders, but the OF install script still used the "standard" compiler that comes with the OS. Apparently, the desired compiler can be selected by setting the environment variables WM_CC and WM_CXX (e.g., WM_CXX=/share/apps/GCC/gcc-4.8.1/bin/g++), however, it seems that those variables are not actually used (or are they)? There are files
OpenFOAM-(version)/wmake/rules/(platform)/c and c++, where the compiler calls are hardcoded, like 'cc = gcc -m64'. When using wmakeScheduler, this eventually turns into smth like 'ssh compile_host "g++ ..."' Naturally, the environment variables are not set on the appropriate host, and /usr/bin/g++ is used. I edited the respective lines in the wmake/rules files to be 'cc = $(WM_CC) -m64', 'CC = $(WM_CXX) -m64', and it compiled succesfully. The question is, should these compiler calls be hardcoded in wmake/rules? Why not use the WM_CC and WM_CXX variables?
r08n is offline   Reply With Quote

Old   August 16, 2013, 18:50
Default
  #12
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,258
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Quote:
Originally Posted by r08n View Post
Why not use the WM_CC and WM_CXX variables?
Honestly, I thought about this several times as well, but I keep postponing the task of looking deeper into this before reporting this as a bug.
The only reason I can find so far is that using "$(WM_*)" directly in the rule files might fail in some cases, such as Unix based machines or in very old Linux distributions.
Nonetheless, these variables are used in the "Allwmake" script that is located in the ThirdParty folder, so it makes sense that they should also be used in the rules' files.

But don't let me stop you! Feel free to report this in the official bug tracker: http://www.openfoam.org/bugs/
wyldckat is offline   Reply With Quote

Old   October 16, 2013, 11:49
Default
  #13
Senior Member
 
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 368
Rep Power: 12
cnsidero is on a distinguished road
Quote:
Originally Posted by r08n View Post
Ooops... I installed different versions of compilers in different folders, but the OF install script still used the "standard" compiler that comes with the OS. Apparently, the desired compiler can be selected by setting the environment variables WM_CC and WM_CXX (e.g., WM_CXX=/share/apps/GCC/gcc-4.8.1/bin/g++), however, it seems that those variables are not actually used (or are they)? There are files
OpenFOAM-(version)/wmake/rules/(platform)/c and c++, where the compiler calls are hardcoded, like 'cc = gcc -m64'. When using wmakeScheduler, this eventually turns into smth like 'ssh compile_host "g++ ..."' Naturally, the environment variables are not set on the appropriate host, and /usr/bin/g++ is used. I edited the respective lines in the wmake/rules files to be 'cc = $(WM_CC) -m64', 'CC = $(WM_CXX) -m64', and it compiled succesfully. The question is, should these compiler calls be hardcoded in wmake/rules? Why not use the WM_CC and WM_CXX variables?
I know your post is a few months old but I just encountered the same issue (I think) when trying to compile OF with LLVM/Clang. In the etc/bashrc (or cshrc) script you need to change both WM_COMPILER to whichever compiler you're using and foamCompiler to ThirdParty. It was the later one that I forgot to change and was causing me grief.
cnsidero is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can someone PLEASE document the development version installation bernd OpenFOAM Installation 76 November 14, 2008 22:51
Compile OpenFOAM on Fedora 8 asaha OpenFOAM Installation 1 August 25, 2008 11:41
OpenFOAM compilation fails on applicationsutilitiesmesh geoffjay OpenFOAM Installation 12 April 29, 2008 15:26
OpenFOAM with IBM AIX matthias OpenFOAM Installation 20 March 25, 2008 03:36
How to compile OpenFOAM from scratch bashrc and cshrc danieltourde OpenFOAM Installation 2 December 15, 2006 10:30


All times are GMT -4. The time now is 01:18.