ana(conda) windows packaging

Having trouble installing or compiling FreeCAD? Get help here.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: ana(conda) windows packaging

Post by looo »

freecad with occt7.0.0 uploaded
install with

Code: Select all

conda create -n <name> freecad occt=7.0.0
or within an environment it should be possible to do the following:

Code: Select all

conda install freecad netgen occt=7.0.0
ps.: for the experts: reading the Upgrade to OCCT 7.0.0 / Removal of CDL and WOK / could be interesting:
https://www.opencascade.com/doc/occt-7. ... cct700_cdl
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: ana(conda) windows packaging

Post by looo »

If I understand the answer correctly then we should change GeomLineSegment::setPoints in Mod/Part/App/Geometry.cpp (line 3178) from

Code: Select all

Handle_Geom_TrimmedCurve::DownCast(handle()) 
to

Code: Select all

Handle(TrimmedCurve)::DownCast(handle()) 
Maybe we could use there upgrade tool to update the Handles used in our source code?
https://www.opencascade.com/doc/occt-7. ... 0_cdl_auto
peterl94
Veteran
Posts: 1001
Joined: Thu May 23, 2013 7:31 pm
Location: United States

Re: ana(conda) windows packaging

Post by peterl94 »

Indeed! That fixed the issue. Their upgrade script worked great. I wonder how backwards compatible the changes are? According to that post "Handle() has been always recommended way for declaring classes - Handle_ is rather internal" it sound like it is. Do you think I should pursue a pull request or just a patch for conda? The script makes small changes all over the place and I don't know if all Handle_ changes are necessary: "148 files changed, 2235 insertions(+), 2257 deletions(-)"
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: ana(conda) windows packaging

Post by looo »

I would vote for a PR, because not only conda is affected. As travis is still using oce, we will see if it is backwards compatible.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: ana(conda) windows packaging

Post by sgrogan »

peterl94 wrote:Indeed! That fixed the issue.
Peter, do you have a brach somewhere? I can test on VS2013
"fight the good fight"
peterl94
Veteran
Posts: 1001
Joined: Thu May 23, 2013 7:31 pm
Location: United States

Re: ana(conda) windows packaging

Post by peterl94 »

sgrogan wrote:Peter, do you have a brach somewhere?
Now I do. https://github.com/peterl94/FreeCAD_sf_ ... pgrade-tmp

Note that I have only tested Part and Sketcher.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: ana(conda) windows packaging

Post by sgrogan »

peterl94 wrote:Now I do. https://github.com/peterl94/FreeCAD_sf_ ... pgrade-tmp
Thanks! VS2013 only switching out occt7.1/occt7.0 compiles and passes all self tests. A quick run thru Sketcher, Part, Part design, and Reverse engineering shows no problems.
on
OS: Ubuntu 14.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10793 +1 (Git)
Build type: Unknown
Branch: occt-upgrade-tmp
Hash: 02f9d102b9d5043bc111c78eaad9bb6e9fced3ec
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.9.1.oce-0.18-dev

Same thing everything looks good.
What's the next test occ 6.7?
"fight the good fight"
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: ana(conda) windows packaging

Post by wmayer »

peterl94 wrote:
DeepSOIC wrote:Reading the internet, I found that /GR- flag should be added to compiler for dynamic_casts to work
I saw that too, but I checked the compiler flags and /GR is present. I wonder if it is a problem with a 3rd party library.
Just to be clear with /GR- you actively disable RTTI. The standard behaviour is that RTTI is enabled (/GR). As a test have a look at this example:

Code: Select all

class A {
public:
    virtual void test()
    {
    }
};

class B : public A {
public:
    virtual void test()
    {
        int i=0;
        i++;
    }
};

int main(int, char **)
{
    A* a = new B();
    B* b = dynamic_cast<B*>(a);
}
When you build it with cl main.cpp everything is fine. When you build it with cl /GR- main.cpp then the compiler raises this warning:
main.cpp(20) : warning C4541: 'dynamic_cast' used on polymorphic type 'A' with /GR-; unpredictable behavior may result
And when running the application it crashes and the debugger shows this message:
Unhandled exception at 0x000007fefd5aa06d in main.exe: Microsoft C++ exception: std::__non_rtti_object at memory location 0x0022fbc8..
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: ana(conda) windows packaging

Post by wmayer »

In occ7.0 the Handle_ class is defined as:

Code: Select all

//! Define Handle() macro
#define Handle(Class) opencascade::handle<Class>
#define DEFINE_STANDARD_HANDLECLASS(C1,C2,BC) class C1; typedef Handle(C1) Handle_##C1;
This means Handle_Something is an alias for Handle(Something) and thus exactly the same.

In occ7.1 Handle_ is defined differently for VS2013 and later:

Code: Select all

//! Define Handle() macro
#define Handle(Class) opencascade::handle<Class>
//! For compatibility with previous versions of OCCT, define Handle_Class alias for opencascade::handle<Class>.
#if (defined(_MSC_VER) && _MSC_VER >= 1800) 
//! For Visual Studio 2013+, define Handle_Class as non-template class to allow exporting this type in C++/CLI.
#define DEFINE_STANDARD_HANDLECLASS(C1,C2,BC) class C1; class Handle_##C1 : public Handle(C1) \
{ \
public: \
  Handle_##C1() {} \
  Handle_##C1(Handle(C1)&& theHandle) : Handle(C1)(theHandle) {} \
  template <class T2, typename = typename std::enable_if <std::is_base_of <C1,T2>::value>::type> \
  inline Handle_##C1(const opencascade::handle<T2>& theOther) : Handle(C1)(theOther) {} \
  template <class T2, typename = typename std::enable_if <std::is_base_of <C1,T2>::value>::type> \
  inline Handle_##C1(const T2* theOther) : Handle(C1)(theOther) {} \
  template<typename T> inline Handle_##C1& operator=(T theOther) { Handle(C1)::operator=(theOther); return *this; } \
};
#else
//! For other compilers, use simple typedef
#define DEFINE_STANDARD_HANDLECLASS(C1,C2,BC) class C1; typedef Handle(C1) Handle_##C1;
#endif
So, now Handle_Something is a subclass of Handle(Something) and thus the dynamic_cast inside the DownCast returns null.

Note: The actual code of the handle class is a bit more complicated using some modern C++11 features and I don't know if Handle_Something::DownCast is supposed to work but in fact it doesn't.

Since the occ comment states:
For compatibility with previous versions of OCCT, define Handle_Class alias for opencascade::handle<Class>.
I would say this is a serious bug.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: ana(conda) windows packaging

Post by wmayer »

peterl94 wrote:The script makes small changes all over the place and I don't know if all Handle_ changes are necessary: "148 files changed, 2235 insertions(+), 2257 deletions(-)"
I think it's mandatory to change it only when used with DownCast. I just wonder if there is a way we can actively forbid the deprecated Handle_ notation in the future since this causes hard to find bugs.
Post Reply