Need Help Compiling Gem for 32 bit Mac OS X
-
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.
-
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?
-
@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...
-
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).
-
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!
-
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
-
@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?
-
@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
-
My general experience is that it's much simpler to just write a C++ extension that makes the system calls one need.
-
@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.
-
Well, okay, seems I'm convinced to use Fiddle
-
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!
-
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
Advertisement