Mac OSX native cocoa binding


I succeed to have open cascade work in a native cocoa application. It is a port focused on 3d opengl. (There is no OSX_DDriver equivalent to the WNT_DDriver). I big headache digging in OCC source code and some hacks in the occ opengl lib have made the deal.
Everything is working fine, visu 3d, visual transient or NIS view behave properly.

A big thanks to the peoples who have made OCC compilable on Mac OS X.

If there is some interest in it, I could release the port as LGPL or under OCC license (if allowed). I am not an expert in unix makefile so the code still sits in a xcode framework project. If anyone is interested in creating a patch for the 6.3 code base...


Hae-Won Choi's picture

Can you give me detail for that?
I'm interested in installing OpenCascade 6.3 on my Intel Mac OS X.

jelle's picture

Hi Emmanuel,

This is a *huge* deal!
I'd love to have your patch.
Currently I'm working on releasing a package that'll allow for distributing OCC much more easy.
I'm working on a PythonOCC release for OCC, hence the interest to distribute binaries.
Having native cocoa native sure makes supporting a OS X OCC release a lot easier ( no more X11 sounds like a blessing to me! ).
A native cocoa window is a great leap in GUI quality / ease of use.
Thanks _so_ much for your efforts!


Roman Lygin's picture


Kudos ! This sounds great. I have never been using Mac myself, and so can't fully appreciate this accomplishment from technical perspective, but believe this is a great milestone for the product. Let me encourage you to send your modifications to the Open CASCADE team (e.g. Make sure you give them under the OCC public license to ensure full compatibility with original code. I hope that will facilitate official Mac OS X support to appear some day.

--- - blog on Open CASCADE

Stefan Boeykens's picture

I would love to try this out. I have had a working OCC version on my Powerbook, but it relied on X11 and this did not fare well with Qt.

So please share it with the community of OCC developers. That would be really helpful and bringing us closer to new Open Source CAD applications on all platforms.

jelle's picture

