[hjasak]

Dear All,

I have just done a compilation of OpenFOAM-1.3 on an older Suse-9.1 system and the issue I've found is so amusing that I wanted to share it (somebody may hit it in the future). :-)

The compilation fails in global.C with the message like

/usr/include/demangle.h:476: error: expected ',' of '...' before typename

Looking at the offending header, the function declaration says:

extern int
cplus_demangle_fill_builtin_type (struct demangle_component *fill,
const char *typename);

i.e. "typename" is used as a name of the parameter, which totally confuses the C++ compiler!


The fix is easy: edit error.C and around the include statement re-define the name locally, i.e.


#define typename HrvsTypeName
#include <demangle>
#undef typename


and all is well.

Hrv

[mbeaudoin]

Hello Hrvoje,

I am still using Suse 9.1 on my workstation. I have kept this old installation relatively up to date, and it looks like this "typo" was corrected in one of the recent SuSE update for 9.1. Here is the same function declaration on my station:

extern int
cplus_demangle_fill_builtin_type PARAMS ((struct demangle_component *fill, const char *type_name));

Looking at the date of the offending file, i can see that it was updated on 2006-01-20 on my workstation.

The file is from the following RPM: binutils-2.15.90.0.1.1-32.13

Now, a little twist on the same subject:

I am currently recompiling OpenFOAM 1.3 on another workstation running Red Hat Enterprise Linux WS release 4 (Nahant Update 2).

The compilation is choking because it cannot find the file demangle.h

Just for testing, I have downloaded and recompiled the latest version of binutils, and, to my surprise, the file demangle.h is not installed by make install either...

So, where does that file comes from?

Is it possible that it is part of binutils on SuSE and from another RPM with RedHat?

I am still investigating this little puzzle... Any pointers would be appreciated...

Martin

[hjasak]

Hmm,

On my Suse systems:


wooster*107-> rpm -q --whatprovides /usr/include/demangle.h
binutils-2.16.91.0.2-8.4


man demangle might also tell you something.

By the way, you are right: this workstation has never been updated from the original Suse-9.1 installation.

Did you try googling it: I get binutils-debuginfo

which kind of makes sense.

Good luck,

Hrv

[mbeaudoin]

Thanks Hrovje for the quick pointer!

By the way, OpenFOAM 1.3 compiled almost right away on my SuSE 9.1 x86-64 workstation.

One problem was easy to fix, the other one, I am still struggling:

<hr width=75% size=2>
The easy problem:
I am using the latest version of cmake (cmake-2.3.4-20060317).

I had to make a small modification to the file OpenFOAM-1.3/applications/utilities/postProcessing/graphics/PVFoamReader/PVFoamR eader/CMakeLists.txt


Here is the fix, in bold:


# Build the package as a plugin for ParaView.

# LINK_DIRECTORIES must be defined before ADD_LIBRARY for cmake version 2.3-20060317
LINK_DIRECTORIES($ENV{FOAM_LIBBIN})

ADD_LIBRARY(${PROJECT_NAME} MODULE ${PVFoamReader_SRCS} ${PVFoamReaderCS_SRCS})
LINK_DIRECTORIES($ENV{ParaView_INST_DIR}/lib)
TARGET_LINK_LIBRARIES(${PROJECT_NAME} vtkClientServer)
FOREACH(c ${PVFoamReader_LIBS})
TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${c}CS)
ENDFOREACH(c)

# Place the package configuration file into the build tree.
CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/PVFoamReader.xml.in
${PROJECT_BINARY_DIR}/../${PROJECT_NAME}.xml @ONLY IMMEDIATE)

# Place the package configuration file into the build tree.
CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/PVFoamReader.pvsm.in
${PROJECT_BINARY_DIR}/../${PROJECT_NAME}.pvsm @ONLY IMMEDIATE)

#Comment out for cmake version 2.3-20060317
#LINK_DIRECTORIES($ENV{FOAM_LIBBIN})

TARGET_LINK_LIBRARIES(${PROJECT_NAME} OpenFOAM finiteVolume vtkFoam)
<hr width=75% size=2>
The not so easy problem:
paraview/paraFoam is crashing in flame with a nice Segmentation fault...

I had not problem with the version of paraview recompiled from OpenFOAM 1.2 on the same SuSE 9.1 x86-64 workstation (paraview-2.2.1).

