Fri, 03/11/2011 - 23:01
Forums:
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...
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.
Fri, 03/11/2011 - 23:11
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.
Sat, 03/12/2011 - 01:39
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 ;)
Wed, 12/21/2011 - 01:52
Hello,
Probably, it is a naive question, but how this patch has to be applied, I don't have configure.in file ?
Wed, 01/04/2012 - 04:24
Apply it to configure.ac. That's the one for the newer version of autotools.
Fri, 03/11/2011 - 23:11
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
Fri, 03/11/2011 - 23:12
Oh Denis has it...great.
Fri, 03/11/2011 - 23:14
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.
Fri, 03/11/2011 - 23:31
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.
Sat, 03/12/2011 - 00:18
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
Sat, 03/12/2011 - 07:22
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
Sat, 03/12/2011 - 13:37
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.
Mon, 03/14/2011 - 08:21
OCC650PATCH
Wed, 03/16/2011 - 18:32
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
Thu, 03/17/2011 - 00:01
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
Thu, 03/17/2011 - 16:24
Hi Thomas,
Thanks for your warning.
Regards