Since Apple have stopped distributing gfortran with Xcode, how should I compile architecture independent Fortran code? I have Mac OS X Mountain Lion (10.8), and XCode 4.4 installed, with the Command Line Tools package installed.
Apple's Native Compilers
As far as I can tell, the Xcode C / C++ / ObjC compilers use a fork of the GNU compiler collection, with llvm as a backend; the latter I figure enables compiling and optimising "universal" binaries, for both Intel and PPC architectures.
3rd party binary Fortran compilers
HPC
I've only found a single website that distributes a binary version of gfortran specifically for Mountain Lion: the HPC website. However, I failed to get this to compile SciPy, and later saw in SciPy's README that it is "known to generate buggy scipy binaries".
CRAN/R
SciPy's recommended (free) Fortran compiler is the one on CRAN's R server, but this has not been updated for Mountain Lion yet. They provide instructions and a script for Building a Universal Compiler, but, again, this hasn't been updated for Mountain Lion yet..
G95
The G95 project hasn't had an update since 2010, so I didn't try it.. Anyone tried this on Mountain Lion?
MacPorts
I guess this will be the easiest way to get gfortran installed, but port search gfortran comes up with nothing, and I've not had any joy with MacPorts in the past (no offence to MacPorts; it's looks like a very active project, but I've been spoilt with Linux package managers, my favourite manager being aptitude) so on Mac OS X I've compiled software and libraries from source code in the past. Never been a problem 'til now...
Building a Fortran compiler
Having dug around on the internet a lot in the last couple of days, I've found other Fortran compilers, but I've failed to get any to cross-compile universal binaries, or to compile SciPy.
GCC - The Gnu Compiler Collection
I compiled the entire GCC collection (v4.6.3), including autotools, automake, libtool and m4 - like the GCC wiki and this blog describe - but the resulting compilers didn't compile universal binaries, probably because LLVM wasn't used as a backend.
DragonEgg
DragonEgg is a "gcc plugin that replaces GCC's optimisers and code-generators ... with LLVM". This looks interesting, but I don't know how I could use it to compile 'llvm-gfortran-4.x'. Can this be done?
Compatibility
Libraries
The compiler that comes with Xcode is (a fork of?) GCC v4.2. But GCC's current release and development branches are versions 4.6 and 4.7, respectively. Apparently, a GNU license change, or something, stopped Apple from updating to more modern versions of GCC. So, if I was to build dynamic libraries made with GCC's gfortran v4.6, could they then be linked with C code compiled by Xcode's native compiler? At a minimum, I figure resulting Mach-O binaries need both x86_64 and i386 code paths. Do GCC provide backwards compatibility with Apple's (forks of?) GCC? I know gfortran has the -ff2c flag, but is this stable across versions?
Compile flags
The GCC Fortran compiler I built from source didn't support the use of the -arch compile flag. I had been including the flags -arch x86_64 -arch i386 in both CFLAGS and FFLAGS environment variables on earlier OSX versions (Snow Leopard to Lion). Python's distutils, and probably other OSX compilers, expect these flags to work, when configured to build apps or frameworks, using Xcode's universal SDK.
In case you're wondering what compile flags I use, I've uploaded the script I use to pastebin, which I source before I compile anything, using: source ~/.bash_devenv.
The Ideal OSX Fortran Compiler
Create ppc and intel (32 and 64bit) universal binaries, specified by using the -arch flags.
Makes binaries compatible with XCode's linker.
Compiles SciPy, giving no errors (compatible with numpy's distutils and f2py).
I don't use Xcode so much, but integration with it would surely benefit other users. Even Intel are still having problems integrating ifort into Xcode 4.4, so this is not something I expect to work..
If you read all the above, then thank you! You can probably tell that I'm not averse to building my own Fortran compiler from source, but is it even possible? Have I missed something? A configure flag maybe? And if such a compiler is not available yet, then why not?!
(Update:) Apple's GCC
Apple provide the source code for their patched version of GCC, at opensource.apple.com. This actually includes the source code for gfortran, but what do you know - it doesn't compile (easily). I'm in the process of writing a build script to get this to work. Unfortunately, I've had to apply a couple of patches, and learn about "the Apple way" of building GNU software. This is the way to go I think. Any reasons why it shouldn't be? I'll update with an answer if I get it to work...
I managed to compile after installing gfortran from http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg, as explained here. I had to try to open the package a couple of times, though. First time it said that only apps from App Store can be installed. After installing gfortran, python setup.py build and python setup.py install worked fine. The unit tests of scipy though give a fairly high number of fails, not sure it's normal.
Ran 5481 tests in 82.079s
FAILED (KNOWNFAIL=13, SKIP=42, errors=11, failures=72)
<nose.result.TextTestResult run=5481 errors=11 failures=72>
In case you didn't already notice this: In newer versions of Xcode you have to explicitly install command line tools in the following way:
Preferences -> Downloads -> Components
And then click the "install" button for command line tools. This includes gfortran:
> gfortran -v
Using built-in specs.
Target: i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)
Admittedly, this does not solve all of my fortran needs (in some cases "./configure" scripts will complain that they cannot "compile a simple fotran program").
You could use brew (or Homebrew) to install gfortran.
$ brew install gfortran
I know you said you don't like MacPorts, but if you install the gcc48 port, it does in fact include gfortran (although you'll also have to do sudo port select --set gcc mp-gcc48 to get it to set up the symlink named gfortran).
Also, FWIW, the MacPorts option is not necessarily a binary - MacPorts can actually build it from source, which is why it sometimes takes a while. On the other hand, it also sometimes seems to get archived binaries from somewhere, but I think it depends on what the original author of the portfile uploaded.
I ended up compiling gfortran the source code provided at Apple's developer tools source code page. This seems to be working okay now - I've successfully compiled x86-64 and i386/i686 LAPACK, ATLAS and BLAS fortran libraries - but there are some ranlib tests which fail, when running make -k test in the build directories. (I could provide more info on that pastebin or somewhere, if someone wants...)
Build process
After asking the question, I downloaded Apple's llvmgcc42 source code tar archive, which includes the source code for llvm/gcc C, C++, ObjC and fortran compilers, and spent some time trying to compile a universal build of gfortran. The build takes about 30-60 minutes on my quad-core 2.8GHz Mac Pro, and became quite an involved process, so I wrote a set of build scripts for it, which I've shared at github.com.
....
I'll keep a tar archive of my build here for the time being, if anyone would like a copy. (Updated 26-Sep-2012) It'll only work if installed with a prefix of /usr/local/ though, unless you run install_name_tool on the executables and dylibs, to change the prefix from /usr/local to wherever you want to put it. You can test install_name's with otool -L filename (more info on the reasons for this is here).
The final build I'm now using also includes updates to the gcc/fortran and libgfortran directories, which I got from GNU GCC 4.2.4. These sources I got from my local GCC's mirror. There were only minor changes between 4.2.1 and 4.2.4, and the build scripts include the patches needed to upgrade the code.
The build-gfortran.sh script I wrote downloads missing dependencies (mpfr and gmp), compiles and cross-compiles them, patches differing headers with architecture-dependent preprocessor macros, and runs lipo to create universal binaries and libraries, eventually supporting both i386 and x86_64 architectures. The process is similar for llvmCore, and then GCC. I mostly copied code from the build_llvm and build_gcc bash scripts provided with Apple's llvmgcc42, but had some of it had to be modified, including a few lipo and install_name_tool commands.
The official way to compile Apple's gcc, using Xcode's gnumake just didn't work for me. I thought this should work just byadding "fortran" to the LANGUAGES variable in build_gcc.
With regards to compiling Scipy, still can't get that building perfectly. I've had to use clang and clang++ as C/C++ compilers, or else I get EXC_BAD_ACCESS malloc errors. Haven't tried the gcc/g++ compilers I built, just used the system ones. This is as reported for Lion, on the Scipy install page. I'm down to 11 errors and 1 failure, which are all raised from the same 3 function calls (_fitpack._bspleval, numeric.asarray, testing.utils.chk_same_position). Think that's pretty good, but I'd like every test to pass...
Related
I have some troubles in making a FFTW (and FFTW++) static project in Eclipse in my MacOS Lion. Have someone already made it?
I've made a separate folder for the include files, but it seems like it can't find them despite I have set the path correctly. I've also replaced in all the c-files the includes with the path <subdirectory/include_file> setting in the Directories section of my project settings
${workspace_loc:/FFTW3/include}.
I don't know if it's relevant but as I wrote my code, using another IDE and typing the commands from bash, I realized that some mp options were needed, so I've updated my version of gcc from 4.2.1 (that is the basic Xcode version for MacOS) to 4.7. I've compiled the FFTW++ example and it worked, compiling it with g++ -fopenmp. I have used macports to install the new version of gcc and I have used one of its options (sudo port select --set gcc mp-gcc47) to set it as gcc default command, in place of the 4.2 version, so I can type and compile from bash.
Now I have seen that Eclipse uses the version 4.2.1. Does somebody know how to change it into the 4.7 version? Do you think that this could solve the problem or it's a cause for my problem?
I am trying to install ruby version manager on a g4 ibook running 10.4 but I receive two error messages right off the bat when I try to run the first command:
$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
bash: line 6: set: errtrace: invalid option name
bash: line 13: conditional binary operator expected
I am new to ruby, rails, and fairly inexperienced with the command line too. I've done a bit of searching and have seen other people having problems installing a specific version of ruby on a powerpc using rvm, but no other examples of someone having a problem installing rvm first of all.
Does this seem like a powerpc issue? Or is there something simple with the command line that I am missing here?
I have also searched on these specific error messages but haven't found any solutions yet. Oh and I should also add that I have xcode installed and I also installed macports because I thought that might help...but it hasn't.
The most probable cause of the error you're getting is your bash version is far too old to be used with any relatively new RVM version. Also, the likelihood of you being able to easily compile rubies on a G4 now is very low. You'll likely end up needing to compile many tools and libraries from source which you'll have to do from the command-line. Finding the right combination of library versions that both support your arch and are still available for download might not be as easy as it sounds. Much of the ruby compilation on OS X depends on libraries that come with Xcode. So, you might hit a wall there too with rubies now requiring newer libraries that can be provided with a version of Xcode that can be installed on your system.
You can try upgrading your bash version and/or use a much older version of RVM, although, I don't remember RVM ever working on 10.4. Or, you can try to compile everything from source, including Ruby. You'll might be able to get Ruby 1.8.6, maybe 1.8.7 working but anything higher is very unlikely.
Good luck =/
May I know if I can cross compile the Solaris x86 library from Solaris sparc server?
The source code is mainly in C++ (some C). I need to use the Solaris C++ compiler CC to compile. I understand that some compile or link flags are different between sparc and x86. I have done a check to make sure that the flags I used are common.
Is it possible to simply copy the library compiled in sparc to x86? Or I need to apply specific flag during compiling and linking?
Thanks,
The Sun/Oracle Studio C++ compilers do not support cross-compilation. You would need to use another compiler that does, like a specially built gcc.
Simply copying the library can't work - SPARC and x86 are very different instruction sets, with no binary compatibility between the two.
Even if you could cross compile the Solaris libraries on SPARC for x86, it would seem a lot simpler to just install the x86 compilers and libraries. The interdependencies of these libraries is probably so complex that such a project would probably not work.
What's preventing you from just downloading and installing the Studio software on x86 Solaris?
Oracle Sun Studio C++ compiler (CC) has --xarch option with big variety of architectures. There are: sparc, amd64, pentium_pro and various extensions/modifications. This flag should be provided for both compiler and linker if you compile and link in separate steps.
You can verify target architecture with file command; e.g:
bash-3.2$ file /usr/bin/CC
/usr/bin/CC: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped
Please, refer to CC manual for details:
Sun Studio 11 C++ Man Page
Can anyone recommend either:
an ARM disassembler that runs in either Windows or MacOS and which can ideally understand the executable format used by iOS
within MacOS, a way to call the cross-compiling GCC installed by XCode directly from the command line (so that I can run it on a small test file and ask for assembly output).
Basically, I'm interested in seeing how certain things get compiled for ARM/iOS by XCode/gcc to help me with optimisation. As you can see, although I have both a Windows and Linux background, I'm not fundamentally a Mac specialist so I'm not too familiar with e.g. where XCode intsalls all its gubbinry or the ins and outs of whatever binary format iOS uses.
I don't particularly care whether I have to do the "disassembly" under Mac OS or Windows, but what I was trying to avoid is installing a brand new copy of GCC configured to cross-compile to ARM, as XCode presumably has a perfectly good installation already sitting there somewhere... Any help appreciated.
You can always use otool disassembler. It's rather basic but does the job.
IDA Pro can disassemble ARM Mach-O files used in iOS. Using it is (in my biased opinion) much better experience that looking at the dead listing. You can check how it works with the demo version.
Disclaimer: I work for Hex-Rays.
an ARM disassembler that runs in either Windows or MacOS and which can ideally understand the executable format used by iOS
I can suggest you a LLVM. If it is built with default options, llvm-objdump will disassemble ARM.
Also, looks like http://developer.apple.com/technologies/tools/whats-new.html Apple is using LLVM toolchain in iOS SDK.
There is already an ARM cross compile toolchain built into Xcode. You can debug your iOS applications at the source and ASM level with the gdb debugger support already built into Xcode. For example, open your iOS app and select Device and Debug. Then set a breakpoint at a source line and run your program until the breakpoint is hit. Now select "Run -> Debugger" from the menu. When the debugger is showing, select "Run -> Debugger Display -> Source and Disassembly" and you will see a window on the right side that shows the ARM asm code that was generated from your source code. You can step through the code a source line at a time using the buttons. If you want to step one ARM asm instruction at a time, open up the gdb console and use the "stepi" instruction (type it once, then just hit enter to repeat).
Take a look at Hopper. It's darn cheap compared to IDA (though not as powerful) and the recent versions can handle ARM.
Within MacOS, a way to call the cross-compiling GCC installed by XCode directly from the command line (so that I can run it on a small test file and ask for assembly output).
Use this script for a gcc that compiles for iphone:
#!/bin/bash
# Note: The "/Applications/Xcode.app/Contents" prefix is only required on 10.7.2 and
# later (where Xcode is installed through app store rather than as a package).
# If running 10.6 or earlier, cut out that prefix.
PLATFORM=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
# Change this to the iOS version you want to compile for (you must have the platform
# SDK installed in Xcode)
VER=6.1
$PLATFORM/Developer/usr/bin/gcc -arch armv7 -framework IOKit -framework CoreFoundation -F $PLATFORM/Developer/SDKs/ iPhoneOS$VER.sdk/System/Library/Frameworks -I $PLATFORM/DeviceSupport/Latest/Symbols/usr/include -L $PLATFORM/Developer/SDKs/iPhoneOS$VER.sdk/usr/lib -L $PLATFORM/Developer/SDKs/iPhoneOS$VER.sdk/usr/lib/system $*
Source: newosxbook.com
Take a look at Radare2 it is an open Source tool that is rising it's Feature-Set constantly and already supports ARM disassembling.
I want to create 64 bit apps for (for example) 64 bit Windows 7. I've searched the web and found some help but couldn't get it to work.
Sorry I've taken so long to respond but I have tried to get the packages suggested to work but they're not easy or else I'm doing something wrong.
Anyway I ran across an environment called pellesc. It consists of a development environment around a compiler which traces is roots back to a 32-bit version that was once (according to Wikipedia) used to develop Quake. From what I've seen so far it's very promising and generates good code too!
In spite of what other people are saying, Eclipse actually has very good support for C++, even in Windows: check out the CDT project. It's very mature and well-supported -- it works for C/C++ at least as well as Eclipse JDT works for Java.
As for the compiler itself, VonC is right, MinGW-w64 (but the mingw-w64 project is moving to mingw-w64.org so i suggest to use mingw-w64.org) is the best option. Eclipse CDT has built-in support for MinGW so as long as you install MinGW first, Eclipse should automatically detect it.
This Eclipse MinGW64 tutorial mentions:
update (Nov 9, 2010): recent MinGW-w64 versions come with 'as', 'g++', and 'gcc' commands. This step may be unnecessary in your MinGW build.
Meaning you won't have anymore to update the GCC assembler, C++ compiler, C compiler and C++ linker, with 'x86_64-w64-mingw32-as', 'x86_64-w64-mingw32-g++', 'x86_64-w64-mingw32-gcc', and 'x86_64-w64-mingw32-g++'.
Other great source for w64 development tools:
Native windows x64 software develop with Mingw-w64 on drangon.org
A 64-bit version of GCC for Windows is available at http://tdm-gcc.tdragon.net/download. I can't see why you would want to use Eclipse for C or C++ programming - try the Code::Blocks IDE at http://www.codeblocks.org instead.
Honestly, I use cygwin. Its compatable with unix so you can easily move systems and has tons of functionality that is gcc friendly (autoconf, make, makedepends, ...). To use gcc to compile to 64 bit add the -m64 option. To compile for windows use the -mno-cygwin option. Make sure though that you're using gcc 3 and not 4 (then you'd use the mingw compiler series). Otherwise, its all the same as unix which is really useful.