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

Installing OF 1.6 on Mac OS X

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

Reply
 
LinkBack Thread Tools Display Modes
Old   August 3, 2009, 19:07
Default
  #21
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by podallaire View Post
just sent an email / yes, no malloc problem
The patches look fine by me. Just one question about the upgrade of the MACOSX_DEPLOYMENT_TARGET from 10.4 to 10.5: Is there a technical reason for it? The reason why this variable was set during the first port Mac-port (waaay back, that's why the details are a bit vague) was that only deployment targets after a certain version allowed circular dependencies of the libraries. If it doesn't have any advantages I'd rather stick with 10.4 to keep the number of systems that can use the patch without modifications as big as possible

BTW: I noticed on the Paraview-list that you're busy with the Cocoa/64-bit-QT
gschaider is offline   Reply With Quote

Old   August 3, 2009, 19:38
Default
  #22
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
I don't think that the MACOSX_DEPLOYMENT_TARGET variable makes a difference /you are right, let's keep 10.4 for compatibility

Yeah, ParaView with QT cocoa 64... well, for some reason, I was able to do
it couple months with the help of the ParaView-list but I did not remember
how. Using the proposed patches, I was able to compile a working
version last week-end which includes Takuya's work. Note that I compiled
QT with gcc-4.2 since some specific mac os x flags are missing from the gcc
mac port version. Here are my conclusions :

- Latest cvs version for some reason is not working properly in client/server
mode, the problems occured for all paraview flavor that I compiled over the
week-end (64 cocoa, 32 carbon, ...) / I really don't know what is the
problem here
- Takuya's reader still faster compared to the new PV3Reader version which
I compiled from the Thirdparty patch and 32-bit OF1.6.x flavor
- ParaView 64 cocoa works well but still need some development, some
components are not fully supported

At the end, the best Mac OS X setup that I can get is a 32 or 64 OpenFOAM flavor with an independant working version of ParaView 32 Carbon (that
I compiled 4 months ago) with Takuya's reader, which allows me to connect
to our Linux cluster.

PO
podallaire is offline   Reply With Quote

Old   August 4, 2009, 03:53
Default
  #23
Member
 
Andrew Ryan
Join Date: Mar 2009
Posts: 47
Rep Power: 8
andrewryan is on a distinguished road
I did a find for some of the files, for which i got a "could not open" error message and I found them in the sources.. How can I figure out what exactly the script is trying to do when it tries to open then file (debug switches?) Could it be that there is some environment variable set to a wrong path?

Also I noticed that there is no Allwclean, is there a way to clean the sources?
andrewryan is offline   Reply With Quote

Old   August 4, 2009, 08:11
Default
  #24
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
The "could not open file" message that you see along the compiling process is normal, wmake is making the depency file list needed for each object. No problem here ...

-> wcleanAll
podallaire is offline   Reply With Quote

Old   August 4, 2009, 09:33
Default
  #25
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Hi!

@Andrew: It seems the compilation of metis is failing, which in turn causes the compilation failures of the subsequent libraries like a chain reaction.
Code:
++ cd metis-5.0pre2
++ wmake libso GKlib
SOURCE=trunk/dlmalloc.c ;  gcc-mp-4.3 -m64 -DdarwinIntel64 -DWM_DP -Wall -O3   -IlnInclude -I. -I/Users/nils/OpenFOAM/OpenFOAM-1.6/src/OpenFOAM/lnInclude -I/Users/nils/OpenFOAM/OpenFOAM-1.6/src/OSspecific/POSIX/lnInclude   -fPIC -Ddarwin -c $SOURCE -o Make/darwinIntel64DPOpt/dlmalloc.o
trunk/dlmalloc.c:84: error: conflicting types for 'sbrk'
/usr/include/unistd.h:559: error: previous declaration of 'sbrk' was here
make: *** [Make/darwinIntel64DPOpt/dlmalloc.o] Error 1
I still haven't tried the patches thus don't have a solution, hopefully not that difficult to find?

@PO: Thanks about sharing your interesting findings. You are way ahead of me about 64bit Cocoa One note is that the reader doesn't support the extended syntaxes of OF-1.6 format yet (especially the nice regex'ed dictionary keywords). I'm working on it but it may take some time.

Takuya
7islands is offline   Reply With Quote

Old   August 4, 2009, 09:53
Default
  #26
Member
 
