Salome on mac os x

That's amazing !!! Cannot wait to try SALOME 5.1.3 - will it be out soon ?

I'm currently trying to compile 5.1.2 following those instructions

 

Regards,

 

PO

Hello, and Happy New Year,

Hello again,

I have updated the files about SALOME on Mac, following the publication of SALOME 5.1.3 :

http://files.salome-platform.org/edf/SalomeBuildWithFink.html

http://files.salome-platform.org/edf/SalomeBuildScripts_20091214.tgz

The same screenshot as above: http://files.salome-platform.org/edf/Screenshot_2009-11-22_21.35.12.png

 

 

Paul

Hi,

It looks like everything is ready to start the Qt Application, and the Gui stops silently...

The only idea I have now is to add some prints, after SALOME_SessionServer.cxx line 534,  or use the debugger if your are familiar with gdb or ddd and if you have it in your environment.

It is possible to launch Salome with ddd or gdb on the Gui process with the command :

./runAppli -k --ddd-session     or     ./runAppli -k --gdb-session

and run, when you have the prompt.

Maybe you will find where it goes wrong...

Another thing you can do is send a tarfile containing the env.d directory in your application, config_appli.xml and the environment file you use in your application (prerequisites path in config_appli.xml).

I am looking for other things to test.

Paul

 

Hello,

I've successfully built Salome 5.1.3 (KERNEL / GUI /GEOM / MED / SMESH/ VISU /YACS) using the Paul's patches and advice.

Next steps for me is to pass all the qualification tests (Same tests as for Linux final 5.1.3 release).

 

Also, I've seen that Qt supports Cocoa, Vtk supports Cocoa, I've seen also some OCC Cocoa bindings (Thanks Torsten). Thus I'm thinking that we could have a Cocoa Salome faster than I expected.

 

Cheers,

 

Nicolas 

Hello, First to answer to you Jasper, tcl/tk is not needed if you want to use OpenCascade only for Salome. Tcl/Tk is only needed for the "Draw" executable of Cascade. You can disable some other features of Cascade as follows : flags="$flags --disable-debug --enable-production" flags="$flags --disable-jcas" flags="$flags --disable-draw --disable-wok" ./configure $flags --prefix=${INSTALL_DIR} ... Then, let me mention that Paul and I are 2 guys from the Salome development team. As a hobby (at home only), we start working on the Mac Os X porting of Salome 5. We got our Mac Book pro 2 weeks ago Jasper, we're analyzing the Mac Os X development stuff, trying to take basic decisions such as autotools vs cmake, Xcode or not... Nicolas

Hello jelle, Nicolas,

Hello,

I am also interested to run Salome on os x.  Any compile tutorial out there?  Unbelievable this application is out for several year with no mac interest.  Where are you guys hiding?

Thanks.

 

I'm curious; of course I do realize that this thread discusses an experimental build for osx. Having said that, I'm wondering whether it would be possible to discuss whether binaries of this experimental build could be uploaded somewhere ( I would be happy to provide storage/bandwith ). Building Salome for sure is not for the faint hearted / compiler challenged. Some time ago, Torsten has been so kind to provide me with the libs of OCC, which meant a lot to me. 

Good evening !

 

This thread has been very quiet over the last 5-6 months / any news, progress, thoughts to share ?

 

regards,

 

PO

And the other one.

Hello,

As Nicolas said above, we have been working for a few days on the Mac OsX porting of Salome 5. Things are falling in place faster than I thought : I have a first part of Salome that compiles and works! (KERNEL, GUI, GEOM). SMESH starts also but there are still a lot of things to fix.

