Need Help Compiling Gem for 32 bit Mac OS X

Anton_S

Hello guys,

I recently got a Mac OS X Maverick, installed SU, and even fixed all bugs on SP for SU2013 and below. All I'm left with is making it compatible on SU2014, which requires ffi_c.bundle. I succeeded in compiling ffi_c.bundle, but keep getting errors when require ffi_c.bundle in SketchUp: match -o, but wrong architecture, or BugSplat. I searched online for help, attempt different solutions, but no success. Many developers experience these errors when they upgrade to Mac OS X Mountain Lion or later, which is based on 64 bit platform. SketchUp uses 32 bit platform. If any of you have a 32 bit Mac OS X, please be willing to help.

Open terminal and type these commands (don't type in the comments):


# Install xcode
# If this command fails, try downloading xcode based on your OS;
# http://stackoverflow.com/questions/1596164/can-i-get-xcode-for-leopard-still
xcode-select --install

# Install RVM - Ruby version manager
\curl -sSL https://get.rvm.io | bash -s stable

# This step will take a while as it will install all required tools.
# Press return when it requests you for verification.
rvm install ruby-2.0.0-p247

# Initialize brew
brew doctor

# Make sure we use installed Ruby
rvm --default ruby-2.0.0-p247

# Now, install FFI gem.
sudo gem install ffi

# Lastly take ffi_c.bundle and share it to me!
# 1. Open finder menu and select Go to Folder...
# 2. Paste this path; /Users/YOUR_NAME/.rvm/gems/ruby-2.0.0-p247@global/gems/ffi-1.9.3/lib
# 3. Take ffi_c.bundle and upload it here.

Most of you who have compiled bundles before won't have to go through all the initial installations steps. Any suggestions would be helpful.

Thanks in regards,
Anton

tt_su

Welcome to a world of pain. Compiling i386 Ruby under OSX Maverics is what forced me to migrate my C extensions for Vertex Tools and TT_Lib2 to C++ extensions.

The only 32bit mac I have left is my old G4 Mac Mini.

Anton_S

I had enough pain to figure out how to compile it in the first place, but then these C++ extensions... FFI consists of multiple .c and .h files. There is no way for me to turn them into C++ extension as its a huge library (unless there is an easy way).

If no one posts a compiled ffi_c.bundle in 2 days, I'd get myself Mac OS X 10.4 on VMWARE virtual machine, illegally, but there is not other choice.

ThomThom, you say this forced you to migrate to C++, how come, could you provide the key point?

tt_su

@anton_s said:

ThomThom, you say this forced you to migrate to C++, how come, could you provide the key point?

Because multiple Ruby versions on OSX is a pain. RVM makes it much easier, but the versions required to compile for Ruby 1.8 and 2.0 in i386 configuration is still troublesome. No one really uses them and with OSX Mavericks it became to difficult. I always ended up with some error building. After many days I called forfeit and took our Hello World C++ example and hooked up my C extension.

All though, gems are a different animal...

Anton_S

Thanks for the heads up, TT, I will install 10.5.8 Leopard. According to online search people experienced errors when they upgraded to Snow Leopard (10.6.x) or later. I assume it will work properly on Leopard (10.5.x).

slbaumgartner

After much hair-pulling and tweaking by hand, I got a GEM to compile under Mavericks and SU 2014. It was such an ad-hoc mess that I don't recommend trying it!

Unfortunately, the Ruby installed by SU is not configured correctly to enable compiling a GEM. Among the many issues I wrestled with: the build script for that particular GEM assumed there was a ruby interpreter available at the path set up by SU - which there is not, only the framework library; the mkmf system determinedly generated makefiles for the native architecture (64-bit) and the system-installed Ruby - which led to all sorts of clashes; some libraries and features that are normally part of the Ruby distribution were suppressed by Trimble after finding they caused bugsplats in SU.

This is a shame, because one of the supposed advantages of a GEM is that you don't have to be an expert code developer to build and install it. However, after what I went through I can sympathize with Trimble and TT: fixing it is way harder than it sounds!

driven

Hi Anton

libffi.6.dylib is included in the Sketchup Ruby framework.

is it possible to utilise that for your needs???

just thinking out loud...

john

slbaumgartner

@driven said:

Hi Anton

libffi.6.dylib is included in the Sketchup Ruby framework.

is it possible to utilise that for your needs???

just thinking out loud...

john

fiddle is the Ruby 1.0.0 wrapper for libffi. I haven't tried using it, but require 'fiddle' returns true on SU 2014, so maybe John's idea is your easiest route?

Anton_S

@slbaumgartner said:

@driven said:

Hi Anton

libffi.6.dylib is included in the Sketchup Ruby framework.

is it possible to utilise that for your needs???

just thinking out loud...

john

fiddle is the Ruby 1.0.0 wrapper for libffi. I haven't tried using it, but require 'fiddle' returns true on SU 2014, so maybe John's idea is your easiest route?

Yes, Fiddle is a good idea, but the way you interact with functions is a bit more similar to Win32API rather than Ruby DL or FFI. SketchyPhysics uses Ruby DL for 1.8.x categories and Ruby FFI for 2.0.x categories since DL was deprecated since 1.9.3. The way you call functions in DL and FFI is function_name(params), but in Fiddle, you should write function_name.call(params). Which forces me due much more work in compatibility, but it does avoids the pain of compiling. I will attempt to compile FFI in Mac OS X 10.5.8 If no luck, I migrate to Fiddle.

Thanks for suggestions

tt_su

My general experience is that it's much simpler to just write a C++ extension that makes the system calls one need.

willeykj

@anton_s said:

@slbaumgartner said:

@driven said:

Hi Anton

libffi.6.dylib is included in the Sketchup Ruby framework.

is it possible to utilise that for your needs???

just thinking out loud...

john

fiddle is the Ruby 1.0.0 wrapper for libffi. I haven't tried using it, but require 'fiddle' returns true on SU 2014, so maybe John's idea is your easiest route?

Yes, Fiddle is a good idea, but the way you interact with functions is a bit more similar to Win32API rather than Ruby DL or FFI. SketchyPhysics uses Ruby DL for 1.8.x categories and Ruby FFI for 2.0.x categories since DL was deprecated since 1.9.3. The way you call functions in DL and FFI is function_name(params), but in Fiddle, you should write function_name.call(params). Which forces me due much more work in compatibility, but it does avoids the pain of compiling. I will attempt to compile FFI in Mac OS X 10.5.8 If no luck, I migrate to Fiddle.

Thanks for suggestions

Anton,

You can use Fiddle and retain the "normal" calling syntax if you use Fiddle::Importer.

Anton_S

Well, okay, seems I'm convinced to use Fiddle

Anton_S

Okay, I finished migrating to Fiddle. It wasn't as complicated as I thought. In fact, file sizes got way smaller since DL and Fiddle use same techniques to import functions.

One thing to note, imported functions remain capitalized in Ruby 2.0.0, but are not capitalized in 1.8.x categories. I had to add some wrapper methods for compatibility.

I ought to finish some things on the TODO list before uploading 3.4. Thanks for ya'll help, especially willeykj!

You guys rock!

Anton_S

Oh wait, Fiddle::Importer is very similar to DL::Importable. I will migrate to Fiddle.
Sorry for misleading you guys.

Thanks for all the help