On 9/19/12 5:25 PM, Daniel Vandersluis wrote: > > On 2012-09-14, at 3:38 PM, Juergen Schmidt <[email protected]> wrote: > >> Am Freitag, 14. September 2012 um 20:56 schrieb Daniel Vandersluis: >>> I apologize if this is the wrong place for this message. >>> >>> I am trying to compile a Ruby gem that connects to OpenOffice through UNO. >>> I have it working perfectly under linux 64bit (by compiling the x86_64 DEBs >>> for OpenOffice and its SDK), however, I am now trying to get it set up >>> under MacOSX 10.8 (Mountain Lion) and am hitting a wall. >>> >>> I have GCC 4.2 (via xcode) and 4.7.1 (via homebrew) installed on my system, >>> and the ruby 1.9.3 libraries (installed for x86_64). I am actually able to >>> get my gem to install (which compiles for the native environment) under GCC >>> 4.7 and x86_64, however when I try to actually use my gem, I get the error >>> message: >>> >>> LoadError: >>> dlopen(/Users/daniel/.rvm/gems/ruby-1.9.3-p194/gems/rubyuno-0.3.3/lib/rubyuno/rubyuno.bundle, >>> 9): Symbol not found: __ZN4cppu11OWeakObject12queryAdapterEv >>> Referenced from: >>> /Users/daniel/.rvm/gems/ruby-1.9.3-p194/gems/rubyuno-0.3.3/lib/rubyuno/rubyuno.bundle >>> Expected in: flat namespace >>> >>> I've figured out that the bundle is not actually getting linked to the UNO >>> libraries, as they are built for i386. otool -L confirms: >>> >>> otool -L rubyuno.bundle >>> rubyuno.bundle: >>> /Users/daniel/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.1.9.1.dylib >>> (compatibility version 1.9.1, current version 1.9.1) >>> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version >>> 228.0.0) >>> /usr/local/Cellar/gcc/4.7.1/gcc/lib/libstdc++.6.dylib (compatibility >>> version 7.0.0, current version 7.17.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version >>> 169.3.0) >>> /usr/local/Cellar/gcc/4.7.1/gcc/lib/libgcc_s.1.dylib (compatibility version >>> 1.0.0, current version 1.0.0) >>> >>> I actually did end up getting my bundle compiled for i386 under gcc 4.2 by >>> hardcoding the -arch i386 flag, which gets the libraries linked into the >>> bundle: >>> >>> $ otool -L rubyuno.bundle >>> rubyuno.bundle: >>> @__________________________________________________URELIB/libuno_cppuhelpergcc3.dylib.3 >>> (compatibility version 0.0.0, current version 0.0.0) >>> @__________________________________________________URELIB/libuno_cppu.dylib.3 >>> (compatibility version 0.0.0, current version 0.0.0) >>> @__________________________________________________URELIB/libuno_salhelpergcc3.dylib.3 >>> (compatibility version 0.0.0, current version 0.0.0) >>> @__________________________________________________URELIB/libuno_sal.dylib.3 >>> (compatibility version 0.0.0, current version 0.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version >>> 169.3.0) >>> /Users/daniel/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.1.9.1.dylib >>> (compatibility version 1.9.1, current version 1.9.1) >>> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version >>> 228.0.0) >>> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version >>> 56.0.0) >>> >>> However why I try to load the gem I get: >>> >>> LoadError: >>> dlopen(/Users/daniel/.rvm/gems/ruby-1.9.3-p194/gems/rubyuno-0.3.3/lib/rubyuno/rubyuno.bundle, >>> 9): no suitable image found. Did find: >>> ./rubyuno.bundle: mach-o, but wrong architecture >>> /Users/daniel/.rvm/gems/ruby-1.9.3-p194/gems/rubyuno-0.3.3/lib/rubyuno/rubyuno.bundle: >>> mach-o, but wrong architecture - >>> /Users/daniel/.rvm/gems/ruby-1.9.3-p194/gems/rubyuno-0.3.3/lib/rubyuno/rubyuno.bundle >>> >>> This happens even if I compile ruby in "universal mode": >>> >>> $ rvm list >>> =* ruby-1.9.3-p194 [ universal ] >>> $ lipo -detailed_info /Users/daniel/.rvm/rubies/ruby-1.9.3-p194/bin/ruby >>> Fat header in: /Users/daniel/.rvm/rubies/ruby-1.9.3-p194/bin/ruby >>> fat_magic 0xcafebabe >>> nfat_arch 2 >>> architecture x86_64 >>> cputype CPU_TYPE_X86_64 >>> cpusubtype CPU_SUBTYPE_X86_64_ALL >>> offset 4096 >>> size 9444 >>> align 2^12 (4096) >>> architecture i386 >>> cputype CPU_TYPE_I386 >>> cpusubtype CPU_SUBTYPE_I386_ALL >>> offset 16384 >>> size 9348 >>> align 2^12 (4096) >>> >>> I have been going in circles for a couple days now trying to figure out how >>> to get this working. I have even tried to figure out how to compile >>> OpenOffice myself hoping that that way I'd be able to get x86_64 libraries >>> to work with, but that seems to be a whole other can of worms. Does anyone >>> have any suggestions and/or know of somewhere I can get OO compiled for Mac >>> x86_64? >> no, the bad news is that the port to 64bit on MacOS had to be done and is on >> our wish to-do list. If you are interested to help here it would be very >> much appreciated. >> >> Juergen >>> >>> Thanks, >>> >>> Daniel Vandersluis >>> Lead Developer, TalentNest >>> [email protected] >>> >>> >> >> > > Thanks for letting me know, Juergen. I would be interested to help but have > no idea how to!
I think a good first step is trying to build the office on your own on MacOS. One of our next steps is to become able to build the office with the latest XCode version, the related compiler and with 64 bit. See - http://wiki.openoffice.org/wiki/Documentation/Building_Guide - http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO and related platform specific pages. Feedback on the pages is also welcome and any kind of help how to improve them and make them more intuitive. Juergen > > - Daniel= >
