[Tutorial] SketchUp Ruby C Extension

Dan Rathbun

(Ruby-Talk GoogleGroup) Common Traps for C extensions

tomasz

I am trying to build the Basic sample under Xcode 4.4, but I am probably doing something wrong, because the resulting bundle fails to load into SU. I get "#<LoadError: myplugin.bundle Failed to load myplugin.bundle". I do not even get the "Failed to find init.. " error.

When compiling with extconf.rb and make the plugin loads just fine.

What project type should I start with to get the extension running? I have already tied /Framework/Bundle, Generic C++ Plug-in. How can I force the -flat_namespace in Xcode?

thomthom

I've never used XCode. :s
But if you find out, could you post back here? It'd be nice to include alternative setups.

Dan Rathbun

I am sure that I remember an old thread where someone explained how to do a OSX extension. I think they said you had to link it to the framworkized Ruby that is under the SketchUp app directory (not the system Ruby that Apple installs.) .. If I recall correctly, that is.

thomthom

I didn't have to relink anything. But I'm not familiar with his scenario of XCode 4.4.

Dan Rathbun

I'll have to find the old topic.

Is v4.4 too new to work with such an old Ruby version as 1.8.5-p0 ??

thomthom

Dunno - what OS are we talking about?

I've only done this on OSX 10.4 and 10.5. Maybe the Ruby that shipped there was compatible with SketchUp's Ruby - and this new version isn't and might actually require you to link to SketchUp's libs? I'm just taking a stab in the dark here.

Jim

@dan rathbun said:

(Ruby-Talk GoogleGroup) Common Traps for C extensions

[off:i2j9ll26]I prefer this interface to the Ruby forum:

(www.ruby-forum.com)

I just don't care for the Google groups interface.[/off:i2j9ll26]

tomasz

@dan rathbun said:

I'll have to find the old topic.

Is v4.4 too new to work with such an old Ruby version as 1.8.5-p0 ??

I don't think so.

The "make" command uses same complier that is bundled with XCode , that is LLVM GCC 4.2.
When the extension is compiled this way, it works fine in SU. It looks like it is just a matter of placing correct settings in proper Xcode windows.

The "-dynamic -bundle -flat_namespace " flags go to 'Linker/Other Linker Flags'. I have chosen STL C++ Library template ... which produces a C++ dynamic shared library (.dylib). I guess it is right type. Unfortunately it does not load with require "extension". Something is still missing.

thomthom

@unknownuser said:

I have chosen STL C++ Library template ... which produces a C++ dynamic shared library

Wait, are you making a C++ extension instead of C?

I've seen some people making Ruby extensions in C++, but you need to perform some extra steps. Something like extern "C".

http://rice.rubyforge.org/
http://www.ruby-forum.com/topic/128668
https://www.google.com/search?hl=en&client=firefox-a&hs=LXd&rls=org.mozilla:en-US:official&q=+site:ruby-forum.com+ruby+c+extension+c%2B%2B&sa=X&ei=7zJXUK62LvLV4QTAvIGgCQ&ved=0CFMQrQIwAw&biw=1600&bih=1096

Dan Rathbun

@unknownuser said:

I have chosen STL C++ Library template ... which produces a C++ dynamic shared library (.dylib). I guess it is right type. Unfortunately it does not load with require "extension". Something is still missing.

It should according to the description of Kernel.require()

(1) Try the whole filename: require("extension.dylib")

(2) Try specifying Kernel.require("extension_name") instead of the copy of require() that is inherited by Object. (Some naughty plugin could have changed it.)

(3) Be aware that require has undergone changes over the years, to both fix some bugs (early on it pushed filepaths into $LOADED_FEATURES before it was determined if the files loaded successfully,) and to change the iteration of paths in $LOAD_PATH (it used to iterate the $LOAD_PATH array multiple times for each filtype { .rb, .so, .o, .dll, ...etc.} This was changed later on so it only iterates each directory once.) One of the major SNAFUs with dealing with different Ruby versions for different SketchUp platforms and versions.

(4) require() has ALWAYS first checked to see if the argument resolves to a valid absolute filepath, and loads that valid file, instead of iterating through the $LOAD_PATH array.

tomasz

@thomthom said:

Wait, are you making a C++ extension instead of C?

Yes. I have finally made it. What a nightmare

Xcode

New Project

Template > "Command Line Tool"!

Enter product name "SX_HelloWorld.bundle"

Type "C++"

The *.c file renamed to *.cpp.
Init_SX_HelloWorld( void ) has to be enclosed in extern "C"

extern "C" {
// The init function here
}

