rbSFML

[Ceylo]

Code: [Select]

ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11]

OBJ_DIR    = "obj"
SO_DIR     = "sfml"
DOC_DIR    = "doc"
EXT_DIR    = "ext"
INST_DIR   = "/opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml" (found)

SFML_INC   = "include" (found)
SFML_LIB   = "lib" (found)

RUBY_INC   = "/opt/local/include/ruby-1.9.1" (found)
RUBY_LIB   = "/opt/local/lib" (found)
RUBY_LINK  = "-lruby.1.9.1"

CXX        = "/usr/bin/clang++"
CXXFLAGS   = "-pipe -O2 -Iinclude -Iext -I/opt/local/include/ruby-1.9.1 -I/opt/local/include/ruby-1.9.1/x86_64-darwin11 -Wall -Wextra "

LINK       = "/usr/bin/clang++ -dynamic -bundle"
LINK_FLAGS = "-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -Wl,-flat_namespace -L. -L/opt/local/lib  -arch x86_64 -L/usr/local/lib -Llib -L/opt/local/lib -lruby.1.9.1"
There are several options that I never used and some that look weird.
- Especially "-Wl,-undefined,dynamic_lookup" that tells the linker not to complain if there are undefined symbols, and look for them at runtime. This is weak linking, but I don't know why it's needed here.
- As for -multiply_defined, it's obsolete.
- -pipe is unknown to both Clang and ld. Only GCC knows it.
- And I don't know why -bundle is used. I'd rather expect -dynamiclib.


