Compiling libarea

[Daryl Stultz]

Hello,

I'd like to use libarea in my own project. I understand libarea is a Python module that needs to be compiled and installed. I'm a bit unfamiliar with the process and I'm hoping to get some help.

I have a MacBook Pro with 10.8.2. I have boost installed via homebrew. Running make (the second time) produces this:

raptor:libarea daryl$ make 

g++ -shared -rdynamic `python-config --ldflags` -lboost_python -fPIC -Wl,-soname,libarea.so.0 Arc.o Area.o AreaBoolean.o AreaDxf.o AreaOrderer.o AreaPocket.o booleng.o Circle.o Construction.o Curve.o dxf.o Finite.o graph.o graphlst.o instonly.o kurve.o line.o link.o lpoint.o Matrix.o node.o offset.o PythonStuff.o record.o scanbeam.o -o .libs/area.so -lstdc++ `python-config --libs`

ld: library not found for -lboost_python

collect2: ld returned 1 exit status

make: *** [.libs/area.so] Error 1

This appears to be "progress" as compared to the output I got before installing boost (and bjam). Mac OSX comes with python 2.7.2. Is there something I need to do to get the build process to find boost? (It is installed to /usr/local/lib).

Any help appreciated.

Thanks

/Daryl

P.S. what is the difference between libarea and opencamlib?

[dan falck]

Hi Daryl,
It seems like I've run across this before with boost_python. You might have to fiddle with the configuration before building (or rebuilding) boost to make sure that you get boost_python included. It's been a long time since I built it on a mac, but it seemed like that was a problem that I was having too.

Dan Falck

[Anders Wallin]

> I'd like to use libarea in my own project. I understand libarea is a Python
> module that needs to be compiled and installed. I'm a bit unfamiliar with
> the process and I'm hoping to get some help.
>
> I have a MacBook Pro with 10.8.2. I have boost installed via homebrew.
> Running make (the second time) produces this:

On unix-like systems, (ubuntu, mac osx), cmake is a vast improvement
over raw makefiles, or even hand-written long command-lines (not sure
what you are using below).
The libarea repository was/is quite "messy" and there are a few forks
which have aimed to clean things up a bit:
https://github.com/aewallin/libarea
or
https://github.com/danielfalck/libarea-clipper

if you have missing libraries (boost python) then cmake should
complain already at the cmake stage.
The way to build with cmake is usually
$ mkdir build (assuming we are in the project directory)
$ cd build
$ cmake .. (assuming theres a CMakeLists.txt file in the project dir)
$ make
$ sudo make install

>
> P.S. what is the difference between libarea and opencamlib?

libarea is for 2D pocketing and profiling. it is built on top of a
polygon library (clipper) that supports boolean operations.
opencamlib is for 3D machining, it takes STL-surfaces as input.
They have different licenses.

Anders

[Daryl Stultz]

On Mon, Oct 15, 2012 at 12:59 AM, Anders Wallin <anders.e...@gmail.com> wrote:

> I'd like to use libarea in my own project. I understand libarea is a Python
> module that needs to be compiled and installed. I'm a bit unfamiliar with
> the process and I'm hoping to get some help.

Hey, great to hear from both Dan Falck and Anders, you two plus Dan Heeks all have projects I'm interested in... Dan (Falck), I left a couple comments on your blog about FreeCAD, more on that later.

I cloned Anders's git repo and after editing CMakeLists.txt to change a switch on sed for the Mac, I got through the cmake stage and it found boost:

...

-- Boost version: 1.51.0

-- Found the following Boost libraries:

--   python

-- found Boost: 1_51

-- boost-incude dirs are: /usr/local/include

-- boost-python lib is: /usr/local/lib/libboost_python-mt.dylib

-- boost_LIBRARY_DIRS is: /usr/local/lib

-- Boost_LIBRARIES is: /usr/local/lib/libboost_python-mt.dylib

