CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Installation (https://www.cfd-online.com/Forums/openfoam-installation/)
-   -   2.0.x on Mac OSX (https://www.cfd-online.com/Forums/openfoam-installation/89752-2-0-x-mac-osx.html)

niklas June 21, 2011 15:01

2.0.x on Mac OSX
 
I'm trying to compile 2.0.x on Mac OS X (Snow Leopard) and in
src/OSspecific/POSIX/POSIX.C
there is an include for "link.h" that I cant figure out which package it comes from.

Commenting it out yields an

POSIX.C:1216:47: error: 'dl_iterate_phdr' was not declared in this scope

which is a clue, but i still cant find out if there is a macports package that supply this.

Anyone know?
N

gschaider June 21, 2011 17:59

Quote:

Originally Posted by niklas (Post 312944)
I'm trying to compile 2.0.x on Mac OS X (Snow Leopard) and in
src/OSspecific/POSIX/POSIX.C
there is an include for "link.h" that I cant figure out which package it comes from.

Commenting it out yields an

POSIX.C:1216:47: error: 'dl_iterate_phdr' was not declared in this scope

which is a clue, but i still cant find out if there is a macports package that supply this.

Anyone know?
N

That is stuff for listing the dynamic libraries which is not implemented in MacOS (or differently). Comment it out. The coded stuff probably won't work (I havn't finished my port yet, so I can't tell for sure)

Bernhard

gschaider June 21, 2011 22:16

1 Attachment(s)
Quote:

Originally Posted by niklas (Post 312944)
I'm trying to compile 2.0.x on Mac OS X (Snow Leopard) and in
src/OSspecific/POSIX/POSIX.C
there is an include for "link.h" that I cant figure out which package it comes from.

Commenting it out yields an

POSIX.C:1216:47: error: 'dl_iterate_phdr' was not declared in this scope

which is a clue, but i still cant find out if there is a macports package that supply this.

Anyone know?
N

As noted in the other posting I just commented the offending lines out (will have a look on how to port this to Mac OS X later. Unless somebody is faster. I sincerely hope so). This patch makes the whole thing compile on MacOSX. The damBreak-case (blockMesh/setFields/interFoam) worked without problems. As always I didn't bother to make paraFoam work (in difference to the the coded stuff I currently have no intention to do so).

In the attached tar you'll find three files:
- patch to OpenFOAM itself.
- patch to the thirdParty-directory
- A file that goes to ~/OpenFOAM/site/2.0.x/ This tells OF that it should use the system-OpenMPI and gcc 4.5 from MacPorts (the Apple gcc 4.2 chockes on some SubField-stuff)

An comments/improvements welcome

Bernhard

podallaire June 22, 2011 12:39

Thank you Bernhard,

tested the patches and used gcc-4.3 to compile it / worked perfectly !

Regards,

PO

niklas June 22, 2011 12:56

Yes, worked like a charm.
thanks for that, saved me lots of time :)
(Im using gcc-mp-4.6)

N

podallaire June 22, 2011 14:10

I'm wondering if files src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCode.C (line 337) and src/OSspecific/POSIX/POSIX.C (line 1118) should be modified for the *.so ?

It looks that loading the shared libs from the controlDcit using extension *.so does not work / I understand that dlLibraryTable.C cannot be anymore tweaked the way you did it for 1.7.x

Thanks

PO

gschaider July 5, 2011 18:56

2 Attachment(s)
Quote:

Originally Posted by podallaire (Post 313137)
I'm wondering if files src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCode.C (line 337) and src/OSspecific/POSIX/POSIX.C (line 1118) should be modified for the *.so ?

It looks that loading the shared libs from the controlDcit using extension *.so does not work / I understand that dlLibraryTable.C cannot be anymore tweaked the way you did it for 1.7.x

Thanks

PO

Well. That fix was quite simple (basically the same only the names have changed). That and a fix that makes the codestreams work (as always: replace .so with .dylib ;) ) are found in the attached dylibMac-patch for those who applied the previous patch. The accumulated wisdom (the old patch with the dylib merged in) can be found in the _v2-patch.

I didn't port the dlLoaded-function (that would have been more work) because I found no code that uses that

Bernhard

sushant July 15, 2011 02:05

Perfect!
 
Compiled *out of the box*. Couldn't have been more perfect. It'll hardly be any effort even for brand new users!

Still, if anyone needs the readymade binaries on a disk image, please see the link in my signature.

More power to you, BG :)

(gcc-mp-45, OS X 10.6.7)

fippo_dk July 25, 2011 04:18

OF on Lion?
 
Hi guys.

