[Ohbuchi]

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]

When I removed the 'triad ::' from line 36 and line 39 of triad.C, the compilation was successful.

[zordiack]

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?

[olivierG]

hello,

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

Regards,
olivier

[wyldckat]

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: http://www.cfd-online.com/Forums/ope...-10-04lts.html - 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:
   

   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:

     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:
     

     triad::Vector<vector>

   • If you have a look at the class template "Vector", you'll find this declaration in the file "Vector.H":
     

         // 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:
   

   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":
     

     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:
   

   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]

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.

[linch]

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:

Linux 2.6.32-5-amd64
Debian GNU/Linux 6.0.7 (squeeze)

[wyldckat]

Hi Ilya,

Don't forget to check if both gcc and g++ are 4.6:

gcc --version
g++ --version

Best regards,
Bruno

[linch]

Hi Bruno,

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

Thanks,
Ilya

[r08n]

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]

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?

[wyldckat]

Originally Posted by r08n

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/

[cnsidero]

Originally Posted by r08n

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.