Problems building Blender on Mac OS X

Compiling, libraries, modules, coding guidelines and porting

Moderators: jesterKing, stiv

Post Reply
tron_thomas
Posts: 0
Joined: Thu Jan 13, 2005 6:20 am

Problems building Blender on Mac OS X

Post by tron_thomas » Tue Jan 24, 2006 7:00 am

I have been building Blender using SCons on a PowerMac system and it has been working really well.

I wanted to have an update version of Blender with the features that will be in Blender 2.41 available on my iBook laptop running Mac OS X 10.4.4 for demonstration purposes. So, I downloaded the source code through CVS.

When I try to build using SCons I get undefined symbols at link time. Some of these errors look like problems that have been encountered and solved in the past, and have resurfaced for whatever reason. Here is the error output:

/usr/bin/ld: Undefined symbols:
__Unwind_Resume
std::__default_alloc_template<true, 0>::deallocate(void*, unsigned long)
std::__default_alloc_template<true, 0>::_S_free_list
__ZNSt24__default_alloc_templateILb1ELi0EE5_LockC4Ev
__ZNSt24__default_alloc_templateILb1ELi0EE5_LockD4Ev
std::__default_alloc_template<true, 0>::allocate(unsigned long)
collect2: ld returned 1 exit status

What can be done to resolve these problems?

Also what is the best way to build Blender on the Macintosh? I saw some posted that indicated there was an Xcode project. How well does building through Xcode work?

lukep
Posts: 0
Joined: Sun Apr 04, 2004 1:39 pm

Re: Problems building Blender on Mac OS X

Post by lukep » Tue Jan 24, 2006 7:44 pm

tron_thomas wrote:I have been building Blender using SCons on a PowerMac system and it has been working really well.

I wanted to have an update version of Blender with the features that will be in Blender 2.41 available on my iBook laptop running Mac OS X 10.4.4 for demonstration purposes. So, I downloaded the source code through CVS.

When I try to build using SCons I get undefined symbols at link time. Some of these errors look like problems that have been encountered and solved in the past, and have resurfaced for whatever reason. Here is the error output:

/usr/bin/ld: Undefined symbols:
__Unwind_Resume
std::__default_alloc_template<true, 0>::deallocate(void*, unsigned long)
std::__default_alloc_template<true, 0>::_S_free_list
__ZNSt24__default_alloc_templateILb1ELi0EE5_LockC4Ev
__ZNSt24__default_alloc_templateILb1ELi0EE5_LockD4Ev
std::__default_alloc_template<true, 0>::allocate(unsigned long)
collect2: ld returned 1 exit status

What can be done to resolve these problems?

Also what is the best way to build Blender on the Macintosh? I saw some posted that indicated there was an Xcode project. How well does building through Xcode work?
the problems are due to the fact that the precompiled libs are made with gcc3.3 and you are using gcc3.4.

Either you recompile all the libs or use gcc_select to get 3.3 as defaut.

easiest way is scons, best is make

Xcode project is no more up to date, i have not the time to maintain it actually. when it was (and i will try to put it in shape), xcode was very easy to use too

tron_thomas
Posts: 0
Joined: Thu Jan 13, 2005 6:20 am

Post by tron_thomas » Wed Jan 25, 2006 4:30 am

Actually, I think with the development tools I have installed I might be building with gcc 4.0.

In my config.opts there are entries like
HOST_CC = 'gcc'
HOST_CXX = 'g++'
TARGET_CC= 'gcc'
TARGET_CXX = 'g++'

I'm thinking that if I change these settings to:
HOST_CC = '/usr/local/gcc-3.3'
HOST_CXX = '/usr/local/g++-3.3'
TARGET_CC= '/usr/local/gcc-3.3'
TARGET_CXX = '/usr/local/g++-3.3'

SCons will use the correct compiler for building Blender.

How accurate is this thinking?

tron_thomas
Posts: 0
Joined: Thu Jan 13, 2005 6:20 am

Post by tron_thomas » Wed Jan 25, 2006 4:57 am

Actually now that I think of it, the problem is more complicated. I can build just fine on my PowerMac system and it uses gcc 4.0. I updated the development tools on my iBook and it has gcc 4.0.1. It must be the difference in these two compiler versions that are causing the problem. Unfortunately, after the upgrade I no longer have 4.0 on the iBook, only 4.0.1.

How can I get the correct version of the needed 3rd party libraries when I want to build on my iBook?

lukep
Posts: 0
Joined: Sun Apr 04, 2004 1:39 pm

Post by lukep » Wed Jan 25, 2006 7:49 am

tron_thomas wrote:Actually now that I think of it, the problem is more complicated. I can build just fine on my PowerMac system and it uses gcc 4.0. I updated the development tools on my iBook and it has gcc 4.0.1. It must be the difference in these two compiler versions that are causing the problem. Unfortunately, after the upgrade I no longer have 4.0 on the iBook, only 4.0.1.

How can I get the correct version of the needed 3rd party libraries when I want to build on my iBook?
man gcc_select

tron_thomas
Posts: 0
Joined: Thu Jan 13, 2005 6:20 am

Post by tron_thomas » Thu Jan 26, 2006 6:38 am

Since I have been successfully building Blender on my PowerMac system which should have been using gcc 4.0.0, I assumed that Blender builds successfully on version 4.0.0 and not on version 4.0.1. I did not mess around with any compiler versions or anything. I just had to make some small tweaks and it build just fine.

I cannot use gcc_select to change my compiler from gcc 4.0.0 to 4.0.1. The system only has the 4.0.1 compiler.

