Hi Justin,
On Jan 23, 3:55 am, "Justin C. Walker" <[EMAIL PROTECTED]> wrote: > On Jan 22, 2008, at 6:15 PM, mabshoff wrote: > > > On Jan 23, 2:59 am, "William Stein" <[EMAIL PROTECTED]> wrote: > >> On Jan 22, 2008 1:48 AM, boyfarrell <[EMAIL PROTECTED]> wrote: > [snip] > >> None of us know how to make one for a program as complicated as Sage > >> (i.e., a 5 million line program that combines together 70 separate > >> components). > > > We would need to modify the way packages are build by passing -arch > > flags to all of them, but that causes problems with libraries like gmp > > and code like python that use macros for endianess and so on. Apple > > has solved some problems like that for python for example, but there > > is a better way - see below. > > What are the problems that using "-arch" causes? I believe that the > endian macros and other related mechanisms will work correctly, as > long as you have the correct pieces installed. > > I have not tried to build "fat" on anything particularly complex, but > in principle, this will work because Apple has done it for all of > their software (except maybe the kernel; it is delivered 'fat', but I > don't know that it is built this way or the way you suggest below). I am fairly certain they build universal with -arch flags. The lipo approach seems like a rather low-tech workaround for Apple to use it, especially since the while -arch flag business comes from Apple themselves and isn't even in the main gcc 4.2 yet. > >>> Will universal binaries work, or is that just of Cocoa applications > > >> I think "in theory" one could make one that would work. In > >> practice it would > >> probably be very difficult and time consuming, and unfortunately > >> have nothing > >> to do with mathematics. If somebody wants to give it a shot though, > >> by all means they should. If I could change some flags and build > >> SAGE > >> in such a way that the binaries were universal but not much > >> bigger, I would > >> be happy to do so. > > > What can be done is the following: Build x86 and ppc independently on > > native systems. Then use lipo to combine all libraries and executables > > into universal binaries. > > This will certainly work. The only difference between this approach > and doing it on one system is that you have have the right SDKs > installed, and you have to modify the build procedure to build > "cross". This involves, in essence, the judicious use of "isysroot" > and "libsysroot' flags in the build flags. > > It may be simpler to build separately and lipo everything, even if > it's done on one system. > > Xcode documentation has a pretty good description of the process. Got any pointers? Too lazy to dig around ;) > > I have done this for CoCoA for example and it > > does work well. But I believe that the resulting binary would only > > produce single architecture extensions when using Cython due to the > > problems mentioned above. The size of the dmg would grow by the amount > > of executables & libraries. A potential issue could be the compiled > > python files. If anybody wants me to write that script let me know. I > > can probably be done in a couple hours ;) > > I think that the size issue may be a minor one, although I have not > checked the size of "binary" bits. I will do that shortly and see what happens with 2.10. But I will try a OSX 10.5 i386 with a 10.4 ppc. > Two points to clarify: > - is there any architecture-dependent "intermediate" code > that lives in a built "sage blob" (something analogous > to compiled elisp, for example)? Not sure, but nothing particular comes to mind. Famous last words, I am sure something will bite me in the ass shortly. > - are there build differences between Mac OS X on Intel > and on PowerPC (as encoded in spkg-install scripts)? As far as I can think of not. I am currently modifying spkgs to build 64 bit build of Sage on OSX and the normal fix is to pass proper [C| CXX|CPP|LD]FLAGS, so passing -arch x86 x86-64 ppc ppc64 might be an option. Note that I tried that with python 2.5.1. and it doesn't work there and while there are various workarounds posted to get this to work they all fail. But Apple ships a universal python, so we might either default to use that on OSX or somebody needs to go off and figure out what they did. In case anybody does: the posix-element.c workaround we use in our python spkg breaks on 64 bit OSX on 10.5, but the fix isn't too hard. Other issues include disutils for Python, i.e. numpy fails to build currently because it seems to miss #ifdefs in a crucial point. > - can the 'autoconf' scheme work in the cross-development > environment provided by Xcode? I don't know if that is relevant since we don't use it and you can make Xcode execute some custom build script. Am I misunderstanding you somehow? > (ok - three points). > > The 'autoconf' issue may be the most serious. > Justin Yep, I think the biggie is gmp. I discussed this with various people on the mpfr mailing list about a months ago and the consensus was the in the current form you cannot build gmp with the arch flags since gmp.h has hard coded values dependent on word size and so on. The solution for that was to create a dummy gmp.h that conditionally includes a x86-64/x86/ppc/ppc64 gmp.h. This is a workaround also employed by Red Hat for example on Linux boxen with mixed 32/64 bit userspace. I doubt something like this would go upstream in gmp any time soon, but more about this at some later point. But in the end it boils down to this: Do people want universal binaries, considering the size tradoff? I do think so, but I hope this isn't like the live-CD where everybody says that it is a good idea but when push comes to shove few people step up and use it. > -- > Justin C. Walker, Curmudgeon-At-Large > Institute for the Absorption of Federal Funds Cheers, Michael > -------- > If you're not confused, > You're not paying attention > -------- --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
