Niels Horn's Blog

FreeCAD and OpenCASCADE

Building a new version of FreeCAD and OpenCASCADE is always a lot of fun…
These two projects are constantly evolving, but almost never ‘in sync’.

In December a new version of the OpenCASCADE library was released – 6.5.2. It solves several bugs and looked like a good reason to build a newer version of FreeCAD in the process. And this is where the fun begins!

Building OpenCASCADE

Building the new version of OpenCASCADE was straightforward. I just needed to update the patch to get it to build with SlackBuilds.org’s version of ftgl and test my patience – as it takes more than two hours to build on my Virtual machine. But after some fiddling around, I had a package.
Time to do some testing and trying to build FreeCAD against it!

Building FreeCAD

I decided to try the latest “stable” version of FreeCAD – 0.12.5284. The FreeCAD developers have not created any new source tarballs for a while, so I had to get the SVN revision 5284. I uploaded the tarball I created from that revision to my site so that everyone can create the same stable version.
I soon noticed that they solved all the problems I had with building against OpenCASCADE 6.5.1 some time ago, so I was able to remove that patch.
But then I ran against a new problem:

error: no matching function for call to 'BRepBuilderAPI_MakeFace::BRepBuilderAPI_MakeFace(Handle_Geom_Plane&, double, double&, double, double&)'

Reading the release notes of 6.5.2 I found out that the BRepBuilderAPI_MakeFace function now needs an extra parameter:

BRepLib_MakeFace has been modified to accept tolerance value for resolution of degenerated
edges. This tolerance parameter has no default value (to ensure that the client code takes care of
passing some meaningful value, not just Precision::Confusion), so some porting overheads
are expected.

So, it doesn’t have a default value. But what was the default before?
I read through the documentation and found that previously the default was Precision::Confusion():

A default tolerance (Precision::Confusion()) is given to the face,
this tolerance may be increased during construction of the face
using various algorithms.

I tried to add this default to the function call and … it worked!
Trying to compile the rest of FreeCAD I found several other locations in the source with the same problem, resulting in this patch:

--- FreeCAD-0.12.5284/src/Mod/Part/App/AppPartPy.cpp	2012-01-02 16:32:09.000000000 -0200
+++ FreeCAD-0.12.5284_patched/src/Mod/Part/App/AppPartPy.cpp	2012-01-02 21:36:18.000000000 -0200
@@ -492,7 +492,7 @@
             d.SetCoord(vec.x, vec.y, vec.z);
         }
         Handle_Geom_Plane aPlane = new Geom_Plane(p, d);
-        BRepBuilderAPI_MakeFace Face(aPlane, 0.0, length, 0.0, width);
+        BRepBuilderAPI_MakeFace Face(aPlane, 0.0, length, 0.0, width, Precision::Confusion());
         return new TopoShapeFacePy(new TopoShape((Face.Face())));
     }
     catch (Standard_DomainError) {
--- FreeCAD-0.12.5284/src/Mod/Part/App/GeometrySurfacePyImp.cpp	2012-01-02 16:32:09.000000000 -0200
+++ FreeCAD-0.12.5284_patched/src/Mod/Part/App/GeometrySurfacePyImp.cpp	2012-01-02 22:08:47.000000000 -0200
@@ -79,7 +79,7 @@
             s->Bounds(u1,u2,v1,v2);
             if (!PyArg_ParseTuple(args, "|dddd", &u1,&u2,&v1,&v2))
                 return 0;
-            BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2);
+            BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2, Precision::Confusion());
             TopoDS_Shape sh = mkBuilder.Shape();
             return new TopoShapeFacePy(new TopoShape(sh));
         }
--- FreeCAD-0.12.5284/src/Mod/Part/App/Geometry.cpp	2012-01-02 16:32:09.000000000 -0200
+++ FreeCAD-0.12.5284_patched/src/Mod/Part/App/Geometry.cpp	2012-01-02 22:37:08.000000000 -0200
@@ -1252,7 +1252,7 @@
     Handle_Geom_Surface s = Handle_Geom_Surface::DownCast(handle());
     Standard_Real u1,u2,v1,v2;
     s->Bounds(u1,u2,v1,v2);
