Bug 220873 - cad/opencascade: patch-src_STEPConstruct_STEPConstruct__AP203Context.cxx is wrong
Summary: cad/opencascade: patch-src_STEPConstruct_STEPConstruct__AP203Context.cxx is w...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Thierry Thomas
URL:
Keywords: needs-qa, patch
Depends on:
Blocks:
 
Reported: 2017-07-20 03:53 UTC by rcarter
Modified: 2018-02-17 19:49 UTC (History)
1 user (show)

See Also:
thierry: maintainer-feedback+
koobs: merge-quarterly?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rcarter 2017-07-20 03:53:30 UTC
Opencascade patch-src_STEPConstruct_STEPConstruct__AP203Context.cxx is wrong

root@bruno> more patch-src_STEPConstruct_STEPConstruct__AP203Context.cxx
--- src/STEPConstruct/STEPConstruct_AP203Context.cxx.orig       2016-11-25 09:52:26 UTC
+++ src/STEPConstruct/STEPConstruct_AP203Context.cxx
@@ -123,7 +123,7 @@ Handle(StepBasic_DateAndTime) STEPConstr
     long shift = 0;
     _get_timezone (&shift);
   #else
-    Standard_Integer shift = Standard_Integer(timezone);
+    Standard_Integer shift = Standard_Integer((long long)timezone);
   #endif
     Standard_Integer shifth = abs ( shift ) / 3600;
     Standard_Integer shiftm = ( abs ( shift ) - shifth * 3600 ) / 60;
--More--(END)

timezone(3) on FreeBSD is a function whose address is a long long; on Linux, via tzset(3) it is a global long integer.  Indeed the patch compiles, but I doubt the result is what is intended.  I fixed this before getting so disgusted with opencascade which required purging everything associated.  I regret that, I should have kept my git branches around.

Anyway the solution is from memory a short static helper function inserted in
the source directly above the inline definition.
Comment 1 Thierry Thomas freebsd_committer 2017-07-20 17:10:34 UTC
Thanks for the notification!

Have you a tested patch?
And a test case?
Comment 2 rcarter 2017-07-21 00:02:41 UTC
Sorry, as I said, I deleted everything I did out of disgust with opencascade.

If you look at tzset(3) on linux and compare to timezone(3) in FreeBSD you will see that the semantics are different.  In order to get the correct semantics a short helper is required.  I put it right above the patched definition, ISTR.

Best of luck.  FreeCAD as ported to FreeBSD (based on opencascade) is currently completely unusable. I worked through the first 10 or so youtube tutorials on 0.16 on linux, and FreeBSD's 0.17 crashes when trying to open the files.  To try to fix these I started with opencascade, but as I mentioned, a white hot fury rose up as I got deeper and deeper.... sorry.

One more tip, I am quite experienced at cmake builds, even complicated ones, and it's clear to me that with this newer version of opencascade they are trying to make their cmake build system sane.  I wouldn't fight that.

Anyway, I hope that eventually opencascade and freecad are usable on FreeBSD.
Comment 3 Thierry Thomas freebsd_committer 2017-07-31 15:21:34 UTC
You are right about (long long)timezone, but I guess that your problem with FreeCAD has another cause. Since this latest upgrade (see PR 220110), several users reported that FreeCAD is now much better for them.

I do not use FreeCAD anymore myself, but I have tested DRAWEXE and GMSH built from cad/gmsh-occ, and both of them can use files from the OpenCascade project (STEP and STL format).

Could you please provide some debug infos with your test case?
Comment 4 Thierry Thomas freebsd_committer 2017-12-28 16:38:06 UTC
Please check https://reviews.freebsd.org/D13665
Comment 5 Thierry Thomas freebsd_committer 2018-02-17 19:49:39 UTC
Sould be fixed in 7.2.0.