Great work the one you have been doing here with these images.

I would like to hear if any of you have tested these images of OF1.7 and OF2.0 on Lion OS X.

I tried to used the images, but they don't work.

Any suggestions?

Best regards,

Felipe

podallaire July 25, 2011 10:18

Quote:

Originally Posted by fippo_dk (Post 317329)
Hi guys.

Great work the one you have been doing here with these images.

I would like to hear if any of you have tested these images of OF1.7 and OF2.0 on Lion OS X.

I tried to used the images, but they don't work.

Any suggestions?

Best regards,

Felipe

I would suggest to compile it from scratch under Lion. I tried that last week and it worked. However, you need to install or build gcc 4.3 at least. You can use MacPort or build it from sources. If you build it from sources, use "clang" instead of the gcc-4.2.

regards,

PO

fippodk July 25, 2011 13:43

Ok, I will try that.

Although I tried with gcc 4.5.3 and it did not work.

I'll post the results later on.

Thanks for your answer,

Felipe

calebg July 26, 2011 12:44

Hi

I am also trying to compile OpenFOAM 2.0.x on Mac OS 10.7, and having difficulties. I am using GCC 4.4 from MacPorts, XCode 4.1, and OpenMPI compiled on my machine from the source code (as 10.7 no longer includes OpenMPI).

I've applied the patches, after updating the OpenFOAM_V2 patch to use gcc-mp-4.4. When I compile, I get several errors, but the most common one is that header files cannot be opened when making dependency lists. Once the compile is done, I will upload the output of the terminal.

Any suggestions would be most appreciated, as well as your patience as I am unfamiliar with compiling code.

Thanks,
Caleb

calebg July 26, 2011 13:40

Hi

So an update: I'm confused. After the compile completed, I ran the foamInstallationTest script. There were 2 critical errors, but the first was the OS. The second was the gcc version - it found 4.2.1. I set the patch to use gcc-mp-4.4.

I can run blockMesh and icoFOAM, so maybe things installed correctly?

Anyone know why I was getting the "could not open file *.H for source *.C" messages?

Here is a sample of the messages:
+ wmake libso OpenFOAM
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file global/global.Cver
Making dependency list for source file global/argList/argList.C
Making dependency list for source file global/clock/clock.C
Making dependency list for source file primitives/bools/bool/bool.C
Making dependency list for source file primitives/bools/bool/boolIO.C
Making dependency list for source file primitives/bools/Switch/Switch.C
Making dependency list for source file primitives/bools/Switch/SwitchIO.C
Making dependency list for source file primitives/bools/lists/boolList.C
could not open file HashSet.H for source file global/global.Cver
could not open file Map.H for source file global/global.Cver
could not open file primitiveMeshI.H for source file global/global.Cver
could not open file pointIOField.H for source file global/global.Cver
could not open file faceIOList.H for source file global/global.Cver
could not open file labelIOList.H for source file global/global.Cver
could not open file polyBoundaryMesh.H for source file global/global.Cver
could not open file boundBox.H for source file global/global.Cver
could not open file pointZoneMesh.H for source file global/global.Cver
could not open file faceZoneMesh.H for source file global/global.Cver
could not open file cellZoneMesh.H for source file global/global.Cver

I also got this message many times, early on:
UPstream.C:266: warning: use of old-style cast

Thanks,
Caleb

gschaider July 27, 2011 11:55

Quote:

Originally Posted by calebg (Post 317573)
Hi

So an update: I'm confused. After the compile completed, I ran the foamInstallationTest script. There were 2 critical errors, but the first was the OS. The second was the gcc version - it found 4.2.1. I set the patch to use gcc-mp-4.4.

I can run blockMesh and icoFOAM, so maybe things installed correctly?

Anyone know why I was getting the "could not open file *.H for source *.C" messages?

Here is a sample of the messages:
+ wmake libso OpenFOAM
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file global/global.Cver
Making dependency list for source file global/argList/argList.C
Making dependency list for source file global/clock/clock.C
Making dependency list for source file primitives/bools/bool/bool.C
Making dependency list for source file primitives/bools/bool/boolIO.C
Making dependency list for source file primitives/bools/Switch/Switch.C
Making dependency list for source file primitives/bools/Switch/SwitchIO.C
Making dependency list for source file primitives/bools/lists/boolList.C
could not open file HashSet.H for source file global/global.Cver
could not open file Map.H for source file global/global.Cver
could not open file primitiveMeshI.H for source file global/global.Cver
could not open file pointIOField.H for source file global/global.Cver
could not open file faceIOList.H for source file global/global.Cver
could not open file labelIOList.H for source file global/global.Cver
could not open file polyBoundaryMesh.H for source file global/global.Cver
could not open file boundBox.H for source file global/global.Cver
could not open file pointZoneMesh.H for source file global/global.Cver
could not open file faceZoneMesh.H for source file global/global.Cver
could not open file cellZoneMesh.H for source file global/global.Cver