-    BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2);
+    BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2, Precision::Confusion());
     return mkBuilder.Shape();
 }

--- FreeCAD-0.12.5284/src/Mod/Part/App/PrimitiveFeature.cpp	2012-01-02 16:32:09.000000000 -0200
+++ FreeCAD-0.12.5284_patched/src/Mod/Part/App/PrimitiveFeature.cpp	2012-01-02 22:40:21.000000000 -0200
@@ -191,7 +191,7 @@
     gp_Pnt pnt(0.0,0.0,0.0);
     gp_Dir dir(0.0,0.0,1.0);
     Handle_Geom_Plane aPlane = new Geom_Plane(pnt, dir);
-    BRepBuilderAPI_MakeFace mkFace(aPlane, 0.0, L, 0.0, W);
+    BRepBuilderAPI_MakeFace mkFace(aPlane, 0.0, L, 0.0, W, Precision::Confusion());

     const char *error=0;
     switch (mkFace.Error())
--- FreeCAD-0.12.5284/src/Mod/Part/App/TopoShape.cpp	2012-01-02 16:32:09.000000000 -0200
+++ FreeCAD-0.12.5284_patched/src/Mod/Part/App/TopoShape.cpp	2012-01-03 00:19:12.000000000 -0200
@@ -1338,7 +1338,7 @@
     double u1,u2,v1,v2;
     surf->Bounds(u1,u2,v1,v2);

-    BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, v1, v2);
+    BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, v1, v2, Precision::Confusion());
     return mkBuilder.Face();
 }

@@ -1391,7 +1391,7 @@

         Standard_Real u1,u2,v1,v2;
         mySurface->Bounds(u1,u2,v1,v2);
-        BRepBuilderAPI_MakeFace mkBuilder(mySurface, u1, u2, v1, v2);
+        BRepBuilderAPI_MakeFace mkBuilder(mySurface, u1, u2, v1, v2, Precision::Confusion());
         return mkBuilder.Shape();
     }

@@ -1443,7 +1443,7 @@
     mkSweep.Perform(tol, Standard_False, GeomAbs_C1, BSplCLib::MaxDegree(), 1000);

     const Handle_Geom_Surface& surf = mkSweep.Surface();
-    BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, vmin, vmax);
+    BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, vmin, vmax, Precision::Confusion());
     return mkBuilder.Face();
 }

--- FreeCAD-0.12.5284/src/Mod/Part/App/TopoShapeFacePyImp.cpp	2012-01-02 16:32:09.000000000 -0200
+++ FreeCAD-0.12.5284_patched/src/Mod/Part/App/TopoShapeFacePyImp.cpp	2012-01-03 00:24:40.000000000 -0200
@@ -135,7 +135,7 @@
                 return -1;
             }

