RubyCocoa 0.11.1

[Eloy Duran]

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