Mac Lion dependencies #865

AWCharlie · 2014-09-19T18:35:18Z

I'm using Lion (Target is OSX first, then the uPython boads then Discovery Boards - I have done it all on Debian before.) and am missing something in setting up to compile micropython. Apple says Xcode for Lion includes the tools. Others say install with xcode-select --install which just says --install is not a valid option. If anyone has tried on Lion, suggestions appreciated or link to a how-to that works for Lion. Here is the output:

$make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
make: pkg-config: Command not found
make: pkg-config: Command not found
CC ../py/nlrx64.S
../py/nlrx64.S:118:Unknown pseudo-op: .bss
make: *** [build/py/nlrx64.o] Error 1
:unix RYAN$ make V=1
make: pkg-config: Command not found
make: pkg-config: Command not found
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else echo "Generating build/genhdr/py-version.h"; mv build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
gcc -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:Unknown pseudo-op: .bss
make: *** [build/py/nlrx64.o] Error 1

$ gcc
i686-apple-darwin11-llvm-gcc-4.2: no input files
$

AWCharlie · 2014-09-20T05:33:22Z

I'm well down the version/dependency/update/conflicting-directions-all-produce-errors rabbit hole, so please disregard. (I thought there were a lot of Mac users. I have Parallels and will install Debian.) Is there a forum? IRC channel?

dhylands · 2014-09-20T06:20:29Z

Forum: forum.micropython.org
IRC #micropython on irc.freenode.net

blmorris · 2014-09-21T01:39:04Z

It looks like you have the ancient version of gcc that OSX provides with Xcode - I have it too, and it doesn't work for micropython. You need to use Apple's clang and follow the steps outlined in #782 - In my comment there I also suggest how to ensure that make uses clang - you need to edit py/mkenv.mk with the following change:

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

However, while I was able to compile the micropython unix port on 10.7.5 / Lion the last time I tried it, I don't use the unix port very much, so I just tried to pull the current source and compile again following those steps and it failed on the linker:

CC seg_helpers.c
LINK micropython
Undefined symbols for architecture x86_64:
  "_mp_unix_free_exec", referenced from:
      _asm_x64_free in asmx64.o
  "_mp_unix_alloc_exec", referenced from:
      _asm_x64_end_pass in asmx64.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [micropython] Error 1

It is also possible that I munged up my source tree somehow, I may try again with a fresh pull. But it isn't the first time that the OSX compilers have found something to complain about.

Edited to add: I just tried again with a fresh source tree and it fails with the same errors. Looks like clang isn't happy with some of the recent changes to py/asmx64.c

AWCharlie · 2014-09-21T03:55:34Z

Thanks, it is getting closer. I left a note on the forum -- dang, that
isn't the forum, its an old issue on github.

