On Mon, 19 Jun 2006, Kevin Ollivier wrote:
Getting back to some PyLucene stuff, and I see on Mac 2.0 is still using
shared library builds. Were there problems with the static builds, or was
there another reason we still can't use them?
The tricks we used to get a static build of _PyLucene.so with libgcj.a to work
work only with gcj 3.4.x.
I tried to make it work with gcj 4.x but it seems to involve more than adding
a few more of the missing symbols that were needed to get it to work under
3.4.x. I've had no time to seriously look into it.
The shared bits that come with PyLucene take up quite a bit of space, and
significantly complicate the issue of making a Universal binary. If
everything were statically linked, we could pretty easily create a Universal
binary by running the following command after the intel and ppc builds
complete:
lipo -create /path/to/intel/_PyLucene.so /path/to/ppc/_PyLucene.so -output
/path/to/universal/_PyLucene.so
Creating a Universal Binary would require gcj 4.x since there is no gcj 3.4.x
on Intel Mac. I should add that gcj for Intel Mac OS X is itself sort of a
miracle at the moment thanks to Sandro Tolaini's patches to gcj 4.0.2
available at http://gcc.gnu.org/ml/java/2006-05/msg00151.html
This should be all that's needed for a Universal binary. It's not so easy,
however, with the shared libraries to worry about. It's possible we could
lipo the shared libraries together, but that will probably bloat the space
requirement for the PyLucene extension alone to around 50MB
While a universal binary is elegant it becomes a lot less so when you consider
the doubling of the size requirements.
Granted, for me it will only be useful for Tiger builds right now (due to
wxPython Universal issues), but it would still be very useful, and IMHO the
transition will need to happen eventually. I'd like to be able to think of
one day being able to only maintain one Mac binary for my software. ;-)
And I would *love* to be able to use the same version of gcj everywhere.
But that's proven a very elusive goal...
On Windows, I've been stuck with gcj 3.4.2 until I figure out how to build a
better one (I'm working on build a 4.0.2 gcj for windows). gcj on windows
needs a *lot* of work and is getting very little attention. Just building the
damn thing requires a PhD in gcc configure/makefile hackery.
On Ubuntu, gcj 4.1.1 seems to not work but gcj 4.1.0 works great on Mac OS X
(but I can only build it with darwinports). On Ubuntu, gcj 3.4.6 works great.
On ppc Mac, I've been using gcj 3.4.3 or gcj 3.4.5 for a long time and it's
worked well.
On intel Mac, thanks to Sandro Tolaini's patches, I'm now able to use gcj
4.0.2. Without his patches, where would be *no* gcj on intel os x for the
foreseeable future.
I'd go ahead and attempt this myself, but it sounds like the process to get
gcj working on Intel is pretty involved, and I was hoping it would be pretty
easy to do a static (and Universal) build on Mac if you've got everything
already setup on your end. Otherwise, it would be very helpful if you could
provide the complete GCJ build you used and spare me some pain. ;-)
The intel gcj binaries I produced are available as a download from
http://downloads.osafoundation.org/compilers/osx/i386 and compiling it
yourself is pretty easy with the patches I mentioned earlier applied to a
stock 4.0.2 gcc source tree.
But first, the static link problem needs to be solved for 4.x again.
The trick we used for 3.4.x is not good enough.
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
