SourceForge Logo
Autoconfiscating Open CASCADE

This page was created to aid Open CASCADE developers in porting and configuring Open CASCADE (OCC) on currently unsupported platforms.  This page also includes descriptions and some fixes for common problems implementing OCC.

    Why is a configure script needed?
Currently users have a tough time getting a simple example to run because of several reasons.

  • Because Open CASCADE is a library, you must use a compiler with it.  If you don't use the same version of the same compiler that Matra used to build OCC, you are likely to have problems.   If you don't have the same compiler, i.e. you don't have an ABI compatable compiler, you are completely out of luck.  The reason is that the OCC interface is C++ classes.  C++ classes provide the most intuitive and usable interface for a library such as this one, but C++ classes use name mangling of functions to allow for overloading.  If the name mangling schemes are not identical, sometimes this changes between versions of the same compiler, then the linker will be looking for the wrong names and any attempt to resolve symbols will fail.
  • For a particular platform, Open CASCADE binaries are linked to a particular Tcl/Tk library version.   Under IRIX, this is version 7.5i.  Doesn't sound so bad?   Try to download an IRIX binary for Tcl version 7.5i, there aren't any available! You would have to download the Tcl 7.5 source, compile it, install it, and then rename or link the shared libraries to the name

  • Autoconf handles this problem by linking to whatever you have installed.
  • If you don't have a supported platform, you are also out of luck.   With Autoconf, the features of the system are checked when the source tree is 'configure'd.   Often times a new platform can be compiled with no changes whatsoever.  GNU Libtool provides the only portable mechanism for using shared libraries, if Libtool has been ported, you shouldn't have any problems building and using Open CASCADE.  Note also that Libtool supports many more systems than Open CASCADE currently does.
  • Another reason to use Autoconf is that it will continue to be usable, as compilers and development tools evolve, Autoconf will evolve to handle these yet to be defined issues.
  • Autoconf is the "Open Source" way. 
The idea is to use GNU Autoconf, GNU Libtool and GNU Automake to create a portable bourne shell script "configure" that will generate makefiles and a configuration header file.  The configure script will test the system in a number of ways and create the configuration header "config.h" based on these tests.
   Currently, there is only one developer working on this project, so if you would like to help test please volunteer!

Introduction to GNU Autotools:

       Documentation for Autotools with Open CASCADE

How to build:

       Check the build instructions page.

 To do list:

  1. Shared installations of Open CASCADE need a better way to determine the platform they are running on. The 'uname' command is far too coarse to be used for this purpose, as all Linux systems reply with "Linux" no matter what processor they are running on.  Preferably the GNU Config scripts, config.guess and config.sub would be used for this as they have the fine-grained control needed to sort out the proper binaries to use on any particular platform.
  2. Running WOK requires users to have TclX and expect installed as shared libraries, perhaps these could be auto-configured when these libraries are present in the source directory.  This would be a great project for someone who is just getting started because it would probably not involve changing anything, just adding some checks and calls to ""
  3. Add Autoconf macros for Java support.   Open CASCADE uses Java in a few places, but the current configure script doesn't look for a Java compiler, only the Jni headers.   Automake and Autoconf have Java support, so it is possible to integrate this as well.   The TKjcas library is not built if jni.h is not found, the build won't stop in FoundationClasses it the headers aren't found.
  4. Test on every platform possible.


    It is my intention to integrate all of these changes into Matra's main CVS repository when they are finished.  This will be a major improvement in the current state of Open CASCADE.  I have recently gotten assurances from Matra Datavision employees that this work will be incorporated into the main CVS repository.
    Update:   The entire project was handed off to the Open CASCADE developers at Matra on April 30, 2001.   I have not recieved any notification from Matra that they are using this work, nor have Matra's CVS sources been updated with the new build system.   This project will remain on SourceForge until the time that Matra has fully incorporated Automake, Autoconf and Libtool into their CVS repository sources.   If you are considering becoming a contributor to this project but unsure of it's future, I assure you that if there is anything of use to anyone in this project, it will remain available.
This page is in no way officially connected to Matra Datavision.