I changed the Rakefile with what you gave except some options (that do not exist with Apple's GCC) :

Code: [Select]

CXX = "g++"
CXXFLAGS = "-O3 -g -I#{SFML_INC} -I#{EXT_DIR} -I#{RUBY_INC} -I#{RUBY_INC}/#{CONFIG['arch']}"

LINK = "g++ -dynamiclib"
LINK_FLAGS = "-L. -L#{SFML_LIB} -L#{RUBY_LIB} #{RUBY_LINK}"
Which now gives

Code: [Select]

[ ceylo ceylo-pc ~/Desktop/rbSFML ] file /opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/graphics.so
/opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/graphics.so: Mach-O 64-bit dynamically linked shared library x86_64
instead of

Code: [Select]

[ ceylo ceylo-pc ~/Desktop/rbSFML ] file /opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/system.so
/opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/system.so: Mach-O 64-bit bundle x86_64
But I don't know a lot about Ruby or bundles so I don't know whether this change is useful.

Anyway, I still get the same error message when trying to launch Steel.

[Groogy]

Actually I jsut realized. You are running on 64 bit and compiling for 64bit. What kind of version is your ruby installation? 32 or 64?

Oh wait never mind it says that right there. It is 64bit system. I am at a loss. Your SFML libraries are 64 as well? I don't know anything else.

The problem is more or less that Ruby can't read the library files for some reason. It can be all from architecture to the filesystem not letting it.

[Ceylo]

Code: [Select]

[ ceylo ceylo-pc ~/Desktop/rbSFML ] which ruby
/usr/bin/ruby
[ ceylo ceylo-pc ~/Desktop/rbSFML ] file /usr/bin/ruby
/usr/bin/ruby: Mach-O 64-bit executable x86_64
[ ceylo ceylo-pc ~/Desktop/rbSFML ] file /opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/graphics.so
/opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/graphics.so: Mach-O 64-bit dynamically linked shared library x86_64
[ ceylo ceylo-pc ~/Desktop/rbSFML ] file /usr/local/lib/libsfml-graphics.dylib
/usr/local/lib/libsfml-graphics.dylib: Mach-O 64-bit dynamically linked shared library x86_64
If I try to run Steel in debug mode (-d):

Code: [Select]

[ ceylo ceylo-pc ~/Downloads/Steel src ] ruby -d Steel.rb
Exception `LoadError' at /opt/local/lib/ruby1.9/1.9.1/rubygems.rb:1264 - cannot load such file -- rubygems/defaults/operating_system
Exception `LoadError' at /opt/local/lib/ruby1.9/1.9.1/rubygems.rb:1273 - cannot load such file -- rubygems/defaults/ruby
Steel.rb:77: warning: ambiguous first argument; put parentheses or even spaces
Exception `LoadError' at /opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36 - cannot load such file -- sfml/graphics
Exception `LoadError' at /opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:63 - cannot load such file -- sfml/graphics
/opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- sfml/graphics (LoadError)
from /opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36:in `require'
from Steel.rb:2:in `<main>'
I'mma have a look at Ruby 'getting started' tutorials on OS X to see whether I missed something.

[Groogy]

I'm wondering if there is some read-write settings you have to set for Ruby and Steel.rb and so on?

You could try moving around the sfml folder in the ruby folder until you get results XD
Like I said I am out of ideas of what the problem might be so I am just spewing out brute force things now.

[Groogy]

Just realized, what happens if you create a ruby file in the ruby library directory and tries to load that? Can ruby find it?

[Ceylo]

Do you mean in /opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11 ?
I copied all of the Steel files there and it still can't load.

I also tried to run ruby as root in case the issue would be related to permissions, but it's still failing.
Even if I replace the 'require' with 'require_relative' in Steel.rb.

Code: [Select]

Steel.rb:2:in `require_relative': cannot load such file -- /opt/local/lib/ruby1.9/site_ruby/1.9.1/x86_64-darwin11/sfml/graphics (LoadError)
from Steel.rb:2:in `<main>'
PS: I may have an idea...

[Ceylo]

Is the extension that the Ruby libraries should take in the $CONFIG variable ?

[Groogy]

Is the extension that the Ruby libraries should take in the $CONFIG variable ?

I don't know, I think so. It got like everything about the environment in there. Just launch up irb in a console and type:

require 'rbconfig'
rbConfig::CONFIG

DAMNIT, I keep pressing modify when I want to quote xD

[Ceylo]

Code: [Select]

irb(main):009:0> RbConfig::CONFIG['DLEXT']
=> "bundle"
According to http://guides.rubygems.org/c-extensions/ , this is what I was looking for.
And using this extension and reinstalling, here is what I get :

Code: [Select]

/opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36:in `require': wrong argument type false (expected Module) (TypeError)
from /opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36:in `require'
from Steel.rb:1:in `<main>'
Where line 1 is just

Code: [Select]

require "sfml/graphics"(I redownloaded the sources to make sure I hadn't introduced errors in the game's sources)

[Groogy]

Alright just to be sure we get this right. I have to end the shared libraries on mac with bundle?

So more or less this should solve it for all platforms:

"#{SO_DIR}/#{file}.#{CONFIG['DLEXT']}"

I will create a "ceylo-branch" on the repo where I will do some printouts as of where it goes wrong and then you'll have to get back to me with the output log.

I will setup the branch now this weekend unless you know a better way to check. The error message doesn't say where it goes wrong it just says that something went wrong. What you could do until then is do a require on each library module and see what happens. This will give me a bit more precise information of what is happening.

rbSFML is just like SFML divided into system, window, graphics, audio. The difference is that rbSFML will check if the others have been loaded and if not load them for you.

boot up IRB in a console and type:

require 'sfml/system'
require 'sfml/window'
require 'sfml/graphics'

[Ceylo]

Code: [Select]

[ ceylo ceylo-pc ~/Downloads/Steel src-1 ] irb1.9
irb(main):001:0> require 'sfml/system'
=> true
irb(main):002:0> require 'sfml/window'
=> true
irb(main):003:0> require 'sfml/graphics'
=> true

Code: [Select]

[ ceylo ceylo-pc ~/Downloads/Steel src-1 ] irb1.9
irb(main):001:0> require 'sfml/graphics'
TypeError: wrong argument type false (expected Module)
from /opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36:in `require'
from /opt/local/lib/ruby1.9/1.9.1/rubygems/custom_require.rb:36:in `require'
from (irb):1
from /opt/local/bin/irb1.9:12:in `<main>'
If I add require 'sfml/window' in Steel.rb, before require 'sfml/graphics', it launches, then crashes.

Code: [Select]

Process:         ruby1.9 [91091]
Path:            /opt/local/bin/ruby1.9
Identifier:      ruby1.9
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  bash [90739]

Date/Time:       2012-04-28 11:19:48.006 +0200
OS Version:      Mac OS X 10.7.3 (11D50)
Report Version:  9

Interval Since Last Report:          369575 sec
Crashes Since Last Report:           10
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      58ED1128-DF39-4F74-B69D-C036FB889BA8

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
objc[91091]: garbage collection is OFF
*** error for object 0x7f8cc25a4650: pointer being freed was not allocated
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        0x00007fff8f35cce2 __pthread_kill + 10
1   libsystem_c.dylib              0x00007fff8824e7d2 pthread_kill + 95
2   libsystem_c.dylib              0x00007fff8823fa7a abort + 143
3   libsystem_c.dylib              0x00007fff8829e84c free + 389
4   libruby.1.9.1.dylib            0x0000000106602458 finalize_list + 184
5   libruby.1.9.1.dylib            0x00000001066e86a6 rb_threadptr_execute_interrupts_common + 86
6   libruby.1.9.1.dylib            0x00000001066e67c7 vm_call_method + 2423
7   libruby.1.9.1.dylib            0x00000001066d7cb4 vm_exec_core + 15172
8   libruby.1.9.1.dylib            0x00000001066e06e2 vm_exec + 98
9   libruby.1.9.1.dylib            0x00000001066ddc63 rb_yield + 99
10  libruby.1.9.1.dylib            0x00000001065c67cd rb_ary_each + 45
11  libruby.1.9.1.dylib            0x00000001066e60b9 vm_call_method + 617
12  libruby.1.9.1.dylib            0x00000001066d67af vm_exec_core + 9791
13  libruby.1.9.1.dylib            0x00000001066e06e2 vm_exec + 98
14  libruby.1.9.1.dylib            0x00000001066ddc63 rb_yield + 99
15  libruby.1.9.1.dylib            0x0000000106658218 range_each + 168
16  libruby.1.9.1.dylib            0x00000001066e60b9 vm_call_method + 617
17  libruby.1.9.1.dylib            0x00000001066d67af vm_exec_core + 9791
18  libruby.1.9.1.dylib            0x00000001066e06e2 vm_exec + 98
19  libruby.1.9.1.dylib            0x00000001066e0e48 rb_iseq_eval_main + 184
20  libruby.1.9.1.dylib            0x00000001065efa4f ruby_exec_internal + 111
21  libruby.1.9.1.dylib            0x00000001065ef997 ruby_run_node + 71
22  ruby1.9                        0x00000001065b9edf main + 79
23  ruby1.9                        0x00000001065b9e84 start + 52

[Groogy]

Can you try and find on what function it is that it crashes?

[Ceylo]

Yes sure!
It's the draw call at line ~262 (more or less, as I've added a few 'require') in Steel.rb.

Everything runs fine until I comment out this call.

[Groogy]

Yes sure!
It's the draw call at line ~262 (more or less, as I've added a few 'require') in Steel.rb.

Everything runs fine until I comment out this call.

Well that is a call to a method in the Game class. So you'll have to narrow done what in that function causes it. It begin at the line 67.

[Ceylo]

Uh, you're right. I didn't know how to recognize rbSFML methods from the Steel's ones.

So I've looked a bit further and I found out it crashes until I comment out "@app.view = @app.default_view" at line 59 of Steel.rb. I suppose it's related to rbSFML this time?