Anyway, I don't have /opt in /usr/local and am working on where to put the
newer libffi and how to get it there. (It looks like the pkg-config is part
of that. I'll have to look at the libffi docs and project).

-- Charlie

On Sat, Sep 20, 2014 at 6:39 PM, blmorris notifications@github.com wrote:

It looks like you have the ancient version of gcc that OSX provides with
Xcode - I have it too, and it doesn't work for micropython. You need to use
Apple's clang and follow the steps outlined in #782
#782 - In my comment
there I also suggest how to ensure that make uses clang - you need to edit
py/mkenv.mk with the following change:

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

However, while I was able to compile the micropython unix port on 10.7.5 /
Lion the last time I tried it, I don't use the unix port very much, so I
just tried to pull the current source and compile again following those
steps and it failed on the linker:

CC seg_helpers.c
LINK micropython
Undefined symbols for architecture x86_64:
"_mp_unix_free_exec", referenced from:
_asm_x64_free in asmx64.o
"_mp_unix_alloc_exec", referenced from:
_asm_x64_end_pass in asmx64.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [micropython] Error 1

It is also possible that I munged up my source tree somehow, I may try
again with a fresh pull. But it isn't the first time that the OSX compilers
have found something to complain about.

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

stinos · 2014-09-21T07:57:47Z

mp_unix_free_exec and mp_unix_alloc_exec are defined in unix/alloc.c, is that somehow skipped by the build?

On a sidenote: it's a bit of a shame there is no way to build for OSX without modifications and searching for the correct procedure in github issues

blmorris · 2014-09-21T18:01:59Z

@stinos - "On a sidenote: it's a bit of a shame there is no way to build for OSX without modifications and searching for the correct procedure in github issues"
I would certainly agree with that, but fixing that situation would require an experienced developer to do for OSX what you have done for windows. There have been some very helpful contributions from OSX users who have fixed some problems as they have cropped up, but nobody has adopted OSX yet as their own to support. (And if I were to try, I would just be throwing… stuff... at the wall, to see what sticks. That's no way to support a platform.) The main developers are using linux, and OSX is a very different beast.

@ARMWorks - If you are trying to make your OSX environment as familiar as possible from a Linux point of view (I started on OSX seven years ago after using Linux the previous seven) then you are fighting an uphill battle without installing some package manager like macports, homebrew or fink. I have used fink, now mostly ports (www.macports.org), and while I haven't used homebrew I understand that it can coexist with macports on your machine. Macports installs packages to /opt/local (at least on my machine, it has been so long that I have no idea if this is the default.) At any rate, it was good enough to install ffi to support uPy a month ago… now I need to see if I can figure out why I can't compile now.

And @stinos - thanks for the tip, I will look into unix/alloc.c to see if I can make sense of it.

-Bryan

stinos · 2014-09-21T18:31:00Z

(more sidenote) macports should indeed be the way to go; I don't have a mac no more so I was thinking of maybe getting a trial on macincloud or similar but I'm not sure if it's worth it as I would probably be able to come up with a proper build but without knowing if it works for other developpers etc..

AWCharlie · 2014-09-21T19:46:35Z

@blmorris I just added macports yesterday and am working through. It put
libffi in /opt/local/var/macports/software/libffi

I thought I read it needs to be somewhere else.

This may be a waste of time and I should do all the micropython on Debian.
The only reason is I want to be collecting data for some Mac apps for
visualization and would like one-stop shopping while developing (Python 3.5
on Mac with NumPy, etc. and micropython on a bunch of ad-hoc networked
gizmos that use the 2MHz 12 bit ADC.

-- Charlie

On Sun, Sep 21, 2014 at 11:02 AM, blmorris notifications@github.com wrote:

@stinos https://github.com/stinos - "On a sidenote: it's a bit of a
shame there is no way to build for OSX without modifications and searching
for the correct procedure in github issues"
I would certainly agree with that, but fixing that situation would require
an experienced developer to do for OSX what you have done for windows.
There have been some very helpful contributions from OSX users who have
fixed some problems as they have cropped up, but nobody has adopted OSX yet
as their own to support. (And if I were to try, I would just be throwing…
stuff... at the wall, to see what sticks. That's no way to support a
platform.) The main developers are using linux, and OSX is a very different
beast.

@ARMWorks https://github.com/ARMWorks - If you are trying to make your
OSX environment as familiar as possible from a Linux point of view (I
started on OSX seven years ago after using Linux the previous seven) then
you are fighting an uphill battle without installing some package manager
like macports, homebrew or fink. I have used fink, now mostly ports (
www.macports.org), and while I haven't used homebrew I understand that it
can coexist with macports on your machine. Macports installs packages to
/opt/local (at least on my machine, it has been so long that I have no idea
if this is the default.) At any rate, it was good enough to install ffi to
support uPy a month ago… now I need to see if I can figure out why I can't
compile now.

And @stinos https://github.com/stinos - thanks for the tip, I will look
into unix/alloc.c to see if I can make sense of it.

-Bryan

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-21T20:17:35Z

"It put libffi in /opt/local/var/macports/software/libffi"
That should just be the source archive. Macports should have installed libffi itself in /opt/local/lib
And then it just needs to be in your PATH (which it should be.)
Also, I don't know if this is a problem you are having, but it is still very possible to compile the stmhal port for the pyboard - you just need to grab the latest ARM compiler toolchain for OSX: https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q2-update/+download/gcc-arm-none-eabi-4_8-2014q2-20140609-mac.tar.bz2
Then use macports to install dfu-util 0.7 (or greater if available) to update your firmware.
-Bryan

blmorris · 2014-09-21T21:14:35Z

Minor correction- what I said was the location of the source archive is actually where pre-compiled binary archives go; source archives go someplace else.

blmorris · 2014-09-22T02:37:16Z

@stinos - Thanks again! Problem was exactly as you said, the Makefile which was modified to compile for OSX did not include alloc.c - added that line in and it compiles as it did before.
More embarrassing, however, is that the modified Makefile is no longer necessary - I can use the stock Makefile and the unix port compiles out of the box (OSX 10.7.5)
Just needed to make sure that the change to py/mkenv.mk was in place to force make to invoke clang, because of the old gcc installed on my system.
@ARMWorks - please disregard most of my earlier advice ;^) Make the change to mkenv.mk, get libffi and pkgconfig installed to their default locations with macports, and it should work. If not, I will try to figure out what else I did to make it work.

stinos · 2014-09-22T06:42:17Z

That's nice! So basically these are two realtively simple steps to get the build working - maybe you should add this info to the main Readme.md and submit a PR for it? I think this is going to be useful for future devs

blmorris · 2014-09-22T14:05:59Z

@stinos - Actually, not quite yet. I thought that I was using the mainline unix Makefile to compile last night; what I actually had was the OSX modified Makefile which had been helpfully updated by git with the recent mainline updates while keeping the OSX modifications intact. While git is a great tool, I get really confused trying to follow the logic sometimes… I realized my mistake only after pulling a fresh source tree this morning as a sanity check and getting this error:

LINK micropython
ld: unknown option: -Map=micropython.map
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [micropython] Error 1

So, purely by accident last night I ended up with a makefile that compiles micropython for OSX.
These are the differences between the mainline unix Makefile and the one that compiles under OSX:
Mainline unix Makefile, lines 32 and 83:

LDFLAGS = $(LDFLAGS_MOD) -lm -Wl,-Map=$@.map,--cref $(LDFLAGS_EXTRA)
…
LDFLAGS+ = -Wl,-order_file,$(BUILD)/order.def

OSX modified unix Makefile:

LDFLAGS = $(LDFLAGS_MOD) -lm -Wl,-map,$@.map $(LDFLAGS_EXTRA)
…
LDFLAGS_MOD += -Wl,-order_file,$(BUILD)/order.def

I don't know nearly enough about Makefile syntax or logic to offer a fix that will work on both OSX and Linux; I also don't have an updated OSX system to test on.

@ARMWorks - I hope that you can get this working and that I haven't gotten you even more mixed up than I am.
It might be good to put up a wiki page with tips and tricks to compile for OSX until we can get a general fix into mainline.

dhylands · 2014-09-22T15:32:22Z

@blmorris What does the command uname output under OSX?

blmorris · 2014-09-22T16:29:57Z

@dhylands - uname returns 'Darwin' on OSX.
Also, take a look at pull request #870 - user @toyg put up a PR to try to fix the build scripts, I have left some comments there

blmorris · 2014-09-22T21:04:38Z

I have put up PR #871 which lets me compile both unix and stmhal on OSX 10.7.5
All the changes are in unix/Makefile, py/mkenv.mk remains as is.
I can't claim to understand everything there, but it works for me - any testing would be appreciated.

blmorris · 2014-09-23T14:24:28Z

PR #871 has been merged, so the unix port in the mainline source tree should now build on OSX without any fiddling - assuming, of course, that all dependancies are in place. libffi seems to be the main sticking point.
I can confirm that it works on my system, any testing and confirmation would be welcome.

AWCharlie · 2014-09-23T17:43:41Z

@blmorris if you don't mind cluttering this up a little, can you give me
some advice on installing libffi from macports? I have libffi directories
in two places.

Here there is Portfile and files (patch and patch-diff)
/opt/local/var/macports/sources/
rsync.macports.org/release/tarballs/ports/devel/libffi

and here there is libffi-3.1_4.darwin_11.x86_64.tbz2
/opt/local/var/macports/software/libffi

I don't see a make file. Maybe I'm supposed to use macports to build? I
have been reading the macports docs and am still integrating - waiting for
enlightenment to emerge from the meditation :-) I expected a binary from
macports so obviously don't get it yet.

On Tue, Sep 23, 2014 at 7:24 AM, blmorris notifications@github.com wrote:

PR #871 #871 has been
merged, so the unix port in the mainline source tree should now build on
OSX without any fiddling - assuming, of course, that all dependancies are
in place. libffi seems to be the main sticking point.
I can confirm that it works on my system, any testing and confirmation
would be welcome.

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-23T19:10:50Z

@ARMWorks - Not cluttering it up at all; given the title you gave to the thread I'd say your question finally gets us back on topic ;^)
First - Is your machine an Intel Mac? Just wanted to check, I don't remember if Lion runs on the old PPC machines, and if it is a PPC machine then I doubt any of this will work.
Second, a disclaimer - it has been so long since I installed Macports on this machine (soon after I got it, over seven years ago) that I really don't remember whether or not I needed to struggle to get it set up. Since then, though, it has kept itself up to date pretty well, although there have been a few occasions where I had to uninstall and reinstall a bunch of ports to unwind a tangled set of dependencies.
While Macports has a lot of options, basic usage is pretty simple.
To make sure that you have the latest port definitions:
sudo port selfupdate
To make sure all of your installed packages are up to the latest version:
sudo port upgrade outdated
Then to install the required version of libffi and any required dependencies:
sudo port install libffi@3.1_4
And you can probably leave off the '@3.1_4', which is just to make sure you get the latest.
Now if everything worked as it should have, that command should have either downloaded and installed a binary package, or if it couldn't find precompiled binaries it should have downloaded a source archive and compiled and installed that. You should be able to find a number of libffi* files in /opt/local/lib and there should also be a pkg-config file at /opt/local/lib/pkgconfig/libffi.pc
Don't bother setting an environment path variable, pkg-config knows where to find this file.
Just to be really sure:

bryan$ sudo port info libffi
libffi @3.1_4 (devel)
Variants:             universal

Description:          libffi library provides a portable, high level programming interface to various calling conventions. This allows a
                      programmer to call any function specified by a call interface description at run-time. Some programs may not know at
                      the time of compilation what arguments are to be passed to a function. For instance, an interpreter may be told at
                      run-time about the number and types of arguments used to call a given function. Libffi can be used in such programs to
                      provide a bridge from the interpreter program to compiled code.
Homepage:             http://sources.redhat.com/libffi/

Platforms:            darwin
License:              MIT
Maintainers:          nomaintainer@macports.org

And then you should be able to compile the latest source - but I want to know if you can't! ;^)

blmorris · 2014-09-23T19:17:27Z

And, if we can get this resolved (and understand what we did to get there) then I will start putting together a "Mac OSX tips and tricks" page on the wiki here.
-Bryan

AWCharlie · 2014-09-23T21:21:30Z

Great. Early Intel Mac Pro 8 core running OSX Lion. I got it from a guy two
weeks ago and there was never any development work, so the tools are
freshly updated perhaps incomplete. Command line tools are included in some
versions of Xcode and not in others.

So, I think I will have time to try today.

-- Charlie

On Tue, Sep 23, 2014 at 12:17 PM, blmorris notifications@github.com wrote:

And, if we can get this resolved (and understand what we did to get there)
then I will start putting together a "Mac OSX tips and tricks" page on the
wiki here.
-Bryan

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

AWCharlie · 2014-09-24T03:29:20Z

All goes well until I build. I'll log out/in or restart. I just execute
make in the unix directory, correct? The libffi files are all in the right
places.

unix RYAN$ make V=1
make: pkg-config: Command not found
make: pkg-config: Command not found
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Tue, Sep 23, 2014 at 2:21 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

Great. Early Intel Mac Pro 8 core running OSX Lion. I got it from a guy
two weeks ago and there was never any development work, so the tools are
freshly updated perhaps incomplete. Command line tools are included in some
versions of Xcode and not in others.

So, I think I will have time to try today.

-- Charlie

On Tue, Sep 23, 2014 at 12:17 PM, blmorris notifications@github.com
wrote:

And, if we can get this resolved (and understand what we did to get
there) then I will start putting together a "Mac OSX tips and tricks" page
on the wiki here.
-Bryan

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

AWCharlie · 2014-09-24T03:50:27Z

Checking around a bit I see some older postings in which Lion expects
libffi in /usr/local so I added to the path export
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig/libffi.pc

and now I get just this output from make

(I did a git pull from the unix directory to update. First I deleted the
old Makefile that had been modified.)

make V=1
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Tue, Sep 23, 2014 at 8:29 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

All goes well until I build. I'll log out/in or restart. I just execute
make in the unix directory, correct? The libffi files are all in the right
places.

unix RYAN$ make V=1
make: pkg-config: Command not found
make: pkg-config: Command not found
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Tue, Sep 23, 2014 at 2:21 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

Great. Early Intel Mac Pro 8 core running OSX Lion. I got it from a guy
two weeks ago and there was never any development work, so the tools are
freshly updated perhaps incomplete. Command line tools are included in some
versions of Xcode and not in others.

So, I think I will have time to try today.

-- Charlie

On Tue, Sep 23, 2014 at 12:17 PM, blmorris notifications@github.com
wrote:

And, if we can get this resolved (and understand what we did to get
there) then I will start putting together a "Mac OSX tips and tricks" page
on the wiki here.
-Bryan

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-24T10:41:23Z

There is no need to run 'make' with macports - really, the correct command is 'sudo port install' and that should do everything, even deciding whether to download source or a pre compiled binary.
And Lion doesn't care about the install location. Homebrew, a different package manager, uses /usr/local/opt, macports uses /opt/local. Both work fine.

Sent from my iPhone

On Sep 23, 2014, at 11:50 PM, "C. Towne Springer" notifications@github.com wrote:

Checking around a bit I see some older postings in which Lion expects
libffi in /usr/local so I added to the path export
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig/libffi.pc

and now I get just this output from make

(I did a git pull from the unix directory to update. First I deleted the
old Makefile that had been modified.)

make V=1
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Tue, Sep 23, 2014 at 8:29 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

All goes well until I build. I'll log out/in or restart. I just execute
make in the unix directory, correct? The libffi files are all in the right
places.

unix RYAN$ make V=1
make: pkg-config: Command not found
make: pkg-config: Command not found
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Tue, Sep 23, 2014 at 2:21 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

Great. Early Intel Mac Pro 8 core running OSX Lion. I got it from a guy
two weeks ago and there was never any development work, so the tools are
freshly updated perhaps incomplete. Command line tools are included in some
versions of Xcode and not in others.

So, I think I will have time to try today.

-- Charlie

On Tue, Sep 23, 2014 at 12:17 PM, blmorris notifications@github.com
wrote:

And, if we can get this resolved (and understand what we did to get
there) then I will start putting together a "Mac OSX tips and tricks" page
on the wiki here.
-Bryan

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

—
Reply to this email directly or view it on GitHub.

blmorris · 2014-09-24T10:55:29Z

Try 'sudo port install pkg-config'

Sent from my iPhone

On Sep 23, 2014, at 11:29 PM, "C. Towne Springer" notifications@github.com wrote:

All goes well until I build. I'll log out/in or restart. I just execute
make in the unix directory, correct? The libffi files are all in the right
places.

unix RYAN$ make V=1
make: pkg-config: Command not found
make: pkg-config: Command not found
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Tue, Sep 23, 2014 at 2:21 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

Great. Early Intel Mac Pro 8 core running OSX Lion. I got it from a guy
two weeks ago and there was never any development work, so the tools are
freshly updated perhaps incomplete. Command line tools are included in some
versions of Xcode and not in others.

So, I think I will have time to try today.

-- Charlie

On Tue, Sep 23, 2014 at 12:17 PM, blmorris notifications@github.com
wrote:

And, if we can get this resolved (and understand what we did to get
there) then I will start putting together a "Mac OSX tips and tricks" page
on the wiki here.
-Bryan

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

—
Reply to this email directly or view it on GitHub.

blmorris · 2014-09-24T11:12:56Z

Sorry for the first reply, trying to reply before coffee. Looks like you are almost there- you are all set with libffi, now you are just missing pkg-config, which can also be installed with macports.
Then, in the unix directory of micropython, do make clean, then make. Could even try make install.

AWCharlie · 2014-09-24T17:18:17Z

I do port install pkgconfig and it says everything is fine and binaries are
OK. Something is still missing. How could a .bss be unknown an unknown
directive? Linker missing?

unix RYAN$ make clean
Use make V=1 or set BUILD_VERBOSE in your environment to increase build
verbosity.
rm -f micropython
rm -f micropython.map
rm -rf build
unix RYAN$ make V=1
mkdir -p build/genhdr
CPP ../py/qstrdefs.h
clang -E -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os
../py/qstrdefs.h -o build/genhdr/qstrdefs.preprocessed.h
makeqstrdata ../py/qstrdefs.h qstrdefsport.h
python ../py/makeqstrdata.py build/genhdr/qstrdefs.preprocessed.h
qstrdefsport.h > build/genhdr/qstrdefs.generated.h
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
Generating build/genhdr/py-version.h
mkdir -p build/py
mkdir -p build/py/../extmod
CC ../py/nlrx86.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx86.o ../py/nlrx86.S
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Wed, Sep 24, 2014 at 4:13 AM, blmorris notifications@github.com wrote:

Sorry for the first reply, trying to reply before coffee. Looks like you
are almost there- you are all set with libffi, now you are just missing
pkg-config, which can also be installed with macports.
Then, in the unix directory of micropython, do make clean, then make.
Could even try make install.

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

AWCharlie · 2014-09-24T20:05:32Z

I poked around but I can't tell what is happening. Is this failing on the
first file or is some of it working?

On Wed, Sep 24, 2014 at 10:18 AM, Charles Springer <
charles.regnirps@gmail.com> wrote:

I do port install pkgconfig and it says everything is fine and binaries
are OK. Something is still missing. How could a .bss be unknown an unknown
directive? Linker missing?

unix RYAN$ make clean
Use make V=1 or set BUILD_VERBOSE in your environment to increase build
verbosity.
rm -f micropython
rm -f micropython.map
rm -rf build
unix RYAN$ make V=1
mkdir -p build/genhdr
CPP ../py/qstrdefs.h
clang -E -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os
../py/qstrdefs.h -o build/genhdr/qstrdefs.preprocessed.h
makeqstrdata ../py/qstrdefs.h qstrdefsport.h
python ../py/makeqstrdata.py build/genhdr/qstrdefs.preprocessed.h
qstrdefsport.h > build/genhdr/qstrdefs.generated.h
../py/py-version.sh > build/genhdr/py-version.h.tmp
if [ -f "build/genhdr/py-version.h" ] && cmp -s build/genhdr/py-version.h
build/genhdr/py-version.h.tmp; then rm build/genhdr/py-version.h.tmp; else
echo "Generating build/genhdr/py-version.h"; mv
build/genhdr/py-version.h.tmp build/genhdr/py-version.h; fi
Generating build/genhdr/py-version.h
mkdir -p build/py
mkdir -p build/py/../extmod
CC ../py/nlrx86.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx86.o ../py/nlrx86.S
CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: error: unknown directive
.bss
^
make: *** [build/py/nlrx64.o] Error 1

On Wed, Sep 24, 2014 at 4:13 AM, blmorris notifications@github.com
wrote:

Sorry for the first reply, trying to reply before coffee. Looks like you
are almost there- you are all set with libffi, now you are just missing
pkg-config, which can also be installed with macports.
Then, in the unix directory of micropython, do make clean, then make.
Could even try make install.

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-24T20:13:02Z

This is what I get for the command that your build fails on:

CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1 -I/opt/local/lib/libffi-3.1/include  -DMICROPY_PY_FFI=1 -Os   -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: warning: ignoring directive for now
    .bss
    ^

And then keeps going to completion rather than quitting. There are some special tricks used to get the OSX build process to deal with the bss start and end symbols, there is some ongoing discussion on this topic in the forum. These tricks my not work on older versions of clang.
What do you get from clang -v?
I get:

unix bryan$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

AWCharlie · 2014-09-24T20:47:02Z

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Aha! Errr. Now what? :-)

