Op donderdag 18-06-2009 om 12:43 uur [tijdzone +0100], schreef Richard W.M. Jones:
does cctools now have real 64 bit support (ie. are they trying to make the code 64 bit clean -- previously we had to compile the whole thing with -m32)?
x86_64 support is one of the major features in the latest Mac OS X (Snow Leopard) so I guess things have improved in that area. However, when trying to build the odcctools on my x86_64 laptop a compile error occurred. Help is appreciated to get the odcctools operational for x86_64 Linux hosts. Support for x86_64 targets should be the next step.
- Support for fat/universal binaries This requires multiple GCC compilers which are tied together by a small wrapper. This wrapper (which is called /usr/bin/gcc on regular Mac OS X environments) accepts arguments like '-arch i386 -arch ppc' and calls the corresponding compilers and uses lipo to merge the results together
What do we lose if we just build everything for, say, i386? PPC Macs are a bit long in the tooth now aren't they?
Support for ppc environments could be dropped as only Intel-based Macintosh'es were fabricated and sold in the last few years. However, fat/universal binaries are still used nowadays containing i386 and x86_64 binaries. I think we should aim for those two targets.
- Can we regenerate the .dylib files which are bundled with the SDK from source code (which is a requirement for Fedora) so that we get something like w32api?
My thought for this one is can we rebuild these files just from a table of the exported symbols? (ie. nm *.dylib)
Would that be legal enough? I've heard rumors on several places that such acts are considered 'reverse engineering' which isn't allowed/questionable. The only way to create something like this in a fully legal way would be by using the public Apple documentation.
- End user installers We need something like nsiswrapper for Mac OS X environments. On Mac OS X environments, all applications are bundled in one directory, a so called '.app'. This directory contains some standard files (containing application information, an icon, etc) and of course the application itself along with it's dependencies and data files. These .app folders can be packed in a .zip file or a .dmg file which end-users can open directly to run/install the application
Doesn't odcctools provide something to do this?
Not that I'm aware of. The odcctools only provide a set of tools which offer the same kind of functionality as with binutils for Linux environments (linker, assembler, etc).
Regards,
Erik van Pienbroek