[lakeat]

BUG-1: cbrtf problem
------------------------------------------------------------------
Ref:
http://www.gnu.org/software/gnulib/m...ode/cbrtf.html
------------------------------------------------------------------
POSIX specification: http://www.opengroup.org/susv3xsh/cbrtf.html
Gnulib module: -
Portability problems fixed by Gnulib:
Portability problems not fixed by Gnulib:
This function is missing on some platforms: AIX 5.1, IRIX 6.5, Solaris 9.
------------------------------------------------------------------

What I have modified:
------------------------------------------------------------------
insert these lines to doubleFloat.H
------------------------------------------------------------------
inline float cbrtf(float x) { return float(cbrt(double(x)));}
inline float asinhf(float x) { return float(asinh(double(x)));}
inline float acoshf(float x) { return float(acosh(double(x)));}
inline float atanhf(float x) { return float(atanh(double(x)));}
inline float erff(float x) { return float(erf(double(x)));}
inline float erfcf(float x) { return float(erfc(double(x)));}
inline float lgammaf(float x) { return float(lgamma(double(x)));}
------------------------------------------------------------------


BUG-2: execinfo.h problem
------------------------------------------------------------------
Ref:
http://www.gnu.org/software/gnulib/m...nfo_002eh.html
------------------------------------------------------------------
Declares the functions backtrace, backtrace_symbols, backtrace_symbols_fd.
Documentation:
http://www.gnu.org/software/libc/man...acktraces.html,
man backtrace.
Gnulib module: -
Portability problems fixed by Gnulib:
Portability problems not fixed by Gnulib:
This header file is missing on all non-glibc platforms: MacOS X 10.3, FreeBSD 6.0, NetBSD 3.0, OpenBSD 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 10, Cygwin, mingw, Interix 3.5, BeOS.
------------------------------------------------------------------

What I have modified:
------------------------------------------------------------------
comment out "#include <execinfo.h>" line like this
#ifndef darwin
//#include <execinfo.h>
#endif
------------------------------------------------------------------

More,
I'd prefer more lines "#ifndef darwin" to be modified to sth like "#ifndef sgi".
To my discouragement, few of us use OpenFOAM on sgi now.

And I still have trouble in compiling OpenFOAM with sgi native mpi,
I post the error messages here. Could anyone have a look at it, I'd appreciate it!
http://www.cfd-online.com/OpenFOAM_D...tml?1211383629

Best Regards,
Daniel

[mattijs]

Thanks for report. For the new version we've split off the os specific parts into a separate library which will make it much easier to implement/disable above port specifics.

I assume the sgi port works with openmpi? If so there is probably something wrong with the mpi invocation since that (argList) handling is the first communication.

[lakeat]

> I assume the sgi port works with openmpi?
1. I am using sgi native mpirun.
2. I have tried openmpi but to no avail.
3. I have tried LAM (), it's good but the error messages are much less than the native mpi, so I do not use it now.


> there is probably something wrong with the mpi invocation since that (argList) handling is the first communication.

Yes, you are right.
1. I found this line 343 caused the errors.
fromMaster >> args_ >> options_;
2. I GUESS the problem is in IPstream's constructor, ./src/Pstream/mpi/IPread.C
line 69
messageSize_ = read(fromProcNo_, buf_.begin(), buf_.size());
3. I printed out "fromProcNo_", "buf_.begin()", "buf_.size()"! And "fromProcNo_" & "buf_.size()" are meaningful,
but "buf_.begin()" is a special symbol which I can not type it out, it is a symbol with two "F" on each corner of left-top and right-bottom. I guess this is wrong. (Please correct me if I'm wrong)
4. I traced the class hierarchy to the top, buf_ -> List -> UList -> STL Member Functions UList<t>::begin() ......???

What can I do now?

Best Regards, Daniel

[lakeat]

Hi Mattijs!

stringI.H
error: '::abs' has not been declared

so, I #include <cstdlib> in the beginning of this file.

I use gcc-4.3.0

Regards, Daniel

[lakeat]

The same error also, file
new.C
'::abort' has not been declared.

I #include <cstdlib> in the beginning of this file.

I add -DIRIX64 to c++DBUG in c++Debug file, and then
change "#ifndef darwin" to "#ifndef IRIX64".


With gcc-4.3.0, warning of "suggest a space before ';'" is quite annoying especially in files like HashTable.C and hashTableI.H. So I modified them.

When would the next version be released?
And when will the 1.4.1-dev be compatible with gcc-4.3.0?

[mattijs]

Thanks - we're currently going through 4.3.0 compilation. Picked up quite a few small 'features'.

[lakeat]

Stupid IRIX, "find . -maxdepth .... " won't work, so no way to wmake all!

And why the cbrtf problem I reported is not accepted in the new version-1.5? Is it because OpenFOAM community has thoroughly abandoned the sgi-IRIX? Sad!

And OsSpecific is not as powerful as I have expected.


Daniel

[henry]

We cannot support IRIX any longer as we do not have access to IRIX machines and my understanding is that SGI has abandoned IRIX in favor of ALTIX (a Linux variant) and we have followed that lead and now support ALTIX. Would it be possible for you to upgrade your machine to ALTIX? If not you could install GNU versions of UNIX utilities on your IRIX machine, in particular if you install GNU find -maxdepth will work. I am not sure what the cbrtf problem is but I guess you will be able to work around it.

H

[lakeat]

Thank you Henry,

I noticed, and you are right in doing that! Though it's not a good news for me, it's not easy to build on that IRIX machine, segv all the time.

I once asked in the nekochan.net forum, there the reply is:
http://forums.nekochan.net/viewtopic...=15&t=16717849
(Note the last post).
I once thought that the new version would take care IRIX MORE, since it seems clearly that you have a strong cooperation with SGI. But now I sadly see I was wrong. I will try to turn to the ssc in shanghai. Tough! But I love this code, it's excellent.

Thanks for your quick reply.

Daniel

[henry]

Are SGI still developing IRIX? My understanding is that they are not and all new SGI machines are being shipped with ALTIX which OpenFOAM does compile (with gcc 4.?) and run on with either OpenMPI or SGI MPI (and other MPI implementations SGI supports but we have not used those directly).

I doubt that OpenFOAM will compile with the MIPS Pro C++ compiler but it might if recent versions support the whole of the C++ standard. We do not knowingly use GNU C++ extensions and endeavor to write OpenFOAM to conform to the C++ standard. If you can show that the reason that OpenFOAM does not compile with the MIPS Pro or any other C++ compiler is because the code is currently relying on some feature not in the standard please report it and we will fix it -- I have a copy of the C++ standard document here for reference. OpenFOAM does compile with recent versions of the Intel C++ compiler and we test this regularly to make sure we are not developing dependencies on g++.

H

[lakeat]

Thank you so much, Henry!