On Wed, Sep 24, 2014 at 1:13 PM, blmorris notifications@github.com wrote:

This is what I get for the command that your build fails on:

CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1 -I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: warning: ignoring directive for now
.bss
^

And then is keeps going to completion rather than quitting. There are some
special tricks used to get the OSX build process to deal with the bss start
and end symbols, there is some ongoing discussion on this topic in the
forum. These tricks my not work on older versions of clang.
What do you get from clang -v?
I get:

unix bryan$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-24T20:52:23Z

Probably update Xcode; it's been a while since I have done so, I think you go straight to apple's web site and download. You may need to set up a developers account, or maybe just an Apple ID, but at any rate I'm pretty sure it's free.

Sent from my iPhone

On Sep 24, 2014, at 4:47 PM, "C. Towne Springer" notifications@github.com wrote:

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Aha! Errr. Now what? :-)

On Wed, Sep 24, 2014 at 1:13 PM, blmorris notifications@github.com wrote:

This is what I get for the command that your build fails on:

CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1 -I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: warning: ignoring directive for now
.bss
^

And then is keeps going to completion rather than quitting. There are some
special tricks used to get the OSX build process to deal with the bss start
and end symbols, there is some ongoing discussion on this topic in the
forum. These tricks my not work on older versions of clang.
What do you get from clang -v?
I get:

unix bryan$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

—
Reply to this email directly or view it on GitHub.

blmorris · 2014-09-24T20:55:23Z

Actually, it looks like I have the older version. This may not be the solution to our problem...

Sent from my iPhone

On Sep 24, 2014, at 4:47 PM, "C. Towne Springer" notifications@github.com wrote:

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Aha! Errr. Now what? :-)

On Wed, Sep 24, 2014 at 1:13 PM, blmorris notifications@github.com wrote:

This is what I get for the command that your build fails on:

CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1 -I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: warning: ignoring directive for now
.bss
^

And then is keeps going to completion rather than quitting. There are some
special tricks used to get the OSX build process to deal with the bss start
and end symbols, there is some ongoing discussion on this topic in the
forum. These tricks my not work on older versions of clang.
What do you get from clang -v?
I get:

unix bryan$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

—
Reply to this email directly or view it on GitHub.

AWCharlie · 2014-09-24T20:58:44Z

Yeah, my xcode is fresh from the oven. I see this was maybe dealt with in
May. Reading.....

#607

On Wed, Sep 24, 2014 at 1:55 PM, blmorris notifications@github.com wrote:

Actually, it looks like I have the older version. This may not be the
solution to our problem...

Sent from my iPhone

On Sep 24, 2014, at 4:47 PM, "C. Towne Springer" notifications@github.com
wrote:

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Aha! Errr. Now what? :-)

