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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
