[ros-users] ogre_tools broken on CTurtle/Snow leopard

[Nicholas Butko]

By "moderate success" I mean "wxhelloworld works, turtlesim works, rxgraph doesn't." 

wxwidgets website: http://www.wxwidgets.org/
On this website, you can find a lot of information about how wxwidgets 2.8 is a huge pain to use in osx 10.6, and wxwidgets 2.9 is better. Download and install the source archives from http://www.wxwidgets.org/downloads/#latest_dev
This worked okay, but it built and installed versions for 2.8 and 2.9. Confusingly, the 2.8 versions were installed to /usr/include (etc) and the 2.9 versions were installed to /usr/local/include (etc), and I later had to manually delete the 2.8 versions to avoid architecture conflicts. You can probably only build the 2.9 version by playing with config flags. 

wxpython website: http://www.wxpython.org
After some digging, you can find the wxpython 2.9 svn branch: http://www.wxpython.org/download.php#svnaccess
Note that wxpython really wants to be downloaded into the wxwidgets src tree. If you download it somewhere else, you will have to hack some of the build scripts. As it is, you will probably have to hack some of the build scripts to keep it from making i386 (32-bit) binaries. 

Here's the general sketch of the problem, to help you understand where you're getting errors and why: 

In OSX 10.6, Apple made two simultaneous changes: (1) 64-bit is the default build architecture, (2) legacy os libraries were not compiled with 64-bit support. 

This means that libraries that call legacy os libraries (like wx2.8) *cannot* be built for 64 bit, and neither can anything that links to them. However, the 64-bit default compile architecture makes it ridiculously annoying to build things without 64-bit, because it requires constant vigilance -- everything you compile always has to be explicitly 32-bit, and nothing wants to do that. It is really really easy to get conflicts. Using "+universal" in macports doesn't really solve this problem. It builds 32-bit and 64-bit versions of every library in macports that supports +universal (not all of them do).  But you still have to keep 64-bit binaries from creeping into your own codebase, or anything you install. Nothing will do this by default. So: constant vigilance!

Easier is to just go with the flow, and make everything 64-bit. This is why you would want to circumvent macports, and install wx* 2.9. You can do this through macports for wxWidgets, but *not* for wxPython. So you need to install at least wxpython manually from svn source. As I said at the outset, I had moderate success with this. The goal of this exercise is to get versions of wx* that have 64-bit binaries. Most errors you get from building will be related to that, and so that makes it easier to track down errors in the makefiles. 


On Oct 5, 2010, at 2:52 PM, Patrick Doyle wrote:

> OK,  now I think I'm at the sample place as you (Deepak) are:
> 
>  ld: warning: in
> /Volumes/ros/ros/tools/rospack/lib/librosstack.dylib, file was built
> for unsupported file format which is not the architecture being linked
> (i386)
>  Undefined symbols:
>    "_main", referenced from:
>        start in crt1.10.6.o
>  ld: symbol(s) not found
>  collect2: ld returned 1 exit status
>  make[3]: *** [../bin/stl_to_mesh] Error 1
>  make[2]: *** [CMakeFiles/bin/stl_to_mesh.dir/all] Error 2
>  make[1]: *** [all] Error 2
> 
> I expect I'll follow the same sequence you did and find the source of
> the problem is wxwidgets.
> 
> 
> I am curious to learn what Nicholas Butko meant when he said:
> 
> "I have recently had moderate success with wxwidgets 2.9.1 and
> wxpython 2.9.1, both installed manually, per instructions on the
> website."
> 
> Which website?  What does "moderate success" mean?
> 
> --wpd
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users