On Wed, Sep 24, 2014 at 1:13 PM, blmorris notifications@github.com
wrote:

This is what I get for the command that your build fails on:

CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: warning: ignoring directive for now
.bss
^

And then is keeps going to completion rather than quitting. There are
some
special tricks used to get the OSX build process to deal with the bss
start
and end symbols, there is some ongoing discussion on this topic in the
forum. These tricks my not work on older versions of clang.
What do you get from clang -v?
I get:

unix bryan$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM
3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

—
Reply to this email directly or view it on GitHub
<
https://github.com/micropython/micropython/issues/865#issuecomment-56731233>

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

AWCharlie · 2014-09-24T21:01:29Z

Oops. I think we have been there. The only thing with .bss and clang that
shows up in a Google search is that thread and another that was merged with
it.

On Wed, Sep 24, 2014 at 1:58 PM, Charles Springer <
charles.regnirps@gmail.com> wrote:

Yeah, my xcode is fresh from the oven. I see this was maybe dealt with in
May. Reading.....

#607

On Wed, Sep 24, 2014 at 1:55 PM, blmorris notifications@github.com
wrote:

Actually, it looks like I have the older version. This may not be the
solution to our problem...

Sent from my iPhone

On Sep 24, 2014, at 4:47 PM, "C. Towne Springer" <
notifications@github.com> wrote:

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

Aha! Errr. Now what? :-)

On Wed, Sep 24, 2014 at 1:13 PM, blmorris notifications@github.com
wrote:

This is what I get for the command that your build fails on:

CC ../py/nlrx64.S
clang -I. -I../py -Ibuild -Wall -Werror -ansi -std=gnu99 -DUNIX
-DMICROPY_USE_READLINE=1 -DMICROPY_PY_TIME=1 -DMICROPY_PY_TERMIOS=1
-I/opt/local/lib/libffi-3.1/include -DMICROPY_PY_FFI=1 -Os -c -o
build/py/nlrx64.o ../py/nlrx64.S
../py/nlrx64.S:118:5: warning: ignoring directive for now
.bss
^

And then is keeps going to completion rather than quitting. There are
some
special tricks used to get the OSX build process to deal with the bss
start
and end symbols, there is some ongoing discussion on this topic in
the
forum. These tricks my not work on older versions of clang.
What do you get from clang -v?
I get:

unix bryan$ clang -v
Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM
3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

—
Reply to this email directly or view it on GitHub
<
https://github.com/micropython/micropython/issues/865#issuecomment-56731233>

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-24T21:07:56Z

It's been an ongoing issue, some of the low-level gc stuff tests some corner-cases of compiler behavior.
I suspect we just need to adjust the options to get a warning and not an error.

dhylands · 2014-09-24T21:40:24Z

I think that what's going on here is that the internal assembler used by clang doesn't recognize the .bss directive.

blmorris · 2014-09-25T03:21:28Z

Yes, the question is why the build continues with a warning on my system and fails with an error on the newer version of clang - and whether we can find a way to continue with a warning instead of that error. I don't imagine that the OSX assembler is suddenly decide that it is happy with the .bss directive ;-)

blmorris · 2014-09-25T17:06:45Z

@ARMWorks - Okay, this is ugly, but just try it: go to /py/nlrx64.S and comment out line 118 which just contains the single statement .bss
I just tried it, and the warning goes away and the executable and map file are identical to when it was left in. It appears that clang just ignores it on my system; there is a bit of work done elsewhere in the build scripts to make sure that the job done by that directive under gcc still happens under clang.
If it works for you then we can figure out a prettier way to do it.
Good luck!

AWCharlie · 2014-09-25T20:30:09Z

Woohoo! I commented out bss in two places. Compiles, links, runs. 5+3 even
= 8.

Thanks for the effort. Now I'll have to target STM32 and TI, etc. I can
finally work on the same system I write docs, maintain web pages, do the
graphics, and all that.

-- Charlie

On Thu, Sep 25, 2014 at 10:06 AM, blmorris notifications@github.com wrote:

