RubyCocoa 0.11.1

[Eloy Duran]

> The only extension that doesn't compile is the openssl one, I can only
> compile it as a i386 binary. However if I apply the macports patches
> (plus my own) and then configure it to use /usr, so where the apple
> supplied libs are then it compiles without a problem.

I should add that I am on a intel machine :)

Eloy

On 7/13/07, Eloy Duran <eloy.de.enige at gmail.com> wrote:
> Hey Ryan & list,
>
> > Ok, so either "universal_variant no" should be added to the rb-
> > hpricot port, or the rb-hpricot port should be fixed so it can build
> > universal. I'm Cc'ing Paul Guyot who maintains rb-hpricot.
>
> I tested hpricot from source and it's capable of building a universal binary.
> However it gets it's config from the ruby config, so when using a
> non-universal ruby it will definitely not build the C extension as a
> universal bin.
>
> So I've been focussing on ruby for now in the hope that I can patch
> mkmf.rb in such a way that any ruby C extensions that use extconf to
> create a Makefile will be build as universal binaries. However I'm not
> sure if all the binary gems are really build on the machine or are
> distributed as binaries, but I believe they only have binaries for
> mswin.
>
> > > Also rubygems has a problem with the universal variant, I added the
> > > following to the portfile to fix it:
> > >
> > > variant universal {
> > >       configure.args-delete --disable-dependency-tracking
> > > }
> > >
> > > Is this the correct way to do it?
> >
> > No. You have effectively made the port no longer attempt to build
> > universal by doing that.
> < *snip*
> > What you probably want instead of "variant universal {...}" is:
> >
> > pre-configure {
> >         if {[variant_isset universal]} {
> >                 configure.args-delete --disable-dependency-tracking
> >         }
> > }
> >
> > That's assuming, of course, that it's really necessary to remove "--
> > disable-dependency-tracking". The reason it's there by default for
> > +universal is that it's needed for most (all?) configure-based
> > software when building universal.
>
> Thanks, I was indeed simply killing the universal option :)
>
> Rubygems is not configure based software, it uses a pure ruby config
> script which doesn't take the --disable-dependency-tracking option.
> Actually I don't think any software in rubygems is anything other than
> pure ruby, so it doesn't really matter anyways....
>
> > Now, rb-cocoa is in the ruby portgroup. These changes you're making
> > to make it universal... might they also be relevant for the other
> > ports in the ruby portgroup? If so, perhaps your changes, once you
> > figure out how to build a ruby thing universal, should go into
> > MacPorts base, rather than into each individual ruby-related portfile.
>
> My hope is that once I have a fully functional universal ruby and
> apply some patches to mkmf.rb that any ruby C extension will be build
> as universal binaries. Also through rubygems. There will of course
> always be exceptions to this....
>
> >
> > > One other thing I hadn't noticed earlier is that ruby itself does not
> > > work with the universal variant. I could of course also add
> > > "universal_variant no", but this will defeat the purpose of building
> > > rubycocoa as a universal.... So does anybody know if ruby is already
> > > being worked on?
> >
> > No idea. Have you already asked Paul? He's also the maintainer of the
> > ruby port. Also, have you already built all of Ruby's dependencies
> > universal? That would be the first required step.
>
> Ok, this is where I'm at.
> All the dependencies are universal binaries, these all worked out of
> the box with macports. I have succesfully patched the configure script
> to build a universal ruby with --enable-shared. I have patched mkmf.rb
> to correctly build extensions that might do any checks in there
> extconf, like zlib.
>
> The only extension that doesn't compile is the openssl one, I can only
> compile it as a i386 binary. However if I apply the macports patches
> (plus my own) and then configure it to use /usr, so where the apple
> supplied libs are then it compiles without a problem.
>
> I have put the openssl mkmf.log files for both situations online:
> macports libs: http://superalloy.nl/misc_files/macports/ruby/mkmf-opt-local.log
> apple libs: http://superalloy.nl/misc_files/macports/ruby/mkmf-usr.log
>
> As you can see the differences start to occur from: "have_library:
> checking for SSL_library_init() in -lssl...". Which returns yes for
> /usr but no for /opt/local.
> Also it says this in the log for /opt/local:
> /usr/bin/ld: warning can't open dynamic library:
> /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libz.1.dylib referenced
> from: /opt/local/lib/libcrypto.dylib (checking for undefined symbols
> may be affected) (No such file or directory, errno = 2)
>
> Uhmmmm..... Is this why it fails to build?? I mean that path can't be
> correct can it?
> But that path doesn't really seem to be in there so I don't think
> that's the cause:
>
> $ strings /opt/local/lib/libcrypto.0.9.8.dylib | grep Developer
> cc -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer
> -fno-common -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386
>
> Could anybody offer any tips on where I should look???
> I'm so close, it's getting frustrating! hahahahaha ;)
>
> > The policy is that if you have changes you want made to a portfile,
> > you file a ticket in Trac and attach a diff and assign it to the
> > maintainer (if in the list) and Cc yourself and the maintainer. If
> > the maintainer does not react within 72 hours, then you can email the
> > list with the ticket number and request that someone else commit the
> > change.
>
> Okidoki.
>
> Cheers,
> Eloy
>