Mac pre-release download way behind Windows version

[blacey]

Good find, Ian! I totally was not thinking of that. I simply excluded the framework from being brought into the bundle and it seemed to work fine with the spacenav I use at work. The 3dconnexion framework is weak linked, so I think that means it won't cause problems for people who don't have the driver installed.

Sweet! I will add this patch to the next build!

[blacey]

Got the 3Dconnexion thing mostly figured out, will need to do some research tomorrow on how best to fix it. The issue is that MakeMacBundleRelocatable.py is setting the wrong rpath to look for the 3Dconnexion Framework in the binaries that make up FreeCAD. -Ian-

Good find, Ian!

Peter and Ian, a new Mac OS X build is available that includes Peterl94's patch for 3DConnexion and sync'd with master through fa42bc4.

Code: Select all

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6305 (Git)
Build type: Release
Branch: tag: 0.16_pre-osx
Hash: 2efb7a28f0c48891efe9b76dc32e9defd4309057
Python version: 2.7.11
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.8.0.oce-0.17

Please confirm the 3DConnexion support when you have a chance, weather permitting If you happen to read this before Chris has a chance to copy the build to the main FreeCAD repo, you can grab it here.

[ian.rees]

Please confirm the 3DConnexion support when you have a chance, weather permitting

Yes, the 3D mouse does appear to work in that build, though there are some other problems with the build that I haven't investigated (creating the default cube in Part Design seems to just make vertex or cube that's very far away?). One thing at a time .

I want to make some other changes in the application bundling/3D mouse area while I'm working on this, let's not pull in Peter's changeset yet.

[Edit: Pull request issued - https://github.com/FreeCAD/FreeCAD/pull/79 ]

Peter - While reading up on dynamic linking on Mac, I ran across this: https://github.com/auriamg/macdylibbundler . Seems like it might be worth a closer look? -Ian-

[blacey]

Please confirm the 3DConnexion support when you have a chance, weather permitting

Yes, the 3D mouse does appear to work in that build, though there are some other problems with the build that I haven't investigated (creating the default cube in Part Design seems to just make vertex or cube that's very far away?). One thing at a time .

I want to make some other changes in the application bundling/3D mouse area while I'm working on this, let's not pull in Peter's changeset yet.

Peter - While reading up on dynamic linking on Mac, I ran across this: https://github.com/auriamg/macdylibbundler . Seems like it might be worth a closer look? -Ian-

Hey Ian,

• 1) I had folded Peter's patch into the last build you tested. Easy enough to revert and fold in your preferred changes though...
  2) I am not experiencing issues with the current build. All unit tests pass and no problem creating cubes in either the Part Design or Part workbench on a Mac running 10.11 that does not have Homebrew installed. Here is a quick video of the current build on a Mac running 10.11 without Homebrew installed - https://www.youtube.com/watch?v=G6BW-vNLDnk

  

  Screen Shot 2016-01-22 at 9.55.32 PM.jpg (34.04 KiB) Viewed 2391 times

What is the config where you are experiencing problems (e.g. OS)?

[ian.rees]

Hmm, I tried the FreeCAD_osx-6270-f480791.dmg and got the same problem there. An easier to describe symptom is that if I try to make a new sketch in Part Design, I get a segfault. Specs of my machine below, though it's been thrashed about quite a bit, so it seems likely that it's got something else weird going on. Wouldn't worry about it unless someone else reports a similar problem.

I tested the same f480791 build as above on a fresh MacOS 10.10 VM, and Part Design seems to work fine there.

This reminds me - we should probably either set the environment variable MACOSX_DEPLOYMENT_TARGET or give clang -mmacosx-version-min=10.something . Not sure what the minimum version we want to support is, but as an example could do something like below. -Ian-

Code: Select all

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1b96b13..2e02bf9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -836,6 +836,9 @@ ELSE(CMAKE_SIZEOF_VOID_P EQUAL 8)
 ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
 
 