-- Python libraries will be installed to: /Library/Python/2.7/site-packages

...

make produces a number of warnings regarding unary operator:

 warning: use of unary operator that may be intended as compound assignment (-=)

then symbol errors:

Undefined symbols for architecture x86_64:

  "_PyBool_FromLong", referenced from:

      boost::python::objects::caller_py_function_impl<boost::python::detail::caller<bool (*)(), boost::python::default_call_policies, boost::mpl::vector1<bool> > >::operator()(_object*, _object*) in PythonStuff.o

[snip]

  boost::python::objects::caller_py_function_impl<boost::python::detail::caller<void (CArea::*)(), boost::python::default_call_policies, boost::mpl::vector2<void, CArea&> > >::operator()(_object*, _object*) in PythonStuff.o

      boost::python::detail::caller_arity<2u>::impl<void (CArea::*)(double), boost::python::default_call_policies, boost::mpl::vector3<void, CArea&, double> >::operator()(_object*, _object*) in PythonStuff.o

      ...

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]: *** [area.so] Error 1

make[1]: *** [CMakeFiles/area.dir/all] Error 2

make: *** [all] Error 2

So it appears I'm moving forward. Any more hints? Google isn't helpful.

I said earlier I want to incorporate libarea in my project, but what I really want is libarea (CAM stuff) in FreeCAD. Dan Falck, I know you've done some work on that. I imagine I need to start by getting libarea built and installed as a Python module, then there is some script I could plug in to FreeCAD to make calls to libarea? I don't need backplotting, just GCode output.

 

>
> P.S. what is the difference between libarea and opencamlib?

libarea is for 2D pocketing and profiling. 

Sounds like I'm working on the right thing, then.

Thanks.

/Daryl 

[Anders Wallin]

> make produces a number of warnings regarding unary operator:
> warning: use of unary operator that may be intended as compound assignment
> (-=)

if you are using clang on mac then it is usually a bit more strict
than gcc and will find more warnings to complain about.

> then symbol errors:
> Undefined symbols for architecture x86_64:
> "_PyBool_FromLong", referenced from:

This is either failing to link properly with python and/or
boost-python, or possibly version mismatch between boost-python and
python.
Here is the result of "cmake .." and "make VERBOSE=1" on my machine (I
made a small change to my repo to display the Python_includes variable
also during the cmake run)
http://pastebin.ca/2246130
please check it carefully and compare to what you get on your machine.

If you look at the top of "PythonStuff.cpp" there is an include for
"Python.hpp" that I have commented out. On Ubuntu that seems to work,
but it may be required for other platforms. Figuring out a
build-system that works for linux, windows, mac, would be nice since
there are a number of libraries with python bindings that we
potentially want for all platforms.

> I said earlier I want to incorporate libarea in my project, but what I
> really want is libarea (CAM stuff) in FreeCAD. Dan Falck, I know you've done
> some work on that. I imagine I need to start by getting libarea built and
> installed as a Python module, then there is some script I could plug in to
> FreeCAD to make calls to libarea? I don't need backplotting, just GCode
> output.

For FreeCAD the long-term goal is to bundle everything with FreeCAD so
that all libraries will come compiled with a binary distribution, or
will be included in the big FreeCAD build for a source-distribution.
But we are still only developing the very basics of CAM within FreeCAD
so I think you will have to build and install the libraries separately
for some time still.

AW

[Daryl Stultz]

On Tue, Oct 16, 2012 at 1:03 AM, Anders Wallin <anders.e...@gmail.com> wrote:

> then symbol errors:

> Undefined symbols for architecture x86_64:
>   "_PyBool_FromLong", referenced from:

This is either failing to link properly with python and/or
boost-python, or possibly version mismatch between boost-python and
python.

If you should feel motivated, here's the output from my cmake/make: http://pastebin.ca/2246378

The only thing I can pick out is our Python versions are the same at 2.7 but your boost is 1.46.1 and mine is 1.51.0. Are they compatible?