-            BRepBuilderAPI_MakeFace mkFace(S);
+            BRepBuilderAPI_MakeFace mkFace(S, Precision::Confusion());
             if (bound) {
                 Py::List list(bound);
                 for (Py::List::iterator it = list.begin(); it != list.end(); ++it) {

With this patch I was able to build FreeCAD successfully on Slackware and now I’m happy playing around with it, discovering the new features

Where to get it

I submitted the new scripts to SlackBuilds.org, where they are waiting in the pending queue to be approved.
In the mean time, pre-built packages for Slackware (both 32- and 64-bits) can be downloaded from my site.

Last month version 7.20.4 of BRLCAD was released with lots of improvements. You can check the log here for details.

This weekend I finally had some time to update my SlackBuild script and submit the update to SlackBuilds.org. While the script is waiting for approval, you can download pre-built packages from my site.

How this all started

About a year and a half ago I wrote a patch to get mysqlcc (”MySQL Control Center”) to build with newer versions of mysql and the gcc compiler. This post can be found here and I’ve received several replies on this blog and through e-mail since.

After mysql 5.5 was released, I received a few questions about getting mysqlcc to work with this new version of the still very popular database.
Personally I have not yet decided if I should stick to mysql – now a commercial product from Oracle – or switch to its really free sister (*) MariaDB or even PostgreSQL.

At first I thought “Are people still using this?” and, together with a complete lack of time, did not do too much with this all.
But the, curiosity caught up with me and I started to do some investigation…

The error messages

Trying to build mysqlcc against mysql 5.5 gives these errors:

main.cpp:(.text+0xae): undefined reference to `my_print_help'
main.cpp:(.text+0xcd): undefined reference to `my_print_variables'
tmp/main.o: In function `main':
main.cpp:(.text+0x1dd): undefined reference to `handle_options'

After some quick “googling” I found out that since mysql 5.5 the libmysqlclient library (libmysqlclient.so.18.0.0) does not export several functions that were exported with the previous versions. A discussion about this can be found here. Basically, they were unofficial and now are hidden functions. They can be exported by altering a CMakeLists.txt file and rebuilding mysql 5.5, but this is not always an option. I did try it and in the end I got it to work, but I was convinced that it was not the right way to fix this. After all, I don’t think Oracle would listen to me and change their library

The patch

OK, so I had to patch mysqlcc.
These now “hidden” functions all were related to passing command-line parameters to mysql, like the location of the socket, etc. Most users would never use this (I never have) and simply start mysqlcc from a menu, not from a prompt.
I simply removed all these calls in mysqlcc, resulting in this patch:

--- mysqlcc-1.0.1-src/src/main.cpp      2011-07-08 07:40:01.000000000 -0300
+++ mysqlcc-1.0.1-src_patched/src/main.cpp      2011-12-19 09:31:11.000000000 -0200
@@ -176,13 +176,7 @@
   print_version();
   printf("usage: %s [options] [database]\n\n", progname);
   printf("Options:\n");
-  my_print_help(my_long_options);

-#ifndef WIN32  //Win32 doesn't support load_defaults yet.
-  print_defaults("my", load_default_groups);
-#endif
-
-  my_print_variables(my_long_options);
   exit(-1);
 }

@@ -192,14 +186,8 @@
   int pid = 0;
   int t = 0;
   int ret = -1;
-  char **save_argv;
-  load_defaults("my",load_default_groups,&argc,&argv);
-  save_argv = argv;
   progname= argv[0];
-  if (handle_options(&argc, &argv, my_long_options, get_one_option))
-    exit(-1);
   if (!argv[0] || !argv[1] || (pid = atoi(argv[0])) <= 0 || (t= atoi(argv[1])) <= 0)
     ret = mysqlcc_main(argc, argv);
-  free_defaults(save_argv);
   return ret;
 }

The patch can also be downloaded here.

It works

After patching and building, I could use mysqlcc on my mysql 5.5 server:

Just remember that it will not handle any command line option after this patch, not even "-v" to see the version...

(*) My and Maria are both daughters of Ulf Michael Widenius, the "father" of both databases.

Today LibreOffice 3.4.3 was released. Updating my SlackBuild script is now extremely simple, so the newest packages can already be downloaded from my site while the SlackBuild is waiting in the pending queue.

I also built the usual language packs and they are being uploaded as well and should be available later tonight.

A few days ago ntop 4.1.0 was released so it was time to update my SlackBuild script again

This release is focused on stability and speed, solving some of the problems the 4.0.x series had.
Some “older” protocols have been removed (but may come back in rewritten form in future versions), making space for newer “protocols” like twitter or facebook.

I already submitted the new SlackBuild script and the packages (including one for ARMedslack) are being uploaded to my site.
And, while you’re updating ntop, check if your GeoIP and graphviz packages are up-to-date, as new versions have been released for these dependencies as well (and are available also on my site).

Updating FreeCAD was long over due – the last package I built was for 0.9.2646 and they’re currently in the 0.11 series. But it is not a simple package to build – it requires some time and patience to get it all right…

