The following comments are owned by whomever posted them. This site is not responsible for what they say.
IRAF on Intel Macs -- First Results
Authored by: sirmarcos on Thursday, January 26 2006 @ 11:57 PM GMT
Well, that's exciting. Rosetta appears to be doing a decent job. That explains the big memory usage of course. I assume X11 comes with on the intel MacOS x 10.4.4 discs and can be installed, as well as the x11 dev tool kit needed to compile things.
other than IRAF, IDL and fink, every other program I used today already has a universal binary. Those are rather key programs to getting work done, of course, but still. The intel transition seems to be less rocky than the 68k to ppc transition. All because Apple controls the developer tools, I think.
Authored by: sirmarcos on Saturday, February 18 2006 @ 03:30 AM GMT
hey, those are pretty good numbers from the intel build. I wonder how many external packages will need to be patched to build on intel...or do they use enough IRAF source that they'll build inside the cl running on a native intel-mac iraf port...
Anyway, the speed looks good. must be the improved integer performance on the Core Duo relative to the PPC?
Authored by: fitz on Saturday, February 18 2006 @ 04:11 AM GMT
I wonder how many external packages will need to be patched to
build on intel...or do they use enough IRAF source that they'll build inside
the cl running on a native intel-mac iraf port...
It won't be too bad: Some of the recent GCC build issues have
already been addressed in the port and there's nothing new in the Intel
OS X that isn't already a problem under ppc OS X. The release will have
binaries for both macosx/macintel (might as well update both) and I think
it should be possible to allow for cross-compilation, i.e. even if you don't
have an Intel Mac a developer should be able to compile binaries on their
ppc system so they can distribute binaries for their package. In theory the
same should be do-able for the various linux flavors but I'm not up to
dealing with the linux ports at the moment.
Authored by: sirmarcos on Monday, February 20 2006 @ 11:34 PM GMT
Well, that's cool. Until today, I hadn't figured out how to make
an intel binary from the command line with the latest OS X dev tools.
I could do it in Xcode, both with my IRAF Button program, and with
some command line c programs I've written... but I didn't know
what I needed to put in the makeflie
I need to do to the makefile to make it happen without the Xcode
IDE... the -arch flag never seems to work.
After googling today, though I came across this page
Authored by: fitz on Tuesday, February 21 2006 @ 07:10 PM GMT
For a simple hello.c the multiple -arch flags are all that's needed for a universal binary. Specifying '-arch i386' on a G4/5 will compile a native intel binary and it's this trick I was referring to in cross-compiling iraf packages i.e. simply set IRAFARCH to 'macintel' and let the system worry about setting the flags to produce intel binaries, all you need is to have the intel iraf libs installed. So, developers could install both archs but users still only need one.
The size of universal binaries is not a minor issue for IRAF: a typical IRAF+STSDAS+TABLES system would run 1GB, most of it wasted space. A UniBin XGterm might make be okay, but we've already got the concept of architectures in IRAF and most people will only want one or the other binary anyway.
The following comments are owned by whomever posted them. This site is not responsible for what they say.
explains the big memory usage of course. I assume X11 comes with
on the intel MacOS x 10.4.4 discs and can be installed, as well as the
x11 dev tool kit needed to compile things.
other than IRAF, IDL and fink, every other program I used today
already has a universal binary. Those are rather key programs to
getting work done, of course, but still. The intel transition seems to be
less rocky than the 68k to ppc transition. All because Apple controls the
developer tools, I think.
many external packages will need to be patched to build on intel...or do
they use enough IRAF source that they'll build inside the cl running on
a native intel-mac iraf port...
Anyway, the speed looks good. must be the improved integer
performance on the Core Duo relative to the PPC?
I wonder how many external packages will need to be patched to build on intel...or do they use enough IRAF source that they'll build inside the cl running on a native intel-mac iraf port...
It won't be too bad: Some of the recent GCC build issues have already been addressed in the port and there's nothing new in the Intel OS X that isn't already a problem under ppc OS X. The release will have binaries for both macosx/macintel (might as well update both) and I think it should be possible to allow for cross-compilation, i.e. even if you don't have an Intel Mac a developer should be able to compile binaries on their ppc system so they can distribute binaries for their package. In theory the same should be do-able for the various linux flavors but I'm not up to dealing with the linux ports at the moment.
Well, that's cool. Until today, I hadn't figured out how to make an intel binary from the command line with the latest OS X dev tools. I could do it in Xcode, both with my IRAF Button program, and with some command line c programs I've written... but I didn't know what I needed to put in the makeflie I need to do to the makefile to make it happen without the Xcode IDE... the -arch flag never seems to work.
After googling today, though I came across this page
http://developer.apple.com/documentation/Porting/ Conceptual/ PortingUnix/compiling/chapter_4_section_3.html
So my (very simple) makefile now looks like:
Walla, the Finder says it's a "universal unix executable" and it's about twice the size of the PPC only one.
So it might be possible to make "universal" binaries of IRAF, if this trick can work on a larger scale. THough that'd be twice as big a download.
The size of universal binaries is not a minor issue for IRAF: a typical IRAF+STSDAS+TABLES system would run 1GB, most of it wasted space. A UniBin XGterm might make be okay, but we've already got the concept of architectures in IRAF and most people will only want one or the other binary anyway.