For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

6.5.0 fails to build on OS X because of dependencies to obsolete FTGL headers

Jens Kilian's picture

I'm trying to build the new release on OS X, but have run into a nasty dependency problem. I'm using the FTGL library I get from macports, which is fairly recent (2.1.3-rc5). Unfortunately, OpenGl_FontMgr.cxx wants to include some header files (FTFace.h, FTLibrary.h) that are no longer installed in that version.

I've tracked this down to a 3 years old(!) change in the FTGL repository:
http://ftgl.svn.sourceforge.net/viewvc/ftgl/trunk/src/Makefile.am?r1=973&r2=974

Does anybody have a suggestion how I can do either of the following:
- fix the dependency
- build OCC 6.5.0 without FTGL?

Thanks,
Jens.

Denis Barbier's picture

Hi Jens,

Here is a patch for you :-)
It builds fine on Linux, I did not send it yet because I did not test it.
Please tell us if it works for you.

Attachments: 
Denis Barbier's picture

Hi again,

Here is a revised patch. After checking that it cannot build with ftgl 2.1.2, I do no more worry about backward compatibility and make further changes to have this version more compliant with newer ftgl ;)

Attachments: 
Chaman Singh Verma's picture

Hello,

Probably, it is a naive question, but how this patch has to be applied, I don't have configure.in file ?

Sharjith Naramparambath's picture

Apply it to configure.ac. That's the one for the newer version of autotools.

Venugopal Gudimetla's picture

Hi Jens,

I had the same problem while building on ubuntu 10. the headers FTLibrary.h FTGLTexture.h etc are not being copied to their installed directories for some reason. The workaround what I found was to get the latest ftgl from sourceforge build the libraries and then copy the headers and libraries to the final location your self than depend on installers. I gave the installation directory paths to be the same where the installers would install the libraries (/usr/lib)and header (/usr/include/FTGL) in my case and then in the makefile of TKOpenGl make directory, I specified the paths of libraries and include files in the Makefile. If this is a patch then I can provide the details.

once this is done, everything was smooth.

Venu

Venugopal Gudimetla's picture

Oh Denis has it...great.

Denis Barbier's picture

Hi Jens,

Here is a patch for you :-)
It builds fine on Linux, I did not send it yet because I did not test it.
Please tell us if it works for you.

Attachments: 
Roman Lygin's picture

Jens,
Note that OCC claims to support 2.1.2 (http://www.opencascade.org/getocc/require/), not 2.1.3-rc5. I think I met similar problem when tried to build with 2.1.3-rc5 on Windows and had to rollback to 2.1.2.

Denis: To ensure more smooth user experience, I believe we need to stick to the policy of providing patches as complete as possible. For instance, if something has to be changed in autotools scripts, attention should be made to provide corresponding MSVS project updates. This may lead to headache of manual maintenance of multiple configurations (32-64, vc8-vc9-vc10), so modifications in the build system should rather be reasonably conservative. I don't know if this applies to your patch, it is just rather a general comment. By the way, does your patch retain support of 2.1.2 (which must be ensured).

Thanks for lightning-fast fixes ;-).

P.S. MSVS files could likely be WOK generate-able but I have never really tried that.

Fotis Sioutis's picture

Roman

MSVS (and not only ...) files are WOK generate-able and i am quite sure that the OCC team creates the project files with this way. But where is WOK ? It has been excluded from the latest release and i had no answer when i asked about it on the initial announcement thread.

Sorry for being slightly off topic

Fotis

Thomas Paviot's picture

Hi Jens,

I'm also trying to build the latest release for OSX but I failed to get something working so far. I however followed the solution provided by Torsten (see http://www.opencascade.org/org/forum/thread_14128/) for the old 6.3.0.

Before I post the traceback, I have to be sure I didn't make any mistake. How did you manage to get so far in the compilation process?

Thomas

Jens Kilian's picture

Right now the problem I reported is the only one I have left. I made several changes to get so far:
- Applied a patch by Roman Lygin (http://opencascade.blogspot.com/2010/04/porting-on-macos.html) for making atomic operations work.
- Patch OSD_Chronometer::GetProcessCPU() the same way.
- Stub out OSD_Chronometer::GetThreadCPU(), which luckily isn't called from anywhere, AFAICT.

I also made some changes to configure.in to get rid of some errors while running configure, and ran autoreconf to regenerate the whole mess
(using the latest autotools from macports).

I plan to write this all up when I've finished, hopefully sometime this weekend. The OSD_Chronometer changes are attached.

Bye,
Jens.

Attachments: 
Andrey BETENEV's picture

OCC650PATCH

sergey zaritchny's picture

Thanks for reporting the problem.
Patch has been registered with ID = OCC22328.
Later you can check it via the specified ID in OCCT Release Notes.
Regards

Thomas Paviot's picture

Hi Sergey,

You should be careful: the provided patch only disables this feature from the MacOSX version of OCCT. This fix the compilation process but I'm afraid OCCT will not have the expected behavior.

A better patch was committed to the db/ports branch of the OCE project: https://github.com/tpaviot/oce

Best Regards,

Thomas

sergey zaritchny's picture

Hi Thomas,
Thanks for your warning.
Regards