That was a compilation from a "fresh" source or a compilation in a directory that already had a compiled OF (before the 10.6-times). In the first case I'd say you're OK (I can't reproduce it because I'd have to scratch my installation for that, but I think that always happens during the first compilation). In the second case you might experience subtle versions of DLL-hell and I'd recommend compiling from a fresh source directory

Quote:

Originally Posted by calebg (Post 317573)
I also got this message many times, early on:
UPstream.C:266: warning: use of old-style cast

That is only a warning. If it was serious god would have created it as an error ;)

of_user_ August 3, 2011 18:20

may i ask how to run this this .path file? i tired:

patch -p0 < ThirdParty-2.0.0-Mac.patch

but it does not work

gschaider August 4, 2011 08:23

Quote:

Originally Posted by of_user_ (Post 318769)
may i ask how to run this this .path file? i tired:

patch -p0 < ThirdParty-2.0.0-Mac.patch

but it does not work

Could you enlighten us about the way in which it doesn't work? Error message would be helpful

of_user_ August 4, 2011 17:06

i put "ThirdParty-2.0.0-Mac.patch" in thirdparty dictionary and tried to run it using:

Quote:

patch -p0 < ThirdParty-2.0.0-Mac.patch --verbose
than i get this:

Quote:

Hmm... Looks like a unified diff to me...
can't find file to patch at input line 7
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|# HG changeset patch
|# Parent b8c70d03f7807a6331a9af62c0d1dfee850f7ca8
|
|diff --git a/Allwmake b/Allwmake
|--- a/Allwmake
|+++ b/Allwmake
--------------------------
File to patch:
how do i go on? i tried typing Allwmake after the file to patch prompt and hit enter. but i do not know how i should run this patch. never ran a patchfile before...

wyldckat August 4, 2011 18:01

Greetings to all!

@of_user_: Try this command instead:
Code:

patch -p1 < ThirdParty-2.0.0-Mac.patch
The reason why it should work is because of this path description:
Code:

|--- a/Allwmake
|+++ b/Allwmake

a and b are folders that do not exist in real life. The "-p" option reads this in the man patch page:
Quote:

Originally Posted by http://linux.die.net/man/1/patch
-pnum or --strip=num
Strip the smallest prefix containing num leading slashes from each
file name found in the patch file. A sequence of one or more adja‐
cent slashes is counted as a single slash. This controls how file
names found in the patch file are treated, in case you keep your
files in a different directory than the person who sent out the
patch.

It continues, but I think it wasn't worth it pasting everything...

Best regards,
Bruno

sushant August 28, 2011 03:59

For OS X 10.7+
 
For those who want to simply get it working on Lion:
  • Install Apple's developer tools
  • Install Macports for Lion (2.0.1 as of this post)
  • Do a 'sudo port install gcc46' (gcc44/45 may have some issues while building)
  • Extract OpenFOAM and ThirdParty on a case-sensitive disk image
  • Use Bernhard's above patches (latest), edit the OpenFOAM patch file and replace 'Gcc45' with 'Gcc46', '-mp-4.5' with '-mp-4.6'. Apply the patches.
  • In ~/OpenFOAM/site/2.0.x/prefs.sh change Gcc45 to Gcc46. Comment out the WM_MPLIB line, or change SYSTEMOPENMPI to simply OPENMPI (have to build your own MPI, Lion isn't shipping with one)
  • Do ./Allwmake in ~/OpenFOAM/OpenFOAM-2.0.x

(I had to do the last step twice; Pstream didn't compile on the first try)

Use the new 10.7 ParaView 3.10.1 binary on Kitware's website. (yay!)

Side note: Even though WM_COMPILER=Gcc46 in site/2.0.x/prefs.sh sometimes 'gcc' is invoked instead of 'gcc-mp-4.6'. Why is this so? This calls Apple's gcc or llvm-gcc 4.2 which spits out furious errors on some files. (to work around it, do 'sudo port select gcc mp-gcc46' then switch back when done)

woodscn September 13, 2011 22:41

Perhaps unsurprisingly, the patch provided above doesn't work with ThirdParty-2.0.1, which is what's available now.

Is there a place I can find the old files? Is there a timeline for a new patch?


All times are GMT -4. The time now is 00:06.