[pit]

HI,

is there any possibility to check the right function of 'wmake'?
I have installed 'CentFOAM' on a Red Hat Enterprise Linux 5 and at the first sight it works correctly. But now I tried to upgrade the installation with the 'simpleFunctionObjects' strictly to rule in the wiki. But I only get a segfault when I want to use it.

At first I thought its a problem with the 'simpleFunctionObjects'-pack, but now I tried to compile a modified solver without success. Because of my beginner-status I search the fault by my own modifications. Thats why I copied the solver 'buoyantBoussinesqSimpleFoam' und renamed it. Furthermore I renamed the .C file and modify the make/files. After running the wclean/wmake command the new 'buoyantTest'-solver was available but also leads to a segfault at the very beginning.

Now I'm not sure if I have a correct Foam installation at all.

user@pool buoyantTest]$ wmake
Making dependency list for source file buoyantTest.C
SOURCE=buoyantTest.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-40 -I/OpenFOAM-1.7.0/src/finiteVolume/lnInclude -I/OpenFOAM-1.7.0/src/turbulenceModels -I/OpenFOAM-1.7.0/src/turbulenceModels/incompressible/RAS/lnInclude -I/OpenFOAM-1.7.0/src/transportModels -I/OpenFOAM-1.7.0/src/transportModels/incompressible/singlePhaseTransportModel -IlnInclude -I. -I/OpenFOAM-1.7.0/src/OpenFOAM/lnInclude -I/OpenFOAM-1.7.0/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/buoyantTest.o
/OpenFOAM-1.7.0/src/finiteVolume/lnInclude/readSIMPLEControls.H: In function ‘int main(int, char**)’:
/OpenFOAM-1.7.0/src/finiteVolume/lnInclude/readSIMPLEControls.H:9: warning: unused variable ‘transonic’
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-40 -I/OpenFOAM-1.7.0/src/finiteVolume/lnInclude -I/OpenFOAM-1.7.0/src/turbulenceModels -I/OpenFOAM-1.7.0/src/turbulenceModels/incompressible/RAS/lnInclude -I/OpenFOAM-1.7.0/src/transportModels -I/OpenFOAM-1.7.0/src/transportModels/incompressible/singlePhaseTransportModel -IlnInclude -I. -I/OpenFOAM-1.7.0/src/OpenFOAM/lnInclude -I/OpenFOAM-1.7.0/src/OSspecific/POSIX/lnInclude   -fPIC Make/linux64GccDPOpt/buoyantTest.o -L/OpenFOAM-1.7.0/lib/linux64GccDPOpt \
             -lfiniteVolume -lmeshTools -lincompressibleRASModels -lincompressibleTransportModels -lOpenFOAM -liberty -ldl   -lm -o /OpenFOAM-1.7.0/applications/bin/linux64GccDPOpt/buoyantTest
/usr/bin/ld: warning: i386 architecture of input file `/usr/lib/crt1.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `/usr/lib/crti.o' is incompatible with i386:x86-64 output
/usr/bin/ld: warning: i386 architecture of input file `/usr/lib/crtn.o' is incompatible with i386:x86-64 output

[wyldckat]

Greetings Pit,

Can you detail a bit how you installed CentFOAM? Did you follow the manual installation guide or did you use the automatic scripted installation?

Best regards,
Bruno

[linnemann]

Hi

This is your problem

/usr/bin/ld: warning: i386 architecture of input file `/usr/lib/crt1.o' is incompatible with i386:x86-64 output

So you are trying to build 64bit on a 32bit machine which will not work.

Also stated on the centFOAM project page is that onli 64bit is supported.

[pit]

@linnemann
Its a SUN with Opteron cpu's and should definetly have 64bit.

@wyldckat
To be honest, I've forgotten because it's weeks ago and I thought it works fine. I know that I started with downloading the packages and install dependies by hand wich need root permissions. After that I think I run the script several times to install the single applications like Engrid ... Thats all.

[wyldckat]

Hi Pit,

OK, then let's figure out what is going on. What do these commands output:

which gcc
gcc -v
uname -a

With these we can know:

• which gcc are you using - if it's the one from CentFOAM or the system's gcc;
• what version of gcc you are using;
• the whole specification of RedHat's kernel version, along with the machine's architecture and name. You can (or should) omit the machine's name, so you won't reveal too much information

