micropython won't compile on OSX Mavericks

[lerouxb]

I have libffi installed via homebrew, but it keeps complaining about libffi not being found. I eventually fixed that with export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig.

Now it gets stuck when it tries to compile, probably because it is using clang and not gcc. I got the following error:

error: unknown warning option '-Werror=cpp' [-Werror,-Wunknown-warning-option]

I installed gcc with homebrew, but it is still using clang. I then commented the compiler option out in the makefile so that clang compiles and then I eventually ended up with:

ld: unknown option: -Map=micropython.map

And that's where I got stuck. I don't know how to solve that and I don't know how to force it to use gcc and not clang either. (assuming that that's probably part of the problem)

[dhylands]

The -Map option is being add in unix/Makefile here:
https://github.com/micropython/micropython/blob/master/unix/Makefile#L32

You could try changing:

LDFLAGS = $(LDFLAGS_MOD) -lm -Wl,-Map=$@.map,--cref $(LDFLAGS_EXTRA)

to read:

LDFLAGS = $(LDFLAGS_MOD) -lm -Wl,--cref $(LDFLAGS_EXTRA)

or even

LDFLAGS = $(LDFLAGS_MOD) -lm $(LDFLAGS_EXTRA)

The map and cref are really just convenience things.

[Anton-2]

As suggested by @dhylands, removing -Map=$@.map and --cref will allow you to compile.... But the resulting version is broken. Recent makefile changes didn't update the part clang needs to provide GC informations.

This makefile ( https://gist.github.com/Anton-2/66c327548f5179edd47f#file-micropython-clang-makefile ) should work.

If you want a map file, use clang syntax : -map,$@.map instead of -Map=$@.map

I'll do a proper PR once I've checked that all is well with the next version of clang.

[lerouxb]

Thanks, @Anton-2, but that gave me the same error I got after following the the advice given by @dhylands

$ make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
mkdir -p build/genhdr
CPP ../py/qstrdefs.h
../py/qstrdefs.h:31:4: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
Q(*)
  ~^
../py/qstrdefs.h:32:1: error: expected function body after function declarator
Q(__build_class__)
^
2 errors generated.
make: *** [build/genhdr/qstrdefs.generated.h] Error 1

[Anton-2]

Looks like you've got something mixed up in your environnement.

CPP ../py/qstrdefs.h should just pre-process this file, not compile it ( using gcc -E ). It is later used by a python program to generate a real header file.

Could you please run

make clean && make V=1 

so we can see what is really done ?

Also, make sure that no previous attempt to use the "real" gcc remains in your path. Micropython should compile fine with standard clang based system compiler on osx, with the makefile I gave you.

[lerouxb]

Aah. It must have been some environment variables and things from when I tried to make it use gcc. I opened up a new fresh terminal and it got past that.

Looks like that worked. Thanks!

[blmorris]

If anyone is trying to compile the unix port on OSX and is running into trouble, I just wanted to add a few details to this thread (running 10.7.5, but encountering some of the same issues.)
First, copy the makefile provided by @Anton-2 to unix/Makefile (rename the old one to Makefile.orig or something like that) - https://gist.github.com/Anton-2/66c327548f5179edd47f#file-micropython-clang-makefile

If you have a version of gcc installed in addition to clang, you may need to make the following change to py/mkenv.mk

##CC = $(CROSS_COMPILE)gcc
CC = $(CROSS_COMPILE)clang

This will break compilation for stmhal, so it needs to by changed back to compile for the pyboard.
Also, you will need an updated version of libffi. Using libffi @3.1_3+universal I got the following error message:

...
CC seg_helpers.c
LINK micropython
/bin/sh: libdir: command not found
ld: warning: directory not found for option '-L-lffi'
Undefined symbols for architecture x86_64:
  "_ffi_type_sint8", referenced from:
      _ffimod_func in modffi.o
      _mod_ffi_callback in modffi.o
      _get_ffi_type in modffi.o
...

Using macports I was able to update to libffi @3.1_4 which fixed the problem.

[p-i-]

I have just got MicroPython to compile on Mavericks.
Firstly, as per lerouxb's post: export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig
Then substituting ./unix/Makefile as per blmorris's post.
Finally executing make from the /unix folder builds it.
π

PS I don't know why I already have libffi. In fact sudo find / -iname 'libffi' reports a second one also (courtesy of homebrew)

[AWCharlie]

New to Macports and all this OSX. I don't even have /opt in /usr/local

I'm trying to figure out where to put libffi and how to get macports to put it there :-)

This is like starting with Linux all over again!

[toyg]

Ok, I got it to work. For reference, this is what you need on Mavericks (10.9.4) to get micropython to compile, assuming you have libffi installed (from macports or homebrew etc):

1. edit /unix/Makefile to change the following:
   LDFLAGS = $(LDFLAGS_MOD) -lm -Wl,-Map=$@.map,--cref $(LDFLAGS_EXTRA)
   to
   LDFLAGS = $(LDFLAGS_MOD) -lm -Wl,-map,$@.map $(LDFLAGS_EXTRA)
2. edit /py/mkenv.mk to change the following:
   CC = $(CROSS_COMPILE)gcc
   to
   CC = $(CROSS_COMPILE)clang This is not really required, unless you have a real gcc installed (by default, gcc is an alias to clang).
3. As @blmorris says, if your libffi comes from homebrew, you must run export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig
4. make

[blmorris]

@toyg - glad you got it working, I just posted something similar at #865 but with a different set of edits to /unix/Makefile. Your change eliminates the map file, as mentioned upthread by @Anton-2 (though I don't know enough to tell if it is really needed).

One note that I would add - your step 3
export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig
is only necessary if you installed libffi using Homebrew; under macports the install directory is /opt/local
The *.pc files are all located in /opt/local/lib/pkgconfig and as far as I can tell pkg-config finds them there without needing to manually set PKG_CONFIG_PATH. In fact, it seems to find the files even if PKG_CONFIG_PATH is pointing to a non-existent directory, as it was when I ran the same command.
-Bryan