Other information I've seen seems to indicate that gcc 3.3 should work. I did not want to change my default compiler to version 3.3 using gcc_select. I found that changing the settings in the config.opts file does make SCons build with gcc 3.3. However after updating again from CVS, cleaning the build and compiling, I'm now getting the following link errors:

__ZNSt15_List_node_base4hookEPS_
__ZNSt15_List_node_base6unhookEv
__ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
__ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base
__ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_
__ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
__ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base
_fprintf$LDBLStub
_sprintf$LDBLStub

Bischofftep
Posts: 0
Joined: Thu Feb 06, 2003 11:01 pm
Location: Richmond, VA
Contact:

Continued Problems

Post by Bischofftep » Wed Feb 01, 2006 6:14 pm

Well, I've hit this problem as well.

I'm running Apple's GCC 4.0.0 on a Dual 2.0 G5.

I've pulled my own copies (& compiled them) of:
OPENEXR
JPEG
LIBPNG
TIFF
ZLIB
FREETYPE2

That's all I could find to do.

I've got all the NAN defines pointing to the new locations.

I still get this error! Any ideas which library this is coming from, or how to get around it? I would rather not backtrack and install gcc 3.3, but if that's the only option...

kidb
Posts: 0
Joined: Wed Jul 23, 2003 4:31 pm
Contact:

Re: Continued Problems

Post by kidb » Wed Feb 01, 2006 6:25 pm

I once had similar errors on my debian system caused by a wrong version of a package called binutils. Contents of package: addr2line, ar, as, c++filt,gprof, ld (!), nm, objcopy, objdump,ranlib, readelf, size,strings,strip. Maybe your ld doesn't like your gcc.

lukep
Posts: 0
Joined: Sun Apr 04, 2004 1:39 pm

Re: Continued Problems

Post by lukep » Wed Feb 01, 2006 8:37 pm

Bischofftep wrote:Well, I've hit this problem as well.

I'm running Apple's GCC 4.0.0 on a Dual 2.0 G5.

I've pulled my own copies (& compiled them) of:
OPENEXR
JPEG
LIBPNG
TIFF
ZLIB
FREETYPE2

That's all I could find to do.

I've got all the NAN defines pointing to the new locations.

I still get this error! Any ideas which library this is coming from, or how to get around it? I would rather not backtrack and install gcc 3.3, but if that's the only option...
you dont have to backtrack.

the command gcc_select will do the job for you and select the right compiler.
all libs must be compiled with same ABI and those in CVS ae for gcc3.3

this means you lack :
ftgl
gettext
openal
sdl
qhull and solid are normally recompiled so no pb

Bischofftep
Posts: 0
Joined: Thu Feb 06, 2003 11:01 pm
Location: Richmond, VA
Contact:

Alas...

Post by Bischofftep » Wed Feb 01, 2006 8:54 pm

Alas, gcc_select only works if a previous version of gcc is installed on the computer. It isn't: only 4.0 is. When I tried gcc_select it told me that "gcc version 3.3 not installed."

I can't find any build of 3.3.X from Apple, and don't relish compiling gcc without all the Apple-specific extensions, so I'm kind of stuck.

I'll try those other librarires, but I know openal wouldn't compile and ftgl isn't available the "easy" way. I'll see about recompiling using a manual code checkout rather than "port." *sigh*

lukep
Posts: 0
Joined: Sun Apr 04, 2004 1:39 pm

Re: Alas...

Post by lukep » Wed Feb 01, 2006 11:58 pm

Bischofftep wrote:Alas, gcc_select only works if a previous version of gcc is installed on the computer. It isn't: only 4.0 is. When I tried gcc_select it told me that "gcc version 3.3 not installed."

I can't find any build of 3.3.X from Apple, and don't relish compiling gcc without all the Apple-specific extensions, so I'm kind of stuck.

I'll try those other librarires, but I know openal wouldn't compile and ftgl isn't available the "easy" way. I'll see about recompiling using a manual code checkout rather than "port." *sigh*
gcc4 package comprises gcc3.3 but you did not installed it

Bischofftep
Posts: 0
Joined: Thu Feb 06, 2003 11:01 pm
Location: Richmond, VA
Contact:

Not an option

Post by Bischofftep » Thu Feb 02, 2006 3:13 pm

Not my fault: Apple's wisdom in distributing XCode 2.2 provides GCC 4.0.1 only, with no options to install GCC3.3.

Still looking into this. Thanks for your help!

kattkieru
Posts: 17
Joined: Wed Oct 16, 2002 3:30 pm

Post by kattkieru » Fri Feb 17, 2006 7:16 pm

Dumb question:

Since this is going to be an issue with people between compilers, why not include the sources for the libs inside the lib directories?

That way, people could more easily compile the libs on their own. I know that the original reason the libs were included as binaries was to simplify the build process, but if precompiling them leads to issues like this (I was hit with it too) then it might be best to have an optional libs-sources folder in CVS as well.

That way, a simple shell script or makefile could make all the libraries and either copy them or make symbolic links so that the scons files aren't confused, for people using gcc4. Thoughts?

jesterKing
Site Admin
Posts: 207
Joined: Fri Oct 18, 2002 12:48 pm
Location: Finland

Post by jesterKing » Fri Feb 17, 2006 8:32 pm

kattkieru wrote:Since this is going to be an issue with people between compilers, why not include the sources for the libs inside the lib directories?
The precompiled libs are not in the main tree, because there are many platform specific files in there. When I'm on my win32 laptop, I really don't want all the other libs - it is quite a lot of 'garbage'. Secondly, the precompiled libs are not source, so they don't belong in the source tree.

/Nathan

ps. config.opts is obsolete. see the scons documents in doc/ of your checkout for more info.

Post Reply