Dependencies

FreeCAD is based on OpenCASCADE, which has been updated a few times since the last time I built a package for it. FreeCAD also depends on a few other libraries: Pivy, SoQt, Coin and xerxes-c. Of these, Pivy also needed an update, so I started with this one.

Updating Pivy
This update was simple. I just got the latest “tag” from the Mercurial repository (there are no tarballs for Pivy) and cleaned up the SlackBuild a bit. Pivy needs Coin and SoQt to build. It takes some time to build, but all went fine.

The updated script was submitted and the new packages were uploaded. I also put a tarball with the snapshot from the Mercurial repository on my site, to make it easier to build and to guarantee that the correct version is used.

OpenCASCADE

OpenCASCADE has never been a simple package to compile. It is huge (sources are > 200MB) and takes some time to build (two hours on my desktop). And worst: it never builds the first time without errors

First it gave some of those dreaded “not declared in this scope” errors.
These errors are caused by stricter checking in the newer gcc versions (actually since 4.3, and Slackware 13.37 is already on 4.5). As usual, they were easily fixed with a small patch putting an extra “include” in the source code.
This is the patch:

--- OpenCASCADE-6.5.1/ros/src/OSD/OSD_MAllocHook.cxx    2011-05-19 08:24:52.000000000 -0300
+++ OpenCASCADE-6.5.1_patched/ros/src/OSD/OSD_MAllocHook.cxx   2011-08-10 12:39:39.000000000 -0300
@@ -10,6 +10,7 @@
 #define __STDC_LIMIT_MACROS
 #endif
 #include <stdint.h>
+#include <stdlib.h>
 #endif

 #include <set>

But that was not all. I soon discovered (after compilation complaining that FTFont.h was missing) that OpenCASCADE now depends on ftgl. Well, that should have been simple to resolve, as there is a ftgl SlackBuild on SlackBuilds.org.
OK, not that simple – it did not work.
Researching a bit on the internet, I found that they used an older version of ftgl, but the guys from OpenSUSE had already written a patch to solve this and can be found here.

After this, I was able to successfully build OpenCASCADE 6.5.1
I just added one thing to the SlackBuild – an option to include all the documentation. Most of it is available online and only interesting if your writing your own programs based on OpenCASCADE, not for users of FreeCAD for example. And we’re talking about 600MB of documentation…

So, the new script was also submitted and the pre-built packages uploaded.

Finally, FreeCAD

OK, so now I could start building FreeCAD, having all the dependencies ready on my machine!

The old problem with the boost libraries continued in the 0.11.3729 sources, to my surprise, but I substituted the original patch with a sed command, to make it easier to maintain:

sed -i "/-lboost/s/-mt\"/\"/g" configure

And two new problems appeared: the name of a function in OpenCASCADE had changed in 6.5.0 and a code for an error condition (according to OpenCASCADE never used) was removed.
I managed to write a small patch to get FreeCAD to compile with OpenCASCADE 6.5.0:

--- FreeCAD-0.11.3729/src/3rdParty/salomesmesh/src/SMESH/SMESH_MeshEditor.cpp   2010-10-17 05:59:46.000000000 -0200
+++ FreeCAD-0.11.3729_patched/src/3rdParty/salomesmesh/src/SMESH/SMESH_MeshEditor.cpp   2011-08-10 20:04:59.000000000 -0300
@@ -2205,8 +2205,8 @@
   if ( projector.IsDone() ) {
     double u, v, minVal = DBL_MAX;
     for ( int i = projector.NbExt(); i > 0; i-- )
-      if ( projector.Value( i ) < minVal ) {
-        minVal = projector.Value( i );
+      if ( projector.SquareDistance( i ) < minVal ) {
+        minVal = projector.SquareDistance( i );
         projector.Point( i ).Parameter( u, v );
       }
     result.SetCoord( u, v );
--- FreeCAD-0.11.3729/src/3rdParty/salomesmesh/src/SMESH/SMESH_Pattern.cpp      2010-10-17 05:59:46.000000000 -0200
+++ FreeCAD-0.11.3729_patched/src/3rdParty/salomesmesh/src/SMESH/SMESH_Pattern.cpp      2011-08-10 20:06:21.000000000 -0300
@@ -436,8 +436,8 @@
   }
   double u, v, minVal = DBL_MAX;
   for ( int i = theProjectorPS.NbExt(); i > 0; i-- )
-    if ( theProjectorPS.Value( i ) < minVal ) {
-      minVal = theProjectorPS.Value( i );
+    if ( theProjectorPS.SquareDistance( i ) < minVal ) {
+      minVal = theProjectorPS.SquareDistance( i );
       theProjectorPS.Point( i ).Parameter( u, v );
     }
   return gp_XY( u, v );
--- FreeCAD-0.11.3729/src/Mod/Part/App/PrimitiveFeature.cpp     2010-08-27 11:22:14.000000000 -0300
+++ FreeCAD-0.11.3729_patched/src/Mod/Part/App/PrimitiveFeature.cpp     2011-08-10 20:41:35.000000000 -0300
@@ -141,9 +141,6 @@
     case BRepBuilderAPI_ParametersOutOfRange:
         error = "parameters out of range";
         break;
-    case BRepBuilderAPI_SurfaceNotC2:
-        error = "surface not C2";
-        break;
     default:
         error = "unknown error";
         break;
--- FreeCAD-0.11.3729/src/Mod/Part/App/TopoShape.cpp    2010-11-14 06:53:08.000000000 -0200
+++ FreeCAD-0.11.3729_patched/src/Mod/Part/App/TopoShape.cpp    2011-08-10 20:43:03.000000000 -0300
@@ -139,8 +139,6 @@
         return "Curve projection failed";
     case BRepBuilderAPI_ParametersOutOfRange:
         return "Parameters out of range";
-    case BRepBuilderAPI_SurfaceNotC2:
-        return "Surface not C2-continous";
     default:
         return "Unknown creation error";
     }

With this, I successfully build FreeCAD 0.11.3729 on Slackware!

Extra package

OpenCASCADE now has an optional dependency called gl2ps so I built a package for this as well.
Doing so, I needed to write a small patch to put the libraries in the correct /usr/lib64 directory on Slackware64:

--- gl2ps-1.3.5-source/CMakeLists.txt   2009-10-16 16:14:07.000000000 -0300
+++ gl2ps-1.3.5-source_patched/CMakeLists.txt   2011-08-10 17:24:43.000000000 -0300
@@ -113,7 +113,7 @@
     set_target_properties(shared PROPERTIES COMPILE_FLAGS "-DGL2PSDLL -DGL2PSDLL_EXPORTS")
   endif(MSVC)

-  install(TARGETS lib shared DESTINATION lib)
+  install(TARGETS lib shared DESTINATION lib${LIB_SUFFIX})
 endif(OPENGL_FOUND)

 if(WIN32)

Where to get it

All scripts have been submitted to SlackBuilds.org.
If you don’t feel like spending about three hours building packages, you can get them ready-to-install from my site.

Freeciv 2.2.7 was released recently and I updated my SlackBuild script for it.

The Freeciv 2.2.x series of releases are mainly bug fixes, while the development of new features continues in the upcoming 2.3.x branch – which is still in beta.

While the script is pending approval on SlackBuilds.org, you can get pre-built packages from my site.

With all the updates to packages, I forgot completely to mention QComicBook. I updated my SlackBuild script for version 0.8.1, which now also supports pdf files.

As always, the pre-built packages can be downloaded from my site.

Today (or yesterday, depending on your timezone) LibreOffice 3.4.2 was released.

Officially stable

This is the first release from the 3.4 series that is officially declared stable enough for enterprise use. So now we can all retire our 3.3.x installations and start using 3.4.2.
I admit that I’ve been using the 3.4 versions since 3.4.0, but I’m not an “enterprise” user, just a private person that uses lots of spreadsheets and writes a few documents.

Previous script works

This release was a nice test for the changes I introduced with the 3.4.1 update…
I tried building the 3.4.2 version with “VERSION=3.4.2 ./libreoffice.SlackBuild” and it worked flawlessly
So if you downloaded the 3.4.1 version from SlackBuilds.org’s git repo or from my site, you do not have to download the newer version – nothing has changed except the version number and the md5 checksums.

New script and packages

While we’re waiting for the next public update on SlackBuilds.org, you can get the new script or the complete packages from my site.
Well, actually, they’re still being uploaded as I write this, but they should be there in a while

Another simple update… Or not?

This weekend I finally updated my LG X130 netbook to Slackware 13.37. This is one of my “stable” machines that I use all the time for day-to-day tasks, so I do not run -current on it, as I depend on it too much. Slackware-current is very interesting for research and testing all the new stuff, but it can break when you least expect it. And then you need a “stable” installation to at least access the internet, pay the bills, read e-mail, etc. So I left this netbook as one of the last machines to update to Slackware 13.37.

And it went quite smoothly. Except for one thing: the wireless adapter was not working…

Old problem returning?

I remembered that when I first installed Slackware on this netbook about a year ago, I also had a problem with this rt3090 card. The kernel confused it with the rt2800 and tried to load the rt2800pci module – which did not work with this adapter.
At the time, I found a simple solution by ‘Googling”: putting the rt2800pci module on the blacklist by creating a simple text file in /etc/modprobe.d/ with a single line:

blacklist rt2800pci

So I checked if that file was still there, and it was…
I did a “lsmod | grep rt2” and the result was:

rt2860sta             483303  1
crc_ccitt               1087  1 rt2860sta

So the correct module was loaded!

More investigation was needed

“ifconfig” did not show the wlan0 interface, but “ifconfig -a” did.
I tried “ifconfig wlan0 up” but it returned with:

SIOCSIFFLAGS: Operation not permitted

So what do we do when a kernel module has problems? Check the dmesg log…
I did a “dmesg | grep -i rt” and found this interesting line:

rt2860 0000:02:00.0: firmware file rt3090.bin request failed (-2)

So, the rt2860 module is looking for the rt3090.bin firmware and not finding it!

But isn’t the rt2860 driver used for the rt3090? I remembered reading (don’t know where, probably when I first installed Slackware 13.1 on this netbook) that the rt3090 adapter was handled 100% by the rt2860 driver.
I decided to check the /lib/firmware directory, where all the firmware files are installed in Slackware. There were several rt2xxx.bin files, but no rt3090.bin.

This is where I decided to get bold

I thought: It’s not working anyway, so what can I loose?
And I created a symlink rt3090.bin to rt2860.bin They are the same in the kernel anyway, right?
I rebooted, and… It worked!

My wireless adapter was working again and my netbook was fully operational as before the update.

But was this really the correct solution?

I decided to go straight to the source and browse around on kernel.org. And in their git repository I found this commit:

rt2860sta: Use latest firmware for RT3090

author Ben Hutchings
Sat, 30 Apr 2011 18:31:32 +0000 (19:31 +0100)
committer Ben Hutchings
Tue, 17 May 2011 04:22:12 +0000 (05:22 +0100)

Ralink’s original drivers for RT2800P/RT2800E-family chips used
multiple different versions of the firmware for different chips. The
rt2860sta driver in staging was briefly converted to load different
files for different chips. However, the current rt2860.bin is
supposed to work on all of them, so replace rt3090.bin with a symlink.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Well, well! So the official solution was to create a symlink as well!
I checked the tree in their git repository and there you can see they have the symlink “rt3090.bin” pointing to the rt2860.bin file, just as I did.
I also noticed a second symlink: rt3070.bin is pointing to rt2870.bin.

Report it back to “The Man”

Now that I was reassured that my solution was the correct one, I sent an e-mail to Pat Volkerding about my findings.
It would be nice to see the rt2860-firmware-26-fw-1 package create the symlink on installation, to prevent some headaches around the world