+IF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+       set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mmacosx-version-min=10.9")
+ENDIF(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
 
 IF(MSVC)
        # set default compiler settings

MacOS 10.10.5
Xcode 7.2
Up-to-date-ish macports install
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

Info below is from a fresh local build:
OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6265 +3 (Git)
Build type: Debug
Branch: 20160123-3dconnexion-mac-bundle
Hash: b5688aade5daaccbbaf1ed7e067ff858f9f4ab17
Python version: 2.7.11
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.8.0.oce-0.17

[peterl94]

Peter - While reading up on dynamic linking on Mac, I ran across this: https://github.com/auriamg/macdylibbundler . Seems like it might be worth a closer look?

It seems to have the same problem as cmake (although, cmake might have changed this), and that is using @executable_path for the install names. The reason I wrote that script to use @rpath was because people were unable to import the freecad libraries in Python (because @executable_path would resolve to the python executable). Also, IIRC, the roadblock with cmake's "fix up bundle" script was adding multiple rapths, one relative to the executable and one relative the library.


Ian, I have had some crashes before with multiple versions of some libs trying to be loaded. You might want to rule that out first. I use export DYLD_PRINT_LIBRARIES=1 to see everything that is being loaded.

Peter

[ian.rees]

It seems to have the same problem as cmake (although, cmake might have changed this), and that is using @executable_path for the install names. The reason I wrote that script to use @rpath was because people were unable to import the freecad libraries in Python (because @executable_path would resolve to the python executable). Also, IIRC, the roadblock with cmake's "fix up bundle" script was adding multiple rapths, one relative to the executable and one relative the library.

Ahh, that makes sense. Perhaps we should put a comment block at the top of the script to explain it's reason for existence? (if we do this, should also clean up that dumb if-continue train I made between lines 251 and 265). By the way, I really appreciate all the guidance on the MacOS bundling/linking stuff!

blacey, the crash seems to be in OCC - I think this might be the one that's fixed in OCC 7? I haven't looked in to that issue in much detail honestly, am just waiting for OCC 7 to be officially released sometime in the next few days :

Code: Select all

* thread #1: tid = 0x1f2c9, 0x000000011d23497d libTKBRep.10.dylib`TopExp_Explorer::Init(TopoDS_Shape const&, TopAbs_ShapeEnum, TopAbs_ShapeEnum) + 165, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000011d23497d libTKBRep.10.dylib`TopExp_Explorer::Init(TopoDS_Shape const&, TopAbs_ShapeEnum, TopAbs_ShapeEnum) + 165
libTKBRep.10.dylib`TopExp_Explorer::Init:
->  0x11d23497d <+165>: callq  *0x28(%rax)
    0x11d234980 <+168>: cmpl   0x2c(%r13), %eax
    0x11d234984 <+172>: jle    0x11d23499a               ; <+194>
    0x11d234986 <+174>: movb   $0x0, 0x28(%r13)
(lldb) bt
* thread #1: tid = 0x1f2c9, 0x000000011d23497d libTKBRep.10.dylib`TopExp_Explorer::Init(TopoDS_Shape const&, TopAbs_ShapeEnum, TopAbs_ShapeEnum) + 165, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000011d23497d libTKBRep.10.dylib`TopExp_Explorer::Init(TopoDS_Shape const&, TopAbs_ShapeEnum, TopAbs_ShapeEnum) + 165
    frame #1: 0x000000011cb97cf1 libTKTopAlgo.10.dylib`BRepBndLib::Add(TopoDS_Shape const&, Bnd_Box&, bool) + 137
    frame #2: 0x0000000119bbf5dd PartGui.so`PartGui::ViewProviderPartExt::updateVisual(TopoDS_Shape const&) + 365

[blacey]

We just released a new build from the Travis CI server that incorporates the following changes:

• Ian and Peter's changes to provide support for the 3DConnexion mice
• A patch from Peter that properly sets the python module dependencies in accordance with home-brew recommendations. This improves the integrity of the application bundle and will make it easier for others to compile their own builds using Homebrew (instructions will be revised once we deploy the os x CI builds)
• Merge with FreeCAD master up through commit cbdd18c.

This as our best build to date so we recommend that all Mac Users upgrade to this build, provided you are running OS X 10.9 or later. You can download build FreeCAD_0.16-6321.cbdd18c-OSX-x86_64.dmg from the FreeCAD Github Releases area.

The next step is to upgrade to matplotlib 1.5.x to simply the build steps (I'll spare you the details) and incorporate the OS X build steps into a unified Linux and OS X Travis CI build configuration in the main FreeCAD repo that will automatically publish OS X builds. We still have some details to work through but once we achieve that milestone, the OS X builds will maintain lock-step with the Linux builds. In the interim, Mac enthusiasts can monitor this thread to know when a new build is available.

Thanks to @peterl94 & @Ian.reese for the OS X prior art, the aforementioned patches and continued collaboration, and to @sgrogen for keen insight and copying each build to the main FreeCAD releases area.

Best,
Bruce

Code: Select all

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6321 (Git)
Build type: Release
Branch: tag: 0.16_pre-osx
Hash: da4e6ccd624dbfcf8dc49282ab67951f989ba63c
Python version: 2.7.11
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.8.0.oce-0.17

[brusk]

Am traveling at the moment so can't test but awesome work guys !

[bronson]

I have a SpaceMouse Wireless but I can't seem to get it to work in the latest FreeCAD 0.16... It works in other apps.

When I go to Tools -> Customize -> Spaceball Motion, it just says "No Spaceball Present".

Anyone know what else I can try? Thanks!

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.4945 (Git)
Build type: Release
Branch: master
Hash: 6cd9220079a1efb1a2f33842fa614521a31bf0d5
Python version: 2.7.9
Qt version: 4.8.6
Coin version: 4.0.0a