If you look at the top of "PythonStuff.cpp" there is an include for
"Python.hpp" that I have commented out. On Ubuntu that seems to work,
but it may be required for other platforms.

I tried commenting it out but it exists due to too many errors emitted.

Thanks.

/Daryl 

[Daryl Stultz]

On Tuesday, October 16, 2012, Daryl Stultz wrote:

The only thing I can pick out is our Python versions are the same at 2.7 but your boost is 1.46.1 and mine is 1.51.0. Are they compatible?

This page: http://www.linuxfromscratch.org/blfs/view/cvs/general/boost.html

suggests Python 2.7.3 is required, I have 2.7.2. Is that be the problem?

/Daryl

[Anders Wallin]

>> This is either failing to link properly with python and/or
>> boost-python, or possibly version mismatch between boost-python and
>> python.
>
> If you should feel motivated, here's the output from my cmake/make:
> http://pastebin.ca/2246378
>
> The only thing I can pick out is our Python versions are the same at 2.7 but
> your boost is 1.46.1 and mine is 1.51.0. Are they compatible?

I don't know about 1.46.1 vs. 1.51.0, I am guessing they should be very similar.
Any chance that you have 32-bit binaries in your Boost-install? Are
there both 32 and 64-bit binary versions of Boost for OSX?

You could try building something very minimal with boost-python, like this:
https://github.com/aewallin/sandbox/tree/master/boost_python_helloworld
does that work? (note you have to move the .py file to the
build-directory for it to find the newly built module)

AW

[Daryl Stultz]

On Tue, Oct 16, 2012 at 5:07 PM, Anders Wallin <anders.e...@gmail.com> wrote:

I don't know about 1.46.1 vs. 1.51.0, I am guessing they should be very similar.
Any chance that you have 32-bit binaries in your Boost-install? Are
there both 32 and 64-bit binary versions of Boost for OSX?

I installed boost via homebrew which means it was all compiled rather than from pre-built binaries. I think that means it must be 64-bit, right? 

You could try building something very minimal with boost-python, like this:
https://github.com/aewallin/sandbox/tree/master/boost_python_helloworld
does that work?

No, same error. 

raptor:build daryl$ make

Scanning dependencies of target testmodule

[100%] Building CXX object CMakeFiles/testmodule.dir/main.cpp.o

Linking CXX shared module testmodule.so

Undefined symbols for architecture x86_64:

  "__Py_NoneStruct", referenced from:

      boost::python::detail::none() in main.cpp.o

I've installed Python 2.7.3 via homebrew to see if that helps. Now I need to figure out how to get the build process to use 2.7.3 instead of 2.7.2 that came with the Mac. 

/Daryl

[Anders Wallin]

> On Tue, Oct 16, 2012 at 5:07 PM, Anders Wallin <anders.e...@gmail.com>
> wrote:
>>
>>
>> I don't know about 1.46.1 vs. 1.51.0, I am guessing they should be very
>> similar.
>> Any chance that you have 32-bit binaries in your Boost-install? Are
>> there both 32 and 64-bit binary versions of Boost for OSX?
>
>
> I installed boost via homebrew which means it was all compiled rather than
> from pre-built binaries. I think that means it must be 64-bit, right?

some googling would suggest that building Boost with clang could lead
to the error message you see.
https://trac.macports.org/ticket/31525
llvm-gcc might work better.
Or indeed you have mismatching, or too old, python.

It's best to get the minimal example to build first before trying
larger projects!

[Daryl Stultz]

On Wed, Oct 17, 2012 at 12:41 AM, Anders Wallin <anders.e...@gmail.com> wrote:

Or indeed you have mismatching, or too old, python.

I see in CMakeCache.txt

Boost_INCLUDE_DIR:PATH=/usr/local/include

but I don't see anything that describes where it is finding Python stuff such as Python.h. How do I go about pointing cmake/make at a different Python installation?

Thanks.

/Daryl