PCL - Point Cloud Library

PCL build requires all the dependencies to be of the same architecture. By default they are 64 bit. The universal binaries should contain both 32 and 64 bit libraries. So try them and let us all know what happens.


I just ran the installer and found that the so–called pcl universal binaries are all 64 bit ;-(


I just ran the installer and found that the so–called pcl universal binaries are all 64 bit ;-(

Or isn’t it so that the libraries are universal but since your system is 64 bits, then it install only the 64 bit version of it?

I made another attempt yesterday to compile it for 32 bit. I had trouble compiling VTK correctly and ended up installing it though mac port (with options +x11 +universal). I thought that if this is the only library that is not 32 bit only but is universal, then it should be fine.
…well apparently no as PCL lib compilation after that failed, for some reason I don’t remember exactly.

Another option I was thinking about: if I remember correctly when I tried ofxPCL, the PCL library (or the scrapped version of it inside the addon) is being compiled by xcode.
So why don’t we get all source code for boost, eigen, flann, qhull and PCL in our OF project in xcode. Then add the header path for each library and build it.
That way xcode will compile everything in 32 bit and so compatible with OF architecture.
Is this possible or am I playing stupid? :smiley: (it sounds too easy to me…or I don’t see some hidden trick)


The OS bitness does not matter: universal binaries should contain both 32 bit and 64 bit (and who knows what else, things like ppc arch): the build schema picks the one, which it is interested in based on an architecture it is being built for.

Building from source, including the dependencies, is a righteous way to go about it of course. However, the dependencies have their own intricate build schemas. VTK is using cmake, boost is using b2 etc. Once you get those right, there is no point to import these dependencies into Xcode, all you have to do is to just build them using make.



After several attempts, I think I finally succeeded to build PCL for 32 bit architecture. At least when I import the libraries in an OF project, Xcode doesn’t complain about it not matching the project architecture.

I still need to test an example but it was quite late yesterday evening so I leave this for later today :).

What I did is:

  • Installing all dependencies using Mac port, with +universal command. At least it is a no brainer, don’t have to do anything.
    For VTK5, I used: sudo port install vtk5 +qt4_mac +universal. (before was using +x11 instead but was bringing some errors if I remember correctly and I found somewhere on the internet this different version so I gave it a try).

Once all dependencies are installed, I used PCL Superbuild: http://www.pcl-developers.org/A-SuperBuild-for-PCL-td5706899.html
I modified SuperBuild.cmake file to include the dependencies libraries using set(BOOST_ROOT “/opt/local/lib or something like that”) command. Also I fixed a little typo about the libusb path name: renamed USB_10_INCLULDE_DIR into USB_10_INCLUDE_DIR.

Then at the bottom of the file, in the PCL compilation options, before INSTALL_COMMAND “” I added:

Finally run cmake and make and it compiled fine.
(Though at first for some reason instead of using Libusb from /opt/local/ it was using the version I had in /usr/local/. As I was too lazy to investigate this, I just removed the files for libusb in /usr/local and it fixed the problem :D).

I will try very soon with an example using OF in Xcode but at least I have now all libraries compiled and compatible for 32 bit architecture! Yay!

I keep you posted, cheers!

I was trying yesterday to include PCL and dependencies into xCode and (of course) had some troubles.

I am having same trouble jvcleave had some time ago: http://www.pcl-developers.org/tm-has-not-been-declared-td4900815.html

Does anyone knows how could this kind of problem be solved in xcode 4?

the first time I solved it was just renaming the file and fixing the errors - it wasn’t too bad

Thanks jvcleave…and I believe you are talking about the time.h in PCL folder, right?

Also looking over ze internet, I might have found a solution: http://www.crickettechnology.com/blog/?p=671 (number 1.)
I found a few forums advising the same work-around. I will give it a try this evening and see what happen :slight_smile:

yeah pcl/common/time.h

I think I renamed it pcl_time.h

I didn’t have to rename the time.h file actually: adding a user-defined setting in xcode with USE_HEADERMAP with value to NO do the trick as well.

After that i add errors with boost macros, like BOOST_STATIC_CONSTANT in has_binary_operator.hpp file. I found this solution here: http://stackoverflow.com/questions/8173620/c-boost-1-48-type-traits-and-cocoa-inclusion-weirdness
So I checked which file of PCL was calling “boost/type_traits.hpp” and I added :
#ifdef check
#undef check
#include <boost/type_traits.hpp>

It is now compiling successfully in xcode and I am able to try some examples from the website.

Also it seems that openni grabber do not work. Now I am putting this PCL version in ofxPCL and let’s see what will happen :slight_smile:

yeah - in a later attempt I got around it as well but forgot what I did so glad you figured it out.

I continued yesterday with merging it with ofxPCL and got some new errors while including ofxPCL.h, related to some pcl includes.

Basically on OSX there is a conflict with cocoa “nil” and “NIL”: for example in the file cons_fwd.hpp.
It seems that the solution for that is to rename them by “nil_” (for example) or “NIL_”. Annoying thing is that a huge amount of file in boost use this term. I didn’t rename them all, only the ones that were troubling the compilation :slight_smile:

So after that, ofxPCL compile fine. Only trouble is ofxPCL function movingLeastSquares which bring errors still.

i think it is just some new syntax changes - these are old but may be worth a shot

You don’t have to rename the nils if you redefine them: https://svn.boost.org/trac/boost/ticket/5010 .


Did you actually verify that the libs you are getting are i386 arch? What does the “file PATH_TO_LIB” reports?

I have tried superbuild (using “cmake -DCMAKE_OSX_ARCHITECTURES=i386 -DCMAKE_CXX_FLAGS_INIT=”-Wall -std=c++0x -stdlib=libc++" …/PCLSuperBuild"), and also specifying arch and libc and other flags in the SuperBuild.cmake, it seems to ignore them, at least “file” command returns “Mach-O 64-bit dynamically linked shared library x86_64” for the all dependencies and pcl libs themselves.




Did you actually verify that the libs you are getting are i386 arch? What does the “file PATH_TO_LIB” reports?

Actually no I didn’t verify this. I just checked if Xcode was complaining about those libraries not matching architecture i386. It did not complained so I assumed it was fine.

I have tried superbuild (using “cmake -DCMAKE_OSX_ARCHITECTURES=i386 -DCMAKE_CXX_FLAGS_INIT=”-Wall -std=c++0x -stdlib=libc++" …/PCLSuperBuild")

I remember that i first tried this as well and as you said: for some reason it ignores the flags. So I added -DCMAKE_OSX_ARCHITECTURES=i386 in Superbuild.cmake, at the very end in “CMAKE_ARGS” parts and then it worked fine.

I will try to remember to check architecture of the PCL libraries this evening and let you know.

I checked with the PCL libraries I compiled, using “file” command:

libpcl_common.1.7.0.dylib: Mach-O dynamically linked shared library i386


I struggled with the same error regarding the time.h linking problem, and I solved it as MEACH has suggested:

  1. add a custom build setting of USE_HEADERMAP = NO for the target. Here is how:
    1.1. Open the target’s info panel on the “Build” pane.
    1.2. Pull down the action pop-up menu at the bottom left of the window, select “Add User-Defined Setting”.
    1.3. In the newly added line, set the first column (“Setting”) to USE_HEADERMAP, and the second column (“Value”) to NO.

  2. add the correct include the following paths to the target (target Build settings “Header Search Paths”). In my example that would be:
    2.1. …/…/…/addons/ofxPCL/src
    2.2. …/…/…/addons/ofxPCL/libs/pcl/include/pcl-1.6
    2.3. …/…/…/addons/ofxPCL/libs/pcl/include/eigen3
    2.4. …/…/…/addons/ofxPCL/libs/pcl/include

hope this helps




I have manually copied pcl-1.6 and eigen3 to OF/addons/ofxPCL/libs/pcl/
but it seems like the path of Eigen is not correctly located.
What have I missed?

Also, copyfiles.py didn’t work for me :frowning: