Extension fails to link on OSX64
bil-bas opened this issue · comments
Works fine on win32, of course.
Error is: ld: duplicate symbol _rb_cColor in color.o and ashton.o for architecture x86_64
I do not get this error, but a duplicate _sin_lookup because it is defined in a header. It should be extern there, and be defined in fast_math.c.
Ah, I'll sort that out, thanks! Hate that different C compilers seem let me get away with different things...bah!
FWIW the latest git head linked fine for me on 64-bit OS X.
But then it crashed at runtime for this one example:
mini:examples jlnr$ ruby particle_emitter_example.rb
dyld: lazy symbol binding failed: Symbol not found: _fast_sin_deg
Referenced from: /Users/jlnr/.rvm/gems/ruby-1.9.3-p286/gems/ashton-0.0.1alpha/lib/ashton/1.9/ashton.bundle
Expected in: flat namespace
dyld: Symbol not found: _fast_sin_deg
Referenced from: /Users/jlnr/.rvm/gems/ruby-1.9.3-p286/gems/ashton-0.0.1alpha/lib/ashton/1.9/ashton.bundle
Expected in: flat namespace
Trace/BPT trap: 5Thanks for reporting that; I thought it all worked now. Not having a Mac is a pain, especially since your compiler is a biscuit ;)
@jlnr Can you give that example another go at compiling and running on OSX please? I got rid of inlining, so that function shouldn't be any different to any other now.
I get to render 125k particles @ 60fps in that example on Linux, which is a lot better than on Windows, which is nice! However, I get a segfault or GC exception after a while (on that example or the particle emitter benchmark), so something is still very, very wrong!
Yep, it works now. It crashes after a while but until then I get ~123k particles at 50 FPS. Not as nice as your score but good enough :)
FWIW the debugger points to if(particle->time_to_live > 0)
So the particle has probably been released already. Or may be the compiler just notices the unaesthetically missing space between if and ( and spits its latte all over the binary. :P
The particles don't get released. When you create the emitter, you set the max number of particles and it creates an array of structures and re-uses them. A particle that is destroyed has its time to live set to -1 or something. Saves a lot of creation and destruction, though whether it is really any faster is anyone's guess.
Incidentally, there are at least 5 lines that have if(particle->time_to_live > 0) in them :P
This is the top of backtrace before the Ruby VM internals begin:
update_vbo [inlined] () at /Users/jlnr/.rvm/gems/ruby-1.9.3-p362/gems/ashton-0.0.1alpha/ext/ashton/particle_emitter.c:452
452 if(particle->time_to_live > 0)
(gdb) backtrace
#0 update_vbo [inlined] () at /Users/jlnr/.rvm/gems/ruby-1.9.3-p362/gems/ashton-0.0.1alpha/ext/ashton/particle_emitter.c:452
#1 0x0000000102f2cab0 in Ashton_ParticleEmitter_update (self=<value temporarily unavailable, due to optimizations>, delta=<value temporarily unavailable, due to optimizations>) at particle_emitter.c:781
Thanks. I think I've caught that one now (and pushed a fix), but there is another segfault happening now which doesn't give useful info in the standard report. Need to work out how to use gdb with it 😊 Windows, where I did the initial development of Ashton, just doesn't care about its memory, obviously!
This bug (not building) is fixed anyway. I'll start a new one for the segfaults.