Quote:
BTW: I noticed on the Paraview-list that you're busy with the Cocoa/64-bit-QT |
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 |
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? |
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 |
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 @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 Thx for the hint, now I just need to figure out why metis does not compile..
|
1 Attachment(s)
try those updated patches
|
Quote:
|
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) |
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 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? |
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 |
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 |
Just had a quick look - interesting ! I will look into it later tonight
Thanks PO |
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 |
Quote:
|
2 Attachment(s)
Quote:
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 |
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 |
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 |
Quote:
|
All times are GMT -4. The time now is 03:21. |