[Stefan you should use Qt-X11, that'll work if you have the X11 app running...]

Stefan Boeykens's picture

I know, but last time I tried, Qt4/X11 through fink did not compile. Qt3/X11 did work, so I was able to compile the Qt3 sample from 6.2.0, but my interest was more with Qt4 and the QtOCC project.

Also, it seemed to conflict with having Qt4/Mac installed on the same machine.

P Dolbey's picture

Keep an eye out on the forthcoming Qt 4.5 release for the Max - it promises 64 bits + native Cocoa.

One of the problems with portability is the way that the OCC OpenGL libraries force handling of the rendering contexts, coupled with the (normally, excepting some ATI cards) one HGLRC to one HWND constraint in Windows. This means that you can't reliably use the platform neutral inherent features of QGLWidget. This, me thinks, is an opportunity for a new Qt-compatible TKOpenGl replacement library. Anyone else tried this?


P Dolbey's picture

p.s. Emmanuel, I keep a set of patches for OCC 6.3 in the qtocc svn respository on sourceforge - if you want to send me the modified files, I can incorporate them into this svn. You can email me at peter (at) dolbey (dot) freeserve (dot) co (dot) uk.

You can view the current patches I've got at , where I keep changes fully audited back to the original OCC code.

evalentin's picture

Thanks Peter. I will do that.
I have however a small concern, as I said, the patch is not yet included in the occ make system so it is not possible to get it compiled using the normal configure/make sequence. This yet needs to be done and I am not a specialist of unix make file. Would you do that ?

IMHO as OSX developper, a new OSX build target should be introduced to generate a Mac OSX framework. Then OCC would be fully integrated in a OSX fashion (dylib + headers).

I will publish an URL tonight or tomorrow where to get the source code of the patch and a small sample to see how thinks can get integrated. I first have to check the license because I would publish OCC source code modified.

X11 is not needed anymore. And as far I have expiremented it, I did not notice any issue with graphic or memory mgt with OCC / cocoa / objective-c integration.


jelle's picture

+1 for a framework. that would be terrific indeed.

actually it would be great if the Xcode project can be merged in the CVS too, since its just so much more convenient.
in /ros/adm/win32 are the Visual Studio project files, it would be lovely to have the Xcode project files too.
would you be willing to share those too Emmanuel?

thanks so much for your efforts,


Torsten Sadowski's picture


The smallest possible publication would be

diff -Nurd file.orig file

or was it

diff -Nurd file file.orig

with all changed sources.

Cheers, Torsten

P Dolbey's picture


I'd rather use any new sources directly, so I can diff them against any other patches I have made already.


I should be able to find someone will to integrate the makefiles


evalentin's picture

You can download the source code of the patch in a XCode project and a small sample project at the following URL:

Sorry for the long explanations on this page but I thought they worth to be mentioned.

If you have any question or want to discuss the choices I have made doing this patch, feel free to ask

Henrik Rudstrom's picture

Hi all
Sounds promising, although i havent been successful yet :(
My first question is, is there any reason why the instructions wouldnt work with the precombiled package on wiki?

I tried following your instructions using the .dylibs and .la's from the binary installation, but i stumbled on several issues:
1. I could not find any library that looks like it has anything to do with opengl ("-Copy the OCC dylib files in the XCode project found in the archive. All files but the opengl lib.")

When i try to build it, i get thousands of errors starting with "error: InterfaceGraphic_tgl_all.h: No such file or directory" in OpenGL_tgl_all.h.

Im no expert with xcode, but it seems to me that it needs the header files, but cannot find them, or does should it be able to use only the .dylibs?

I hope this is not an issue with the precompiled occ package, as my attempts to compile occ from scratch has had an equal amount of success.

In any case thanks in advance, and appreciate your efforts!


jelle's picture

Hi Henrik,

I'm Jelle, I run the pythonOCC project with Thomas Paviot.
I'm on OSX too ;')

Henrik, it would absolutely be a huge deal to get a compiled version with the Emmanual's patch.
I hope we can join hands in this effort!

Henrik, regarding the files distributed on pythonOCC, I have to be frank with you and inform you that there are troubles with the wxGTK package.
The module has linked files that arent found on vanilla osx machines, so this is the trouble.
I didnt poor a ton of effort into because I want to move from X11 -> Cocoa.



Henrik Rudstrom's picture

Hi Jelle,
I really hope we can get it working too, although i feel a bit stuck now, have been trying to compile OCC from scratch, using the instructions linked from emmanuels page, but i think i have messed up something with my libtool versions, because i keep getting syntaxerrors on these lines _LT_DECL(build_old_libs, enable_static, 0,

That is why i hoped it would work with your (i presume) binaries. Have you been able to get the patch compiled, or anyone else for that matter?

I will give it another go soon and post back


jelle's picture

Hi Henrik,

Torsten Sadowski wrote up a really good set of instructions to compile OCC on OSX:

States that you do need a recent version of libtool indeed ;')

Henrik Rudstrom's picture

So, finally got it compiled with the binaries from the package, only unsure if it works: Compiling the testapp from emmanuels site works fine, but when i run it it throws "initial dyld memory pool exhausted". interestingly google provides only a single hit to this search, not a very informative one though.

Any clues on how to fix that?

Jelle, once the patch works, what would be needed to get it to work with python?

Henrik Rudstrom's picture

Hi again,
Finally got things working a bit better; the patch and the objective-c example works fine. I'm now trying to rebuild pyOCC and modifying its Visualization module to work with the patch.

I've added this to the headers:

#elif (defined(__MACH__) && defined(__APPLE__))

modified the types for the display classes accordingly:
#elif (defined(__MACH__) && defined(__APPLE__))
Handle_OSX_Window myWindow;
Handle_OSX_GraphicDevice gd;

and added this to my constructors
#elif (defined(__MACH__) && defined(__APPLE__))
gd = new OSX_GraphicDevice();
short quality = 1; //just a wild guess
myWindow =new OSX_Window(gd,(void *)hi,(void *)lo,(void *)quality); //tried Standard_Address in all permutations, wont work

1. all the classes compile, except the Display2D class, as i have no OSX equivalent for Xw_Driver/WNT_Driver.

2. Anyhow i deleted all reference to Display2D and managed to compile pyOCC, but to my disappointment (not too big suprise, have hardly any clue of what i am doing) it gave me this error:

ImportError: dlopen(OCC/, 2): Symbol not found: __ZN10OSX_WindowC1ERK24Handle_OSX_GraphicDevicePvS3_S3_
Referenced from: /Users/henrik/Development/workspace/pythonOCC/src/build/lib.macosx-10.3-fat-2.6/OCC/
Expected in: dynamic lookup

I have the patch installed in /Library/Frameworks/OpenCascade.framework and tried setting DYLD_LIBRARY_PATH although i believe osx should handle that automatically

At the moment im quite clueless, dont know too much about opencascade and swig, c++ is still mind boggling to me, so any ideas would very much appreciated!


Thomas Paviot's picture

Hi Henrik,

I recently moved from an old PC laptop to a new MacBookPro one. I'm currently running Snow Leopard (64 bits) and trying to get pythonOCC work on that platform.

For now, I merged Emmanuel's files with the automake OpenCASCADE system. I tweaked the, aclocal.m4 and files, as well as the TKService package to add native Cocoa/Carbon support. I also modified the original files from Emmanuel in order to compile with the classical ./configure script and I added "Handle_OSX_Window.hxx" and "Handle_OSX_GraphicDevice.hxx" headers to be consistent with the current implementation of the API.

This work is not completed yet, since I still have a few issues with pythonOCC. I will share a patch as soon as I'm done with that.

Best Regards,


Jasper Mine's picture

I'm am very surprised that even seven months later, OpenCascade still is not patched for osx compile. Did you guys send your patches to the devs???

For me out of the box OpenCascade needed GL/gl.h replaced with OpenGL/gl.h in the sources, not the right way, but a least it goes for now... Currently stuck on TCL/TK not being found although its there.

Should I be using svn version? This is open source and we should really try and get OpenCascade compiling good for framework, and osx x11 lib and send our changes upstream.

Anybody want to chat about this please email me right away as I would like to compile salome but need this running first! jsplifer at yahoo dot com

I need your help guys.

Thomas Paviot's picture

Hi Jasper,

Just a question: why should the patches be sent to the OCC dev team since maintenance releases are not public? Send a patch today and the result will be available in 2010 or 2011 (what is the plan for the next public release?). If OpenCASCADE source code was available somewhere on a CVS/SVN server, it would be a pleasure to release and share patches.

Best Regards,


Paul Jimenez's picture

Because it is required by the license. It also helps improve the library, even if it feels unfair how long we have to wait to see our patches available in the next public release.

Thomas Paviot's picture

I disagree with you: nothing, in the complete license text, explictely tells to share modifications with the dev team (excepted the first 3 lines that are not part of the license). The licensing issues were already discussed here: . If you have further information, can you please share it?

On the other hand, it's true that we all have an interest to improve the library, and I'm completely ready to do so. I just wait for a public svn/cvs repository to commit patches. Such a repository would not necessarily have to be set up or maintained by the OCC dev team. The current way of sharing code is not really up-to-date with basic open source tools/workflows: post a patch here, on this forum, and tag it with OCC_PATCH can be considered as a 15 years-old solution, no?

Jasper Mine's picture


Very good to get a response! The Salome forum is quite dead for an osx user with questions. And I would love Salome running on osx.

I was not aware of OpenCascade contribution issue. Your right it seems to be mostly forum based.

So does OpenCascade compile on osx? Is there a step by step tutorial on how to compile? I will try and collate all data on osx and compile from these forums and give it another go.

Thank-you for your input. I should probably make a new thread? Step by Step OSX compile?

Thomas Paviot's picture


OpenCascade compiles on osx: see this thread It describes the way to get a proper X11 based OCC. The compilation process works perfectly on OSX 10.6 (Snow Leopard) 64 bit.

The other issue is related to a Cocoa based OCC implementation. The first post of the current thread is quite ambigous: Emmanuel's patch is not Coacoa native but rather a Cocoa/Carbon mix. If you want to get it compile with the ./configure script, it's much more work than a simple replacement of GL/gl.h with OpenGL/gl.h. I'm looking forward to discussing this topic with other OCC/OSX users (and especially SL 64 bits users).

I don't know exactly whether or not this work can be connected to Peter Dolbey's qtocc project ( The next Qt release (4.6) will actually be Cocoa based, and 64 bit compliant ( Qt4.6 + qtocc might be a way to have a native Cocoa implemtation of OpenCASCADE, with 64 bits support. If it's doable, then the svn repository of this project could be used to share MacOSX/OCC code.


Foo Bar's picture

I realize this is a rather old thread, but the upthread link to native OSX OpenCascade from Emmanual seems to be broken.

Is there a new source for this code? I'd be happy to spin up a google code or other repository to host it.


Dr Chris Lee's picture

Hi Emmanuel

I know it is a few years ago and the link does not work, but is there any chance you could post it again somewhere that does work



István Csanády's picture

hey, can you send me the cocoa bindings? the link is broken. istvancsanady (o) gmail _ com