The last line of the code should read:

rb_define_module_function( mSUExtTest, "knock_knock", RUBY_METHOD_FUNC(rb_knock), 0 );

Now the important thing

Build Settings\Linking\Other Linker Flags > -dynamic -bundle -undefined suppress -flat_namespace

Build Settings\Search Paths\Header Search Path > has to point to Ruby headers
Build Settings\Search Paths\Library Search Path > has to point to Ruby compiled library

I have compiled the extension with LLVM GCC 4.2

thomthom

Where does this macro come from? RUBY_METHOD_FUNC

tomasz

@thomthom said:

Where does this macro come from? RUBY_METHOD_FUNC

This sits in ruby.h. Without getting a proper pointer type the code will not compile, since it is C++ now.

#define RUBY_METHOD_FUNC(func) ((VALUE (*)(ANYARGS))func)

tomasz

@dan rathbun said:

Is v4.4 too new to work with such an old Ruby version as 1.8.5-p0 ??

I have compiled the sample extension using dynamic library. My Lion has Ruby 1.8.7 present and this simple example worked just fine.

I am trying to compile Ruby 1.8.5 as a static library now and it looks that with Xcode 4.4, it is next to impossible to get things right. I wish I had Snow Leopard with Xcode 3.2.

Anton_S

When recompiling Win32::API under own namespace, do not use -Ox flag.
The -Ox flag from [Compiler Options](http://msdn.microsoft.com/en-US/library/19z1t1wy(v), which creates maximum optimization causes SketchUp to produce a bugsplat right after completion of callback function enumeration.

Example:

module My;;CallbackTest
  EnumWindows = My;;Win32;;API.new('EnumWindows', 'KP', 'I', 'User32')
  EnumWindowsProc = My;;Win32;;API;;Callback.new('IP', 'I'){ |hwnd, lParam|
    puts hwnd
    1 # continue process
  }
  
  def self.listWindowHandles
    EnumWindows.call(EnumWindowsProc, nil)
    # With Compiled $CFLAGS = '-MT -Ox -W4'
    #   SU crashes right after enumation through all parent handles.
    # With Compiled $CFLAGS = '-MT -W4'
    #   SU works fine, although the size looks ~1.5 KB greater than with the -Ox flag.
  end
end

When compiling Win32::API, I have $CFLAGS = '-MT -W4'

...just sharing some Win32::API compilation experiments

thomthom

Good to know!

I should add some warning about the -Ox flag that it might cause problems - since it's very aggressive optimization.

thomthom

Call for information

I´ve only used a Mac Mini PPC with 10.4 and a Mac Mini Intel with 105 when compiling C Extensions under OSX.

I´m getting all sorts of warning that 10.5 isn´t supported anymore, from Apple and the software. Fair enough.

But what I´d like to know is:
If I update to Montain Lion - what would I need to get SketchUp Ruby C Extensions running?
I take it that the OS Ruby versions is much newer now - and I´d have to link the build to something other than the OS Ruby?

Also, when compiling a C Extension under Mountain Lion - how backwards compatible will it be?

AdamB

@thomthom said:

I take it that the OS Ruby versions is much newer now - and I´d have to link the build to something other than the OS Ruby?

No, a Plugin resolves the symbols on load.

@thomthom said:

Also, when compiling a C Extension under Mountain Lion - how backwards compatible will it be?

As much as you ask for it to be: eg -mmacosx-version-min=10.4 will ensure it runs on 10.4 and up.

@thomthom said:

I should add some warning about the -Ox flag that it might cause problems - since it's very aggressive optimization.

Just to correct this. The optimization does not produce 'wrong code' per se. Its that it commonly will remove leaf function stack frames to increase performance, meaning Ruby's GC can't find a reference to a Object and it gets marked for collection. So ensure you keep references and you'll be fine.

thomthom

@adamb said:

No, a Plugin resolves the symbols on load.

Really? But if the OS Ruby is 1.9, and I compile without doing anything. Won't it be compiled for 1.9 only then? Isn't there completely different functions between 1.8 and 1.9?

@adamb said:

As much as you ask for it to be: eg -mmacosx-version-min=10.4 will ensure it runs on 10.4 and up.

Where does this flag go in the compile process? In the MAKEFILE? In the arguments of the make command?
(I'm very green to this.)

@adamb said:

Just to correct this. The optimization does not produce 'wrong code' per se. Its that it commonly will remove leaf function stack frames to increase performance, meaning Ruby's GC can't find a reference to a Object and it gets marked for collection. So ensure you keep references and you'll be fine.

Thanks for the clarification.