I am currently recompiling paraview/paraFoam in Debug mode to explore the problem.

Wish me luck..

Martin

Martin -

I had almost the same problem on the Cygwin port, though on Cygwin it's execinfo.h rather than demangle.h that isn't available. The quick-and-dirty solution is to go through and kill all the #if defined(__GNUC__) pieces in error.C. That disables the new backtrace functionality, but it's optional so it doesn't hurt anything else.

In my case, I killed them by wrapping them in #ifndef cygwin blocks; you could probably do something similar with #ifndef NoBacktrace, and then put -DNoBacktrace in the build rules, if you don't want to delete them.

I suspect installing binutils-debuginfo is probably a much better solution, though!

- Brooks

[hjasak]

Hmm, works over here.

- did you compile paraview yourself (I did)
- which build type did you compile? The standard release build uses -O3 optimization, which is for some reason too aggressive (found it on darwin), so I usually build a "nothing" (leave the question blank) or change the optimization level in the advanced options to -O1


Variable Name: CMAKE_BUILD_TYPE
Description: Choose the type of build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
Current Value:
New Value (Enter to keep current value):


If all else fails, try doing a debug build of paraview. You may also need the following snippet of installation instructions for your own paraview build (note that I'm using the latest versions of external stuff):


cd ~/OpenFOAM/linuxSrc
tar xvzf paraview-2.4.3.tgz
mkdir paraview-2.4.3-obj
cmake -i ../paraview-2.4.3

Change options:

enable shared library: YES
prefix: ~/OpenFOAM/linuxSrc/paraview-2.4.3

gmake
gmake install


cd ~/OpenFOAM/linuxSrc

mkdir ~/OpenFOAM/linux/paraview-2.4.3/include
cp ./paraview-2.4.3/VTK/Common/vtk* ~/OpenFOAM/linux/paraview-2.4.3/include/
cp ./paraview-2.4.3/VTK/Filtering/vtk* ~/OpenFOAM/linux/paraview-2.4.3/include/
cp ./paraview-2.4.3-obj/VTK/vtk* ~/OpenFOAM/linux/paraview-2.4.3/include/
cp ./paraview-2.4.3-obj/ParaViewConfig.cmake ~/OpenFOAM/linux/paraview-2.4.3/lib/paraview-2.4/


Good luck,

Hrv

[mbeaudoin]

Yup, I am compiling paraview myself; and I always use the latest version as well.

I was forcing the CMAKE_BUILD_TYPE to Release; I will follow your advice and downgrade to "nothing" and see how it goes...

By the way, here is my local recipe for forcing paraview to install the header files using make install (instead of using cp).

Of course, you need to set up your paraview installation prefix to the right path right away. For a standard OpenFOAM install, it would be something like this:

//Install path prefix, prepended onto install directories.
CMAKE_INSTALL_PREFIX:PATH=~/OpenFOAM/linux/paraview-2.4.3


Next, you need to modify the file paraview-2.4.3/CMakeLists.txt like this (my modifs are in bold):

[ some stuff before.. ]
# Setup install directories.
IF(NOT PV_INSTALL_BIN_DIR)
SET(PV_INSTALL_BIN_DIR ${PV_INSTALL_ROOT}/bin)
ENDIF(NOT PV_INSTALL_BIN_DIR)
IF(NOT PV_INSTALL_INCLUDE_DIR)
# SET(PV_INSTALL_INCLUDE_DIR ${PV_INSTALL_ROOT}/include/paraview-${PARAVIEW_VERSION})
SET(PV_INSTALL_INCLUDE_DIR ${PV_INSTALL_ROOT}/include)
ENDIF(NOT PV_INSTALL_INCLUDE_DIR)
IF(NOT PV_INSTALL_LIB_DIR)
SET(PV_INSTALL_LIB_DIR ${PV_INSTALL_ROOT}/lib/paraview-${PARAVIEW_VERSION})
ENDIF(NOT PV_INSTALL_LIB_DIR)
IF(NOT PV_INSTALL_DATA_DIR)
SET(PV_INSTALL_DATA_DIR ${PV_INSTALL_ROOT}/share/paraview-${PARAVIEW_VERSION})
ENDIF(NOT PV_INSTALL_DATA_DIR)

# Install no development files by default, but allow the user to get
# them installed by setting PV_INSTALL_DEVELOPMENT to true. Disable
# the option altogether if PV_INSTALL_NO_DEVELOPMENT is already set to
# true.
# We force PV_INSTALL_DEVELOPMENT to true
SET(PV_INSTALL_DEVELOPMENT 1)
IF(NOT PV_INSTALL_NO_DEVELOPMENT)
[more stuff after]

It's not pretty, but it gets the job done.

Martin

[mbeaudoin]

All right, I went to the source, so to speak, and found the answer about the missing demangle.h file under RedHat.

The answer lies in the way the binutils RPMs are created under SuSE and RedHat.

Using rpmfind, I grabbed the binutils source RPM for both my stations running SuSE 9.1 and RedHat WS 4:
ftp://195.220.108.108/linux/SuSE-Linux/i386/update/9.1/rpm/src/binutils-2.15.90. 0.1.1-32.13.src.rpm
ftp://195.220.108.108/linux/redhat/updates/enterprise/4WS/en/os/SRPMS/binutils-2 .15.92.0.2-15.src.rpm

Once the proper source RPM installed on each machine, it is pretty easy to discover the way each binary RPM package is constructed by simply reading the spec file binutils.spec, located under the SPECS directory (/usr/src/redhat/SPECS for RedHat, and /usr/src/packages/SPECS for SuSE).

You can also build the binary RPM from the source RPM using rpmbuild. That way, you can verify on each platform what is really going on as the binary RPM is getting build.

The main difference is located under the binutils.spec %install section.

For SuSE, there is an additional step in the installation section that activates, from the directory libiberty, the installation of a few other header files, including the file demangle.h.

Here are the lines in question from the binutils.spec file from the SuSE source package; the line in bold is the important installation step that is missing for RedHat:
<hr width=75% size=2>

[stuff deleted...]
%install
cd build-dir
rm -rf $RPM_BUILD_ROOT
%if "%name" == "binutils"
# installing native binutils
make DESTDIR=$RPM_BUILD_ROOT install-info install
make -C gas/doc DESTDIR=$RPM_BUILD_ROOT install-info-am install-am
rm -rf $RPM_BUILD_ROOT%{_prefix}/%{HOST}/bin/*
mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{HOST}/bin
ln -sf ../../bin/{ar,as,ld,nm,ranlib,strip} $RPM_BUILD_ROOT%{_prefix}/%{HOST}/bin
mv $RPM_BUILD_ROOT%{_prefix}/%{HOST}/lib/ldscripts $RPM_BUILD_ROOT%{_libdir}
ln -sf ../../%{_lib}/ldscripts $RPM_BUILD_ROOT%{_prefix}/%{HOST}/lib/ldscripts

# Install header files
make -C libiberty install_to_libdir target_header_dir=/usr/include DESTDIR=$RPM_BUILD_ROOT

# We want the PIC libiberty.a
install -m 644 libiberty/pic/libiberty.a $RPM_BUILD_ROOT%{_libdir}
#
chmod a+x $RPM_BUILD_ROOT%{_libdir}/libbfd-*
chmod a+x $RPM_BUILD_ROOT%{_libdir}/libopcodes-*
strip $RPM_BUILD_ROOT%{_bindir}/*
[stuff deleted...]

<hr width=75% size=2>

So here is the explanation, now where do I go from here...?

Well, I sure will modify my RedHat binutils installation in order to get the demangle.h file properly installed because I really want to play with the new stack trace on code abort stuff on either SuSE or RedHat workstations (and I want to be able to recompile OpenFOAM from the source code on both these platforms.)

But in the meantime, it looks like this part of OpenFOAM 1.3 is really SuSE specific for people compiling OF from source; maybe it would be a good idea for now to simply activate/deactivate this code at compile time using conditionnal compilation statements in the source code.

Anybody with good antennas at RedHat so we could suggest a little patch update for binutils??

Martin

Martin -

The files you want aren't in RedHat's binutils because they're platform-specific, I think. A bit of poking around the directory tree of the RedHat RPM link you gave finds the following links, and I'll bet one of them will make you happy.

ftp://195.220.108.108/linux/redhat/updates/enterprise/4WS/en/os/Debuginfo/i386/R PMS/binutils-debuginfo-2.15.92.0.2-15.i386.rpm

ftp://195.220.108.108/linux/redhat/updates/enterprise/4WS/en/os/Debuginfo/ia64/R PMS/binutils-debuginfo-2.15.92.0.2-15.ia64.rpm

ftp://195.220.108.108/linux/redhat/updates/enterprise/4WS/en/os/Debuginfo/x86_64 /RPMS/binutils-debuginfo-2.15.92.0.2-15.x86_64.rpm

- Brooks

[mbeaudoin]

Brooks,

The files I need, well at least demangle.h, are part of the plain vanilla standard binutils package.

Look it up on gnu.org. : http://ftp.gnu.org/gnu/binutils/

As describe in my previous post, it is the installation of binutils that is platform specific, at least for SuSE and RedHat.

As for the debuginfo RPMs, here is an excerpt from the document http://www.gurulabs.com/goodies/RedHatLinux9-TechReview.php
<hr width=75% size=2>

Debuginfo RPMs
When creating RPMs using rpmbuild -baspecfile or rpmbuild --rebuildfoo.src.rpm, now a debuginfo RPM is automatically built alongwith the primary RPM(s). These can come in handy when experiencing application crashes. By installing the corresponding debuginfo RPM for apackage, detailed information useful for pinpointing the problem for adeveloper can be obtained when the application crashes. For more info,see the RELEASE-NOTES and the initial idea proposal.

If you create your own RPMs, and you wish turn off the automatic generation of the debuginfo RPMs, the instructions in the shipped RELEASE-NOTES are not correct. The proper entry in your ~/.rpmmacros file is:
%debug_package %

<hr width=75% size=2>

The debuginfo RPMs will give you a copy of a given package libraries with the debugging symbols included, which is very handy for debugging applications linked against those libraries.

This is not the case here, I simply need to compile OF with some include files from the standard GNU package binutils. The files are installed under /usr/include with SuSE, they are absent with RedHat.

By the way, I have almost completed modifying the RedHat binutil.spec file in order to get a binary RPM file similar to the one from SuSE, and where the missing .h files are correctly installed under /usr/include. I'll post the fix as soon as my modification is completed and tested on my RedHat system.

I will also post a fix for people who cannot easily modify their Linux installation. That fix will be based on a local installation of binutils, probably somewhere under the ~/OpenFOAM/linux directory.

Martin

I'm only basing my comments on the fact that, according to the following site, the RedHat binutils-debuginfo-2.15.92.0.2-5.1.i386.rpm file supplies demangle.h (whereas the binutils src rpm doesn't):

http://rpmfind.net/linux/RPM/fedora/updates/3/i386/debug/binutils-debuginfo-2.15 .92.0.2-5.1.i386.html

Certainly it sounds weird given the documentation you posted.... But the file seems to be in there; does installing it not actually solve the problem in practice?

- Brooks

[mattijs]

The other problem is this libiberty.a that actually provides these demangling routines. Is that part of a 'standard' RH installation?

(and why is there no .so one? And gdb has its own one?)

But I feel the backtrace is too nice a facility not to include.

[mbeaudoin]

Brooks:
Indeed, the debuginfo RPM does provide demangle.h, but under the following path:


[palantir:src]> rpm -qlp binutils-debuginfo-2.15.92.0.2-5.1.i386.rpm | grep demangle.h
/usr/src/debug/binutils-2.15.92.0.2/include/demangle.h
/usr/src/debug/binutils-2.15.92.0.2/libiberty/cp-demangle.h


What is needed for the recompilation of OpenFOAM 1.3 is the file
/usr/include/demangle.h

The debuginfo RPM only installs files under the directory

/usr/lib/debug
and
/usr/src/debug

The debuginfo RPMs are mainly for debugging purposes, not for compiling. Of course, we could tweak the OpenFOAM compilation scripts for looking up the files under /usr/src/debug/binutils-2.15.92.0.2/include, but I would not do that. I prefer to adress the problem at its source.

Mattijs:
Yes, the library libiberty.a is there under both SuSE and Redhat.

The problem seems to be limited only to some missing header files under RedHat.

I will continue my current compilation of OF 1.3 under RedHat today, I will keep you posted...

Martin

[mbeaudoin]

Well, I have OpenFOAM 1.3 up and running on RedHat after a complete local recompilation of OpenFOAM, gcc, and paraview.

Of course, I have not tested everything, but I ran a few tutorials, and paraFoam seems to be ok too.

As mentionned before, the only problem was the missing headers from binutils.

I have finally chosen to solve this problem by using a partial local installation of binutils under ~/OpenFOAM/linux. The only thing that I had to install was the header files provided by the command

make target_header_dir=~/OpenFOAM/linux/binutils-2.15.92.0.2-15/include -C libiberty install_to_libdir

I also had to modify the file ~/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/Make/options in order to add the local binutils include directory in the EXE_INC definition

[mbeaudoin]

Sorry, I hit the "Post Message" too soon...

I was just concluding:

If anybody is interested in the whole detailled process about how to get the binutils stuff sorted out in order to recompile OpenFOAM 1.3 on RedHat, I could wrap up a little text and put it on the Wiki somewhere.

Otherwise, you can get a pretty good idea simply by reading this thread.

Martin

[pierrot]

Hi Martin,

I am interested in the whole detailed process.
I use SUSE LINUX 10 and I want to compile OpenFoam 1.3 on it with MPICH or MPI

Pierre

[mbeaudoin]

Pierre,

I don't think you have anything special to do under SuSE 10 with regards to the binutils problem described in this thread.

As Bernhard mentionned in another recent thread (http://www.cfd-online.com/OpenFOAM_D...tml?1144354541), start with the README-file (Section "4. Building from Sources (Optional)" ), and see how it goes.

Martin

[gschaider]

Concerning Martin's fix for the demangle.h-problem on RedHat/Fedora machines. It is also possible to install to install the binutils-debuginfo rpm's as suggested before and add the directory to the searched include-directories by

export CPLUS_INCLUDE_PATH=/usr/src/debug/binutils-2.15.92.0.2/include/
(of course the version number may differ)
in the shell where you then execute the Allwmake command. Of course I have to do that any time I recompile libOpenFOAM.so, but I don't do that that often.

[grisu]

I fear the problem is not limited to Redhat/Fedora: I am compiling OF 1.3 for Debian64 (just a dry run - final target is OF 1.3 on Alpha/OSF1) and up to now I ran into some errors (I have to mention that I had the same errors using the default compiler from my distro (gcc-4.0.3) or the package provided at the OF-Homepage (gcc-4.1.0).):

1) during compilation I got lots of following error messages:

/usr/bin/ld: cannot find -l......
collect2: ld returned 1 exit status
make: *** [/home/$user/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxAMD64Gcc4DPOpt/......] Error 1

The final result is that you end up with an absolutly empty $HOME/OpenFOAM/OpenFOAM-1.3/applications/bin directory.

When I looked up all the output I found that the very first error came with a missing "iberty" -
My Solution: install binutils-dev (deb available)

2) After that the next error message indicated that the object "global" could not be made because of missing "demangle.h".

My Solution: Using the link from Moses Brooks I downloaded the 64bit version of the binutils-rpm,
converted it with alien and installed it.
I also had to apply Bernhards suggestion to export the CPLUS_INCLUDE_PATH.


At the moment it is still compiling without excessive error messages -
I will post the results as soon as possible.

(If I use the existing binaries for Linux64 everything seems ok, even paraFoam is working.)

[liugx212]

Dear All,

I also have problem about installing new OpenFOAM 1.3 version. I post my message of error here. Could you please help me? I am waiting.

Thanks advanced.
Guoxiang



/usr/bin/ld: cannot find -lOpenFOAM
collect2: ld returned 1 exit status
make: *** [/home/liu/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamDebugSwitch es] Error 1
+ wmake foamInfoExec
Making dependency list for source file foamInfoExec.C

SOURCE_DIR=.
SOURCE=foamInfoExec.C ; g++ -m32 -Dlinux -DDP -Wall -W -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-30 -I/home/liu/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -pthread -c $SOURCE -o Make/linuxGcc4DPOpt/foamInfoExec.o
/home/liu/OpenFOAM/OpenFOAM-1.3/wmake/bashScripts/mkObjectDir /home/liu/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec
g++ -m32 -Dlinux -DDP -Wall -W -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-30 -I/home/liu/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -pthread Make/linuxGcc4DPOpt/foamInfoExec.o -L/home/liu/OpenFOAM/OpenFOAM-1.3/lib/linuxGcc4DPOpt \
-lOpenFOAM -liberty -o /home/liu/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec
/usr/bin/ld: cannot find -lOpenFOAM
collect2: ld returned 1 exit status
make: *** [/home/liu/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec] Error 1