Andrew Ryan
Join Date: Mar 2009
Posts: 47
Rep Power: 8
andrewryan is on a distinguished road
@7islands Thx for the hint, now I just need to figure out why metis does not compile..
andrewryan is offline   Reply With Quote

Old   August 4, 2009, 11:48
Default
  #27
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
try those updated patches
Attached Files
File Type: zip patchesV2.zip (11.7 KB, 39 views)
podallaire is offline   Reply With Quote

Old   August 4, 2009, 13:00
Default
  #28
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by podallaire View Post
try those updated patches
Could you upload them to the Wiki, too (just replace the old patches with them no need to confuse everyone with v1/v2). Thanks
gschaider is offline   Reply With Quote

Old   August 4, 2009, 13:41
Default
  #29
Member
 
Andrew Ryan
Join Date: Mar 2009
Posts: 47
Rep Power: 8
andrewryan is on a distinguished road
I just tried again with the following line uncommented:

trunk/dlmalloc.c:84: error: conflicting types for 'sbrk'

Then it compiled w/o problems (except for the could not open error messages, why do they appear anyway?), however paraFoam did not work, I didn't check whether paraview was compiled or not.

@podallaire I didn't try your patch yet, I started recompiling before u posted it. How long did it take for you to compile? I'm not exactly sure, but I think maybe more then 3 hours (on a MB Pro , Intel Core 2 Duo 2.53 MHZ, 4GB RAM)
andrewryan is offline   Reply With Quote

Old   August 4, 2009, 14:18
Default
  #30
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
I have updated the Wiki with the latest version of the patches :

http://openfoamwiki.net/index.php/Ho...enFOAM_v16_Mac

Andrew, I suggest that you clean everything, re-patch both OpenFoam and ThirdParty and recompile. Compiling everything (except ParaView) : around 3-4 hrs
podallaire is offline   Reply With Quote

Old   August 5, 2009, 03:22
Default
  #31
Member
 
