Link error under Tiger

Compiling, libraries, modules, coding guidelines and porting

Moderators: jesterKing, stiv

Post Reply
osxrules
Posts: 0
Joined: Wed Jun 02, 2004 6:34 pm

Link error under Tiger

Post by osxrules »

I finally got my dev tools for Tiger and compilation has gone fine so far. I'm getting an error about linking though and it is the following:

/usr/bin/ld: Undefined symbols:
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)

I don't know where the functions are being called either.

osxrules
Posts: 0
Joined: Wed Jun 02, 2004 6:34 pm

Post by osxrules »

Thanks for the fast responses guys :roll:. Anyway, I managed to get it fixed by tracing the default_alloc_template call thanks to a suggestion from Duoas. I eventually discovered the problem in OpenAL.

So, I got it to build using the OpenAL that is built into Tiger - it seems to work too because I can hear the sound in some games I have. Also rather than use the blender.app wrapper that comes in CVS, which didn't work, I copied the Blender 2.37 release and replaced the binary. It seems to be running a bit faster but not much. I have all the optimizations at max and the difference is not really noticable.

It's compiled with the auto-vectorization options under 10.4.1 and on a G4.

There are a few problems though. I'm getting streaky lines in my renders (I think that happened to one of the PC optimized versions too) and the binary is 5 times bigger than the release. There must be a lot of redundancy in there though because it zips down from 45MB to 11MB. Oh well, at least I know I can compile the latest CVS on Tiger with XCode 2.1 so I can hopefully get previews of all the bugs... er I mean great new features coming in 2.38 ;).

Update:
got the lines in the render problem fixed - Blender doesn't like it if you set the gcc optimization settings higher than 0 for some reason.

I also got the code size problem fixed - I just strip off the debug symbols. You can do it by setting XCode to do a deployment postprocess or you just run the command line strip command with the Blender build as an argument. The latter is better because it means you don't have to recompile. It reduced the Blender build down to the same as the release version so you don't have to use the makefiles for a small binary.

Update 2:
I removed one of the compiler flags and that sorted the problem with the renderer breaking while having the optimization higher than 0. Because auto-vectorization only works at level O2 and higher, it meant this was functioning too.

I also made a deployment build. The result was that I got a 1/3 smaller binary. However, the performance is the same. After turning on verbose for the auto-vectorization, I discovered that it only vectorized a very small number of loops. Probably over 95% were ignored.

This seems to be a flaw in the auto-vectorization with it being a new feature. GCC 4.1 should make auto-vectorization better but the only solution for Altivec currently is to either manually vectorize code or alter loops so that they are supported by auto-vectorize. The latter is the best option since with manual vectorization, switching to Intel will mean code is unusable.

Post Reply