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).

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

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

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)?
  - are there build differences between Mac OS X on Intel
    and on PowerPC (as encoded in spkg-install scripts)?
  - can the 'autoconf' scheme work in the cross-development
    environment provided by Xcode?
(ok - three points).

The 'autoconf' issue may be the most serious.
Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to