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

Suse Linux 91 port

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

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 5, 2006, 14:22
Default Dear All, I have just done
  #1
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,904
Rep Power: 33
hjasak will become famous soon enough
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
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   April 5, 2006, 15:09
Default Hello Hrvoje, I am still us
  #2
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   April 5, 2006, 15:22
Default Hmm, On my Suse systems:
  #3
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,904
Rep Power: 33
hjasak will become famous soon enough
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
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   April 5, 2006, 16:38
Default Thanks Hrovje for the quick po
  #4
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   April 5, 2006, 16:40
Default Martin - I had almost the s
  #5
brooksmoses
Guest
 
Posts: n/a
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
  Reply With Quote

Old   April 5, 2006, 17:05
Default Hmm, works over here. - did
  #6
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,904
Rep Power: 33
hjasak will become famous soon enough
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
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   April 5, 2006, 17:40
Default Yup, I am compiling paraview m
  #7
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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 is offline   Reply With Quote

Old   April 6, 2006, 01:22
Default All right, I went to the sourc
  #8
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   April 6, 2006, 01:54
Default Martin - The files you want
  #9
brooksmoses
Guest
 
Posts: n/a
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
  Reply With Quote

Old   April 6, 2006, 03:34
Default Brooks, The files I need, w
  #10
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   April 6, 2006, 04:27
Default I'm only basing my comments on
  #11
brooksmoses
Guest
 
Posts: n/a
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
  Reply With Quote

Old   April 6, 2006, 05:38
Default The other problem is this libi
  #12
Senior Member
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26
mattijs is on a distinguished road
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.
mattijs is offline   Reply With Quote

Old   April 6, 2006, 09:50
Default Brooks: Indeed, the debuginfo
  #13
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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 is offline   Reply With Quote

Old   April 6, 2006, 15:51
Default Well, I have OpenFOAM 1.3 up a
  #14
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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 is offline   Reply With Quote

Old   April 6, 2006, 16:01
Default Sorry, I hit the "Post Message
  #15
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   April 7, 2006, 05:50
Default Hi Martin, I am interested
  #16
New Member
 
Pierre Maruzewski
Join Date: Mar 2009
Posts: 6
Rep Power: 17
pierrot is on a distinguished road
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
pierrot is offline   Reply With Quote

Old   April 7, 2006, 09:46
Default Pierre, I don't think you h
  #17
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 332
Rep Power: 22
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   April 12, 2006, 12:50
Default Concerning Martin's fix for th
  #18
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
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.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 13, 2006, 17:16
Default I fear the problem is not limi
  #19
New Member
 
Christian J.
Join Date: Mar 2009
Posts: 4
Rep Power: 17
grisu is on a distinguished road
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.)
grisu is offline   Reply With Quote

Old   April 15, 2006, 03:00
Default Dear All, I also have probl
  #20
Senior Member
 
Guoxiang
Join Date: Mar 2009
Posts: 109
Rep Power: 17
liugx212 is on a distinguished road
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
liugx212 is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
star3.24 and SUSE Linux 10.0 Timothy Siemens 3 October 17, 2006 13:39
CFX 10 Pre/Post and Linux SuSE 10.0 Bernhard Dobmeier CFX 2 July 11, 2006 15:09
CFX and SUSE linux Paul CFX 5 December 23, 2004 22:53
Fluent 5.x with SuSE Linux 7.1 (7.0)? Elmar Riesmeier FLUENT 3 April 8, 2001 14:34
Linux/Alpha port ? Prateep Chatterjee FLUENT 1 June 5, 2000 22:28


All times are GMT -4. The time now is 11:03.