@ARMWorks https://github.com/ARMWorks - Okay, this is ugly, but just
try it: go to /py/nlrx64.S and comment out line 118 which just contains
the single statement .bss
I just tried it, and the warning goes away and the executable and map file
are identical to when it was left in. It appears that clang just ignores it
on my system; there is a bit of work done elsewhere in the build scripts to
make sure that the job done by that directive under gcc still happens under
clang.
If it works for you then we can figure out a prettier way to do it.
Good luck!

—
Reply to this email directly or view it on GitHub
#865 (comment)
.

blmorris · 2014-09-25T21:00:37Z

Sweet! I'll do a PR later this evening. I realized after my last comment that the immediate preceding and following lines are already #ifdef'd out for OSX, so it's nice and clean to wrap them all together. I just don't know why it wasn't done that way initially- maybe just an oversight, but we should be sure. Anyway, looks like we are close to proper OSX support.

It seems that newer versions of clang don't like the .bss directive, so we don't use it for OSX. Addressing issues #865 and #875.

blmorris · 2014-10-07T16:06:38Z

I suspect that this issue can be closed; with the current source tree Micro Python can be compiled on OSX without any special workarounds.
I have started writing an article on the wiki called Micro Python on Mac OSX to explain how to install the necessary software dependencies on a Mac to work with Micro Python. Still a work in progress, filling in details as time allows.

Fix ReadTheDocs build due to c2rst.

blmorris mentioned this issue Sep 22, 2014

micropython won't compile on OSX Mavericks #782

Closed

blmorris mentioned this issue Sep 26, 2014

Enable unix build for current versions of clang (OSX) #875

Closed

dpgeorge added a commit that referenced this issue Sep 26, 2014

py: Clean up nlr*.S to make it easier to read; fix clang .bss error.

133b083

It seems that newer versions of clang don't like the .bss directive, so we don't use it for OSX. Addressing issues #865 and #875.

dpgeorge closed this as completed Oct 9, 2014

tannewt pushed a commit to tannewt/circuitpython that referenced this issue May 24, 2018

Merge pull request micropython#865 from tannewt/fix_rtd_build

2fd9e9a

Fix ReadTheDocs build due to c2rst.

Mac Lion dependencies #865

Mac Lion dependencies #865

Comments

AWCharlie commented Sep 19, 2014

AWCharlie commented Sep 20, 2014

dhylands commented Sep 20, 2014

blmorris commented Sep 21, 2014

AWCharlie commented Sep 21, 2014

stinos commented Sep 21, 2014

blmorris commented Sep 21, 2014

stinos commented Sep 21, 2014

AWCharlie commented Sep 21, 2014

blmorris commented Sep 21, 2014

blmorris commented Sep 21, 2014

blmorris commented Sep 22, 2014

stinos commented Sep 22, 2014

blmorris commented Sep 22, 2014

dhylands commented Sep 22, 2014

blmorris commented Sep 22, 2014

blmorris commented Sep 22, 2014

blmorris commented Sep 23, 2014

AWCharlie commented Sep 23, 2014

blmorris commented Sep 23, 2014

blmorris commented Sep 23, 2014

AWCharlie commented Sep 23, 2014

AWCharlie commented Sep 24, 2014

AWCharlie commented Sep 24, 2014

blmorris commented Sep 24, 2014

blmorris commented Sep 24, 2014

blmorris commented Sep 24, 2014

AWCharlie commented Sep 24, 2014

AWCharlie commented Sep 24, 2014

blmorris commented Sep 24, 2014

AWCharlie commented Sep 24, 2014

blmorris commented Sep 24, 2014

blmorris commented Sep 24, 2014

AWCharlie commented Sep 24, 2014

AWCharlie commented Sep 24, 2014

blmorris commented Sep 24, 2014

dhylands commented Sep 24, 2014

blmorris commented Sep 25, 2014

blmorris commented Sep 25, 2014

AWCharlie commented Sep 25, 2014

blmorris commented Sep 25, 2014

blmorris commented Oct 7, 2014