Andrew Ryan
Join Date: Mar 2009
Posts: 47
Rep Power: 8
andrewryan is on a distinguished road
@podallaire 3-4 hours again Doesn't anybody have a Mac Pro here? Maybe I'll try tonight. (It's 9am here, so in about 13 hours or so) In addition to your patches, I also made the following changes:

- A symlink for malloc.h in /usr/include. Because some headers refer to it as malloc.h instead of sys/malloc.h. (I think it was somewhere in the ThirdParty libs)
- Uncommented trunk/dlmalloc.c:84.

Did you include this in your patch now?

Also what's the easiest way to get ParaView working? I just downloaded the binaries from paraview.org and used foamToVTK, but it seems that not everything works correct. Do I have to compile ParaView by hand, or is there a way to use the binaries with paraFoam?
andrewryan is offline   Reply With Quote

Old   August 5, 2009, 05:57
Default
  #32
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Hi!

Maybe someone here had better luck: one thing that stopped working some time ago (can't put my finger on it, when) is the printStack-functionality (or to be exact: the part where I get the line-number in the code-file). To get the line in the source I'm using gaddr2line from the MacPorts-project. The problem is that whatever binary I throw at that tool it always gives the error-message "unable to read unknown location 0x1b" and subsequently always says "??:0"

I'm not sure when this stopped working. Maybe when I did the transition from my PowerPC-iBook to the Intel-MacBook. Or when I switched from Fink to MacPorts. At least it seems to be independent of 32/64-bit

Has anyone an idea how to fix this?
- special format specification with the -g-flag (I tried some, but none seems to work)
- other version of addr2line (Fink?)

BTW: gobjdump seems to work so the binutils do not seem to be completely broken

Bernhard
gschaider is offline   Reply With Quote

Old   August 5, 2009, 13:24
Default
  #33
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Hi!

Another little change: no the dynamic libraries get linked in such a way that the path to them IS NOT hardcoded. This solves the issue with having to copy the "real"-libPStream.dylib over the dummy-libPstream.

I have put the patch on the SVN (URL on the Wikipage). Podallaire, could you have a look if it looks alright/works for other people than me. I'd say we'd keep and update the patch on the SVN until the other issues are resolved (or we're sure they can't be solved). The current patch on the Wiki works and there is no need to confuse people with versions 23 to 42

Bernhard
gschaider is offline   Reply With Quote

Old   August 5, 2009, 13:42
Default
  #34
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
Just had a quick look - interesting ! I will look into it later tonight

Thanks

PO
podallaire is offline   Reply With Quote

Old   August 5, 2009, 19:40
Default
  #35
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
yep, your last changes rock the house !

The addr2line problem is not easy / I will do some search

Thanks for you again for this great contribution, hope that more
people will try it on the Mac

PO
podallaire is offline   Reply With Quote

Old   August 5, 2009, 20:07
Default
  #36
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by podallaire View Post
The addr2line problem is not easy / I will do some search
Don't bother. I solved it (or got an ugly workaround involving gdb and a python.script, to be exact). Will put the patch on th SVN tomorrow
gschaider is offline   Reply With Quote

Old   August 6, 2009, 07:59
Default
  #37
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by gschaider View Post
Don't bother. I solved it (or got an ugly workaround involving gdb and a python.script, to be exact). Will put the patch on th SVN tomorrow
OK. It is now on the SVN (the complete patch that can be used to patch a Release-version). For those who already used the previous patches I attach a patch that only adds this functionality (Line-numbers and Source-files in the backtrace). The patch on the SVN also fixes a bug in the previous patch that broke compilation on Linux.

Probably after applying the patch you'll have to make bin/addr2line4Mac.py executable.

The utility emulates addr2line by asking gdb for the line number that corresponds to the given address. There was also a weird bug where popen does not behave as expected and had to be worked around in printStack.C. Maybe this can be fixed by reimplementing the script in some other language (awk, but I don't want to). Also does this script only get the relative filenames of the sources(not the absolute ones like addr2line on Linux does), but the reason for this seems to be that only the relative names are stored in the binary

For those who want to live with OF 1.5 on a Mac I back-ported the patch to 1.5 and attached it here.

From my point of view the Mac-patch for OpenFOAM-1.6 is feature complete. As soon as I get positive feedback on it I'll put it on the Wiki. For the Third-Party-stuff the only things not working (if I'm not mistaken) are the compilation of Hoard and Paraview on 64 bit. Any news on those?


Bernhard
Attached Files
File Type: gz MacAddr2Line.patch.gz (918 Bytes, 19 views)
File Type: gz MacAddr2Line1.5.patch.gz (919 Bytes, 8 views)
gschaider is offline   Reply With Quote

Old   August 7, 2009, 08:27
Default
  #38
Senior Member
 
Pierre-Olivier Dallaire
Join Date: Mar 2009
Location: Montreal, Quebec, Canada
Posts: 185
Rep Power: 8
podallaire is on a distinguished road
Good morning,

I did not test yet the new functionalities brought by this new patch but I can say it compiles without problem.

Regards,

PO
podallaire is offline   Reply With Quote

Old   September 4, 2009, 02:33
Default
  #39
Senior Member
 
MadsR's Avatar
 
Mads Reck
Join Date: Aug 2009
Location: Copenhagen, Denmark
Posts: 175
Rep Power: 8
MadsR is on a distinguished road
Nice work. If it is any help, I also successfully compiled OF-1.6 using the above guidelines on an iMac running Leopard.

(hey, when is OpenFOAM going to take advantage of all the cool stuff in Snow Leopard? OpenCL for example).

/Mads
__________________
Online free airfoil-mesher for OpenFOAM here
MadsR is offline   Reply With Quote

Old   September 4, 2009, 06:51
Default
  #40
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by MadsR View Post
Nice work. If it is any help, I also successfully compiled OF-1.6 using the above guidelines on an iMac running Leopard.

(hey, when is OpenFOAM going to take advantage of all the cool stuff in Snow Leopard? OpenCL for example).
There's another thread somewhere on the forum on making OF use such Vector-processor-technologies (CUDA, Cell-prozessor). Personally I'm afraid that the potential for these technologies is rather limited with OpenFOAM (memory constraints etc) but I may be wrong
gschaider is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenFOAM13 for Mac OSX Darwin 104 hjasak OpenFOAM Installation 70 September 24, 2010 05:06
problems with installing OpenFOAM 1.6 su_junwei OpenFOAM Installation 8 September 10, 2009 12:54
Problems Installing OF 1.6 32 bit bucksfan OpenFOAM Installation 19 August 4, 2009 01:36
Mac Simple Install Request or Processing Assistance Help sjohnson OpenFOAM Installation 4 December 12, 2008 08:46
MAC + SOLA for free surface T Main CFD Forum 1 April 11, 2001 13:43


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