[gschaider]

Originally Posted by podallaire

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

[podallaire]

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

[andrewryan]

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?

[podallaire]

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

[7islands]

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.

++ 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

[andrewryan]

@7islands Thx for the hint, now I just need to figure out why metis does not compile..

[podallaire]

try those updated patches

[gschaider]

Originally Posted by podallaire

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

[andrewryan]

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)

[podallaire]

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

[andrewryan]

@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?

[gschaider]

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]

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

[podallaire]

Just had a quick look - interesting ! I will look into it later tonight

Thanks

PO

[podallaire]

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

[gschaider]

Originally Posted by podallaire

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]

Originally Posted by gschaider

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

[podallaire]

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

[MadsR]

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

[gschaider]

Originally Posted by MadsR

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