We have been working with the Fink packages (http://www.finkproject.org) on Snow Leopard, and with the release candidate of SALOME 5.1.3.

SALOME 5.1.3 will be released and published in a few days, unless too much last minute bugs. I think we will publish our patches for Mac Here soon after the 5.1.3 publication.

I will elaborate more on our solution in another message, this is a preliminary solution. A lot of work is needed to obtain clean patches, and help from people who knows better Mac Os than us will be wecome!

Paul

Hello,

SALOME 5.1.3 is now really starting to work on Mac, (KERNEL, GUI, GEOM, SMESH and VISU), with still with a lot of things to fix. 

A screenshot: http://files.salome-platform.org/edf/Screenshot_2009-11-22_21.35.12.png

I have summarized our work in the following link:

http://files.salome-platform.org/edf/SalomeBuildWithFink.html

You will find in this document the current state of the porting, and the scripts and patches, also available here:

http://files.salome-platform.org/edf/SalomeBuildScripts_20091121.tgz

The patches are applicable to SALOME 5.1.3, not yet published, but it can be helpful for all of you who are working on the SALOME porting on Mac Os X: our solution based on Fink is perhaps not the easiest way for the end user (a lot of packages to compile and install), so all ideas to make a lighter integration are welcome!

There is still a lot of work to do on the patches to have them integrated in the source code (regroup several things in a portability layer, for instance...).

If you have difficulties to acces the links above, let me know.

Paul

Hello,

On my previous message about SALOME on Mac, I forgot a patch file about Med.

The links are updated:

http://files.salome-platform.org/edf/SalomeBuildWithFink.html

http://files.salome-platform.org/edf/SalomeBuildScripts_20091122.tgz

Paul

Congratulations on the Salome release!

Cool news!  I'm sure the elves were very busy to have this finished in time for Christmas.

I will follow your instructions on 5.1.3 compilation, thank you very much for taking the time to do this.

Hope you have a happy holiday.

Jasper

Good morning,

I compiled the whole thing / however, when I start the application, I can see the startup screen but I get this :

INTERRUPTION from thread 0x10688c000 : - INTERRUPTION: /opt/salome_5.1.3/tarpublic/GUI_SRC_5.1.3/src/Session/Session_ServerThread.cxx [279] : CONDITION 0 NOT VERIFIED

error close LocalTraceCollector : 11

Hi,

Other comments:

I don't think hdf5 compilation with 4.2.1 or 4.4.2 will make any difference at that stage of the SALOME starting process, but after that, I don't know... I used the hdf5 provided by Fink and compiled with 4.4.2.

The only thing I am sure is I needed to use either 4.2.1 or 4.4.2 depending on the product compiled to get something that works, but I still don't understand very well the bugs I have found with both versions of gcc.

Paul

...something that I forgot to mention is that I get the splash screen, but nothing after / see attached

Thanks

PO

Hello,

I mentioned I would report my progress.  So here it is.

I am currently having trouble with the compile of the opencascade prerequisite.  I am stuck there.  It goes but openGL, tcl/tk are not being found during configure.  I am in communication with builders on the opencascade forum.

Jasper

Hi Nicolas, Jasper,

Its *wonderful* news to hear that you guys are working on porting Salome to OSX!

Having Cmake sure would be an _absolute_ blessing, and as Jasper mentions can be considered a superset of make and Xcode. So +1 ;')

Something we're working on at the PythonOCC front is to be able to start a Quartz window from OCC. This is pretty important since Carbon support is deprecated and X11 can be a hassle in some cases. Are you guys interesting in that at all? Its a wild guess, but perhaps this effort can be shared.

Nicolas, would you mind sharing with us how far you've managed to compile Salome?

Wonderful to see all this OSX activity, this is a terrific thread!

Cheers,

-jelle

 

jelle,

Hi, I am probably jumping the gun here without knowing the current status of Salome running on osx.

 If it does not work on osx I would recommend trying to get it working on osx's x11 first as the differences between linux and osx are not that great.  Alot of back and forth communication would be necessary feeding each other gcc errors etc.  So perhaps an irc channel on freenode.net to communicate the compiling progress and fixes?  And then relay actual progress to a thread in the forum?

If Salome does work in osx X11 then steps to cocoa-fy the window management and links to cocoa libs could be an option, I'm not sure if this is such a priority, but one benefit might be running Salome in OSX as a 64bit application.  I am interested in your project jelle, although I'm not sure what PythonOCC is.  From other forum posts it seems like your trying to package OpenCascade into an apple friendly framework?  Again good path if Salome is stable in its X11 configuration.

OK.  So I started a channel on freenode.net called #Salome.  I have a bit of osx compiling experience as I have hacked this to work on osx http://epsylon.rptd.ch/forum/viewtopic.php?f=24&t=251  I also was doing at one time the package maintaining for blender 3d as the osx intel manager http://wiki.blender.org/index.php/Dev:Ref/Release_Checklist  And I do beta testing for various windows and *nix to osx platform transition beta testing.  With that said, I am not a very good coder so I will need help, lots and lots of help to make any progress.  If anybody reading this has good knowledge of the coding language and the internals of Salome I ask you join the irc channel, I will wait there.

Hope to hear from you.

Jasper

Hello,

The other process are still alive... I red more carefully the code in Session_ServerThread.cxx. The normal behaviour is:

• check the presence of /Registry in CORBA Naming service : normally, it must not be present. (line 276)
  
• when not present,
  
• throw an exception (line 277),
• catch it (line 281),
• register a new instance of /Registry in Naming Service (line 285)
• and continue...
  
• if /Registry is found, 
• print a message (line 278) "RegistryService servant already existing"
  
• and abort (line 279)
  

Sometimes, aborts occurs too early, before the print of  last lines of trace.

A simple test could be to comment or remove the line 279: ASSERT (0); in GUI_SRC/src/Session/Session_ServerThread.cxx and recompile only GUI Module,
then run SALOME, and give me the trace in console ( keep the option --enable-debug when compling the all the modules, to have a trace).

I have attached my trace as an example of what happens when SALOME starts correctly.

 

Hi Paul,

I tried to modify and recompile the GUI module / same result unfortunately. I'm sending my trace for your review

Thanks

PO

Good Evening,

There is a probably a problem with omniOrb, but can't guess the exact reason. I suppose the process omniNames has been started and aborts (I had this problem when onmiNames was compiled with g++ 4.4.2 instead of 4.2.1)

Could you give me more information ?

- all the trace in the console,from the runAppli command to the last message,

- the process still alive after the message : (command ps -jx) : when SALOME is running we have something like :

prascle   508     1   507 8638d68    0 S      ??    0:00.02 omniNames -start 2810 -logdir /tmp/logs/prascle/omniNames_2810 -errlog /tmp/logs/prascle/omniNames_2810/omniNameErrors.log
prascle   512     1   511 8f22380    0 S      ??    0:01.26 SALOME_Session_Server --with Registry ( --salome_session theSession ) --with ModuleCatalog...
prascle   514     1   513 8638138    0 S      ??    0:00.07 SALOME_LauncherServer --with Registry ( --salome_session theSession ) --with ModuleCatalog…
prascle   516     1   515 86384e0    0 S      ??    0:00.04 SALOME_ConnectionManagerServer
prascle   518     1   517 8f224b8    0 S      ??    0:00.21 python /Users/prascle/projets/SALOME/Run/V513/bin/salome/SALOME_ContainerPy.py FactoryServerPy

- the log files  in /tmp/logs/<yourLogName>

Thanks,

Paul

 

 

Hello,

Salome is now running great on my  MBP with X11 and Fink, I'm trying to get it with Cocoa now. Then I've started to work with native products. I've got Qt Cocoa (4.6.0) Ok , Vtk Cocoa (CVS) Ok and I'm starting the process for OpenCascade following instructions of this link. 

 

In this link, I compile using Torsten's procedure and I have a question/remark for Torsten , I think you forgot to mention to load the fink environment for autools issue, but I may be wrong, am I ?

 

Cheers,

 

Nicolas 

I am also very interested any news?, Did you already submit a request to the fink project?

 

Thanks

Hello,  

In a day and a half Torsten was able to get Kernel compiling using cmake.  I also have kernel compiling on my system with an error in swig at the moment.  I was very happy to see him join the IRC channel.  Obviously Kernel is a small fraction of the whole that is Salome but I'm glad to see Torsten's progress.  

Good news on the Salome 5.1.3 release!!!  And I hope we can get working on the mac port as soon as possible after your public release.

Paul, interesting news about more of the modules compiling.  I sure am eager to see the edits to source to make this these modules compile.

Thank-you for the interest and progress guys!

Jasper

I'm really thrilled by all the effort on developing a osx build.

However, making such a build is such a massive effort.

I wonder whether we could organize a repository / location where binaries can be uploaded such that the effort of doing so can be distributed. I'm willing to offer server space for sure. It would be just so cool to rsync to a salome build, rather than having to spend a massive effort trying to build it. This coupled with a repository for Code_Aster would be really a great improvement?

Idea?

 

-jelle

Hello everybody,

 

For your information, I've got a first draft of Salome on Mac OS X with Cocoa support. It implies that I had to re-build some prerequisites specially for Mac OS X (Qt 4.6.1 Cocoa, Vtk 5.4.2 Cocoa).

After many patches, as a result, I've got a native Salome Cocoa GUI (including the VTK  Cocoa viewer) compiled  with Mac OS X frameworks.

 

Today, there are 2 main problems :

 

 - I've got lot of bugs related to the Apple STL  (specially about the string type in STL). This is the first project I'm managing with Mac OS X. Is it a known problem ??

 

- The OpenCascade library is not ported today, i.e. the GEOM module in Salome is only available through Python scripts. This is the next step (but it's a very big one).

 

I'll provide patches for each module in the next days.

 

Cheers,

 

Nicolas

Hi Jasper,

Thomas & I ( the developers of PythonOCC(.org) ) are both working on OSX.

Perhaps we can offer some help?

 

-jelle

Happy new Year!

 

I will try to build fink packages for the prerequisites and maybe later for salome itself. Right now I've got omniorb and omniorbpy. To use them the .info files must be copied into 

 

/sw/fink/dists/local/main/finkinfo/

I don't know when (if at all) the packages will appear in fink unstable.

 

Cheers, Torsten

Hi,

I have compiled omniOrb with gcc 4.2. I have this from a ps -jx after trying to launch ./runAppli :

podallaire  1742     1  1741 8704fd8    0 S      ??    0:00.21 omniNames -start 2810 -logdir /tmp/logs/podallaire/omniNames_2810 -errlog /tmp/logs/podallaire/omniNames_2810/omniNameErrors.log

podallaire  5300     1  5299 90ab728    0 S      ??    0:00.04 SALOME_ConnectionManagerServer

podallaire  5298     1  5297 8705d40    0 S      ??    0:00.06 SALOME_LauncherServer --with Registry ( --salome_session theSession ) --with ModuleCatalog ( -common /Users/podallaire/../../op

Thanks for you time Paul / I will jump into the print statements later today

In the meantime, I'm sending my myAppli directory + env file as requested.

Regards,

PO

I checked your configuration and found nothing.

The following lines in your environment are not necessary, but I created an application with these modifications to check if there is a side effect, but it still works for me. Everything looks OK so far.

export PYTHON_ROOT=/sw
alias python="/sw/bin/python2.6"
export KERNEL_ROOT_DIR=${PRODROOT}/Install/KERNEL_V513
export GUI_ROOT_DIR=${PRODROOT}/Install/GUI_V513
export GEOM_ROOT_DIR=${PRODROOT}/Install/GEOM_V513

Paul

It would be just  _wonderful_ to see Emmanual's patch integrated in OCC. Thanks so much for keeping us posted of your efforts Nicolas, it would a wonderful achievement to have OCC & Cocoa / Quartz working together!

Cheers,

-jelle