If it were a SUN machine using SunOS/Solaris, I would know that the 64bit version is a bit more picky than Linux usually is, by separating LD_LIBRARY_PATH into LD_LIBRARY_PATH32 and LD_LIBRARY_PATH64 (if I'm not mistaken). But since it's RedHat, it could depend on the machine's architecture, like SPARC or something like that, i.e., have the same discrimination of 32 and 64 path's, since SunOS and RHEL are OS'es that target enterprises

Best regards,
Bruno

[pit]

Hi Bruno,
after startup and before 'sourcing the .bashrc'

which gcc:

/usr/bin/gcc

gcc -v:

Using built-in specs.
Target: x86_64-redhat-linux
Konfiguriert mit: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread-Modell: posix
gcc-Version 4.1.2 20080704 (Red Hat 4.1.2-48)

after 'sourcing':
which gcc:

.../OpenFOAM/ThirdParty-1.7.0/platforms/linux64/gcc-4.4.4/bin/gcc

gcc -v:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nini/OpenFOAM/ThirdParty-1.7.0/platforms/linux64/gcc-4.4.4 --with-gmp=/home/nini/OpenFOAM/ThirdParty-1.7.0/platforms/linux64/gmp-5.0.1 --with-mpfr=/home/nini/OpenFOAM/ThirdParty-1.7.0/platforms/linux64/mpfr-2.4.2
Thread model: posix
gcc version 4.4.4 (GCC)

I'm not sure what the '/home/nini/...' path is. It's definetly not from the machine here.
uname -a:

Linux local_machine 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

[wyldckat]

Hi Pit,

The "/home/nini" path is probably from Linnemann's build system

But this is very odd... Before you ran wmake to build simpleFunctionObjects, you did source the bashrc file, right? Because right now there are only two possibilities that come to mind for this not to work:

1. CentFOAM's ThirdParty package didn't properly unpack for some weird reason (it's been known to happen with other OpenFOAM packages and other Linux distributions). Therefore the desired object files didn't unpack properly from the ThirdParty package.
2. You didn't source the bashrc file, therefore the system's gcc was used. But if this is the correct possibility, it's odd that the system's gcc would pick up on the 32bit libraries instead of the 64bit libraries...

So, with a bit more feedback, I think we can isolate the problem

Best regards,
Bruno

[pit]

The OF bashrc is sourced because without sourcing the 'wmake' command is not available. I tried it one more time few minutes ago with the same result.

[wyldckat]

Hi Pit,

OK, I forgot to ask this before, but which ld are you using?

which ld
ld -v

Because if it isn't the one that comes with the ThirdParty package, then that could be the problem.

The other possibility is that it could be a problem with the search process of the gcc related object files. Try this:

cd $WM_THIRD_PARTY/platforms
find . -name "ctr*.o"

Best regards,
Bruno

[pit]

I think we get closer to the problem

which ld:

/usr/bin/ld

ld -v:

GNU ld version 2.17.50.0.6-14.el5 20061020

I should tell you, that CentFOAM "install" the packages seperatly. Thats why I need a few entries in my local .bashrc:

9 alias OF17=". ...OpenFoam/OpenFOAM-1.7.0/etc/bashrc"
 10 export LD_LIBRARY_PATH=.../OpenFoam/paraview-3.8.0/lib/paraview-3.8:$LD_LIBRARY_PATH
 11 export PATH=.../OpenFoam/paraview-3.8.0/bin:$PATH
 12 export NETGENDIR=.../OpenFoam/netgen-4.9.13/bin
 13 export PATH=.../OpenFoam/netgen-4.9.13/bin:$PATH
 14 export LD_LIBRARY_PATH=../OpenFoam/netgen-4.9.13/lib:$LD_LIBRARY_PATH
 15 export PATH=.../OpenFoam/engrid-1.2.0:$PATH
 16 export PATH=.../OpenFoam/gmsh-2.4.2/bin:$PATH
 17 export QTDIR=.../OpenFoam/Qt-4.5.2
 18 export PATH=.../OpenFoam/Qt-4.5.2/bin:$PATH
 19 export LD_LIBRARY_PATH=.../OpenFoam/Qt-4.5.2/lib:$LD_LIBRARY_PATH
 20 export PATH=.../OpenFoam/vtk-5.4.2/bin:$PATH
 21 export LD_LIBRARY_PATH=.../OpenFoam/vtk-5.4.2/lib/vtk-5.4:$LD_LIBRARY_PATH

find . -name "ctr*.o" brings no result

[wyldckat]

Hi Pit,

This is odd... doesn't CentFOAM come with its own ld? Try looking for it somewhere at "$WM_THIRD_PARTY/platforms/linux64/gcc-4.4.4". If there isn't an ld, then it's because it wasn't built with binutils. If there is one, but named something like "x86_64-unknown-linux-gnu-ld", then edit the rule files at "$WM_PROJECT_DIR/wmake/rules/linux64Gcc".

Since I'm not familiar with the innards of CentFOAM, I'll have to suggest trying to rebuilding gcc 4.4.4 using the script I made available some time ago and updated yesterday: Automated scripts for building gcc 4.4.x and 4.5.x for using with OpenFOAM 1.7 series
It will download the necessary packages and build both binutils and gcc. You can update the used versions of packages defined in the script if you want to, since for example, CentFOAM is using gmp-5.0.1 and my scripts are using the latest 4...something version...

Best regards,
Bruno

[pit]

Hi Bruno,
sry for the long time of no response. I tried your solution but I get new errors.
To make a long story short, I get a 'new & clean' RHEL5 installation from the admin. That finally woks fine with the CentFOAM-1.7.0.

I only want to 'end' the thread for internal search and say thanks for your assistance.

[wyldckat]

Hi Pit,

Originally Posted by pit

I only want to 'end' the thread for internal search and say thanks for your assistance.

You're welcome And I'm glad you've got it up and running and also entitled to a shiny new RHEL5

Best regards and happy foaming
Bruno