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@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