Learning About Arduino on OS X 10.2
: Description : This page documents my process to get the Arduino IDE and tools running on Mac OS 10.2.8 successfully.
: Status : Research (Success with AVR-GCC 3.4.6!) (Abandoned 4.X; Compiled 3.4.6—successfully compiled, uploaded and tested sketch from IDE)
As shipped in version 0010, the Arduino IDE and tools do not run successfully on Mac OS X 10.2 in my experience. The Arduino IDE opens successfully but then complains in the "console" about a missing dylib file(s) when trying to use avr-g++ command.
It is possible to get Arduino 0010 running on Mac OS X 10.2.8 and edit, build and upload sketches from the IDE.
I mostly followed the instructions at http://www.nongnu.org/avr-libc/user-manual/install_tools.html, patched the gcc 3.4.6 source for new devices and built binutils, avr-gcc and used the IDE and avrdude as supplied with Arduino 0010.
I've uploaded a binary, but haven't tested it on another Mac OS 10.2 machine, I'd be interested to hear if it works for you: Arduino 0010 binary for Mac OS X 10.2 (Includes Arduino IDE, avr-gcc 3.4.6 and avrdude.)
Check out the stripes:
Note: This documents the complete trial and error process I used to gain success—it's not a step-by-step list of instructions.
- I had tried 'sudo ln -s /sw/lib/libiconv.2.dylib /usr/lib/libiconv.2.dylib' as it seems I had a version from fink which seemed to stop the message.
- But then I got messages about 'libmx.A.dylib' being missing:
dyld: ./avr-g++ can't open library: /usr/lib/libmx.A.dylib (No such file or directory, errno = 2)
- According to "stuff i found on the internet" the issue is that the version of avr-g++ included with Arduino has been compiled with gcc 4.0+ and this does not output files compatible with Mac OS X 10.2 due to missing library dependencies.
- This may not have always been the case: "On Mac OS X, install Apple's Developer Tools. Should work with everything from the December 2002 Tools for Jaguar on OS X 10.2, up through the more recent Xcode stuff."
- The tools-ppc.zip file in the repository does not appear to include source, it only contains binaries.
- This suggests the problem might be solved by compiling the avr-g++ source with gcc 3.x:
> I have recently re-compiled my PDE as a Universal Binary and it works well in most settings; however, I have just found out that it will not run on 10.2.8. > The Console log shows that the '/usr/lib/libmx.A.dylib' does not exist. > I have found some threads on the Xcode Users list that explain that targets built with GCC 4 will not run on Mac OS 10.2... is this true? Yes, C++ code compiled with gcc 4 requires 10.3.9 or later. C and Obj-C code should be okay. > (http://lists.apple.com/archives/Xcode-users/2005/Apr/msg00376.html) > According to the 'Universal Binary Programming Guidelines' Xcode uses GCC 4.0 for targeting Intel-based Macs. > > Is it possible to build a Universal Binary PDE that will run on 10.2, 10.3, 10.4, and Intel? Yes, you just have to use gcc 3 for the PowerPC build.
- Of course, if the code isn't compatible with gcc 3.x it could also just be a complete waste of time trying to do this.
- Follow http://www.nongnu.org/avr-libc/user-manual/install_tools.html (I used a non-root install location.) (For building binutils
use 'make install' first or ignore the error about the info files when using 'make' on it's ownyou'll need to build texinfo. You'll need to 'chmod u+x build-aux/install-sh' or you'll get a permissions error. (Or who knows, it complains about a missing makeinfo for me...--I changed the line with 'makeinfo=.....missing' to 'makeinfo=makeinfo'. <=== This made it work, so maybe you don't need to make makeinfo afterall if you've got makeinfo installed somewhere.))
- But it seems gcc 4.x ain't going to compile (I hit this error also (in 'libcpp' ?)): Problem building gcc42 on 10.3.9. ( DONE: Abandon avr-gcc 4.x and try avr-gcc 3.x instead? Will this compile Arduino-generated code? (Update: Seems like, yes, apparently Gentoo at least only ships avr-gcc 3.4.6))
- gcc-3.4.6 compiles and installs "out of the box" with the above version of binutils. Still need to test.
- Need to rename the directory 'arduino-0010/hardware/tools/avr' (e.g. 'avr.orig'). Then symlink the one we just built ('~/local/avr'). 'ln -s <dir>/local/avr'
- Complains about atmega168. atmega8 starts compiling. (DONE: Do we need a patch to gcc to use atmega168? (Update: Yes.))
- Complains about stuff in EEPROM, and other libraries—this means we need to build avrlibc i believe.
- 'bunzip2 -c avr-libc-1.4.7.tar.bz2 | tar xf -' avr-libc-1.4.7.tar.bz2
- Building and installing avr-libc appears to work. Blink sketch for Atmega8 seems to compile successfully in IDE. (Untested on device).
- We need the following patches to get atmega168: gcc-3.4.6 new devices patch (I had no problems building binutils 2.18 but if you use an older version you might also need to patch binutils.
- 'cd gcc-3.4.6; patch -p0 < ../patch-related/patch-newdevices'
- You'll need to rebuild avr-libc after you patch & build gcc if you do it in the order I did.
- Arggh! I've gotten a successful compile from the IDE! (After spending ages trying to track down a really annoying issue.)
- So, the issue was that trying to compile (in the IDE or from the command line) produced this error: (I also edited the preferences file '~/Library/Arduino/preferences.txt' to set 'build.verbose=true' so I could see how the successful atmega8 build process worked.)
avr/bin/ld: crtm168.o: No such file: No such file or directory
- The error occurred even after I had rebuilt avr-libc to ensure the file existed. And it did exist. I eventually realised that the error never occurred for the atmega8, but did for the atmega168 and any of the "new devices" I tried.
- I ran gcc with the "-v" flag to see what was happening and noticed this:
# Linker command generated for Atmega168 ...avr/bin/ld -m avr5 -Tdata 0x800100 -o /tmp/build27572.tmp/Blink.elf crtm168.o ... # Linker command generated for Atmega8 ...avr/bin/ld -m avr4 -o /tmp/build27572.tmp/Blink.elf /<full path>/avr/lib/avr4/crtm8.o ...
- Note that in the above command the 'crtm' file for the Atmega8 has a full path, while the one for the Atmega168 doesn't—this means it couldn't be found when it was search for. Note that using '-L' doesn't change this.
- When I tried to run the linker command manually with the full path for crtm168.o it was successful. If I specified the (full) library path to avr-gcc with "-B" it was also successful.
- Eventually I decided the key file affecting this was "local/avr/lib/gcc/avr/3.4.6/specs"-- gcc specs file format described. I eventually realised the new devices patch touched "MULTILIB_MATCHES" in "gcc-3.4.6/gcc/config/avr/t-avr" but this didn't seem to be reflected in the "*multilib_matches:" line in the spec file.
- By inserting "mmcu=avr5;mmcu=atmega168" into the "*multilib_matches:" list I was then able to successfully compile both from the command line and the IDE. I have yet to test the generated HEX file tho.
- My current supposition is that you have to re-run "./configure ..." before re-building gcc if you've already built it. (Unconfirmed.)
- It seems like I may not have been the only person with this issue:
I'm getting this weird error when I try to compile something with avr-gcc. /usr/lib/gcc/avr/4.1.2/../../../../avr/bin/ld: crtm168.o: No such file: No such file or directory Cerin, I suggest visiting the support channels for this "avr-gcc" I think that's self-explanatory, eitherway. No such file or directory :o It's more of a general make/compile question. you'd think, but it's not Cerin, no, it looks like a broken linker. I'm using -L/usr/local/avr/lib/avr5 when I compile, which is where that .o file exists. Guh anyone??? That's how you specify library paths right? With the -L flag?
- You might want to look at the build script 'buildavr.sh' from AVR GNU development tools under Linux--although if you do you'll need more recent new device patches than provided there.
- HARDWARE: At this stage I installed the FTDI USB-to-Serial driver from the FTDIUSBSerialDriver_v2_1_7.dmg disk image. It installed fine and I rebooted. But when I plugged in the Arduino after the reboot I got the oddest error message I recall seeing on Mac OS X:
The program you are using needs to use a system file that may reduce the security of your computer. The file 'FTDIUSBSerialDriver.kext' has problems that may reduce the security of your computer. You should contact the manufacturer of the product you are using for a new version. If you are sure the file is OK, you can allow the application to use it, or fix it and then use it. If you click Don't Use, any other files that depend on this file will not be used.
- Here is an image of a similar dialog (for a different kernel extension):
- The dialog displays three buttons "Fix and Use", "Use" and "Don't Use". Wow, nice error message Apple developers! :-P The link referenced by the quote is Apple's explanation--essentially the kernal extension or some part of it has file permissions errors that mean non-root users could modify the extension. Clicking "Use" seems to allow the extension to load and the /dev/tty.usbserial.-XXXX file was created. Using the IDE to attempt to upload a sketch seems to reset the Arduino succesfully but the upload failed because avrdude wasn't found (unsuprisingly as I haven't built avrdude or moved it back from the original tools directory). Apparently choosing "Use" will cause the dialog to appear after each reboot. When I tried "Fix and Use" it wanted permission to change the loginwindow application so I haven't done that yet (Update: After a reboot I chose "Fix and Use" and it didn't ask for any permissions, odd. A reboot showed the fix seems to be permanent.). Related links: link, link, link, link
- IT WORKS!!! Arduino 0010 CAN run on Mac OS X 10.2!! (At least, specifically 10.2.8). avrdude didn't even require a rebuild—the version shipped with 0010 and its config file only needed to be copied over:
cp -R avr.orig/etc avr/ cp avr.orig/bin/avrdude avr/bin/
- I successfully compiled and uploaded the original, and a modified version of the blink sketch and received serial communication from it.
- Another possible issue: libgcc_s.1.dylib