Beginning support for ARMv7 hosts (RasPi, etc.) #439

hpux735 · 2015-12-11T22:32:23Z

I'm almost finished with enabling native compilation on ARMv7 hosts such as the Raspberry Pi, BeagleBone, Nvidia Tegras, etc...

The build of the swift compiler and standard library complete. The compiler is also capable of generating executables, though there is a remaining linker problem. I'm not sure where to move from here, so I'm hoping that this work can be a starting point for some. The error is: unexpected reloc type 0x03

I've tested this patch in attempt to determine whether it negatively effects building on MacOS or Ubuntu 15.10 on x68_64. In MacOS, the test suite completes with 2 unexpected failures, 2350 expected passes, 5 expected failures, and 33 unsupported tests. The x86_64 linux build completes with 1682 expected passes, 92 expected failures, 575 unsupported failures (apparently no unexpected failures). Finally, the linux arm port completes the testing suite with 1456 expected passes, 81 expected failures, 639 unsupported tests, and 155 unexpected failures.

I'm happy to make any changes to requested, and I'd be overjoyed if anyone had a crumb trail I could follow to address the linking issued.

Any comments are very appreciated!

gribozavr · 2015-12-11T22:51:08Z

Sign in to view

  set(SWIFT_PRIMARY_VARIANT_SDK_default "LINUX")
-  set(SWIFT_PRIMARY_VARIANT_ARCH_default "x86_64")
+
+  if("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64")


Please leave a comment here that this only works for building a host compiler, and won't work for building cross-compilers.

gribozavr · 2015-12-11T22:57:19Z

Sign in to view

@@ -216,7 +216,7 @@ extern "C" long double _swift_fmodl(long double lhs, long double rhs) {
 // This implementation is copied here to avoid a new dependency
 // on compiler-rt on Linux.
 // FIXME: rdar://14883575 Libcompiler_rt omits muloti4
-#if __arm64__ || !defined(__APPLE__)
+#if (__arm64__ || !defined(__APPLE__)) && !defined(__arm__)


Let's be more explicit in this list:

#if (defined(__APPLE__) && defined(__arm64__)) || \ (defined(__linux__) && defined(__x86_64__))

gribozavr · 2015-12-11T22:58:40Z

Sign in to view

@@ -12,16 +12,18 @@
 // RUN: FileCheck -check-prefix watchOS_SIMPLE %s < %t.simple.txt

 // RUN: %swiftc_driver -driver-print-jobs -target x86_64-unknown-linux-gnu -Ffoo -framework bar -Lbaz -lboo -Xlinker -undefined %s 2>&1 > %t.linux.txt
-// RUN: FileCheck -check-prefix LINUX %s < %t.linux.txt
+// RUN: FileCheck -check-prefix LINUXx86 %s < %t.linux.txt


Could you name this prefix LINUX-x86_86?

gribozavr · 2015-12-11T22:58:50Z

Sign in to view

+// RUN: FileCheck -check-prefix LINUXx86 %s < %t.linux.txt
+
+// RUN: %swiftc_driver -driver-print-jobs -target armv7-unknown-linux-gnueabihf -Ffoo -framework bar -Lbaz -lboo -Xlinker -undefined %s 2>&1 > %t.linux.txt
+// RUN: FileCheck -check-prefix LINUXarm %s < %t.linux.txt


Ditto, LINUX-arm?

gribozavr · 2015-12-11T23:00:59Z

Sign in to view

@@ -657,6 +657,56 @@ elif run_os == 'linux-gnu':
        "ld -L%s" %
        (os.path.join(test_resource_dir, config.target_sdk_name)))

+elif run_os == 'linux-gnueabihf':


What is the difference between this block and the previous block? Can it be factored with 'if' statements instead of code duplication?

gribozavr · 2015-12-11T23:03:17Z

Sign in to view

@@ -227,6 +227,9 @@ function set_deployment_target_based_options() {
        linux-x86_64)
            SWIFT_HOST_VARIANT_ARCH="x86_64"
            ;;
+        linux-armv7)
+            SWIFT_HOST_VARIANT_ARCH="ARM"


It should be armv7.

armv7-gnueabihf eventually.

gribozavr · 2015-12-11T23:07:32Z

There are soft float and hard float variants of armv7 ABI (and even multiple variants of those, IIRC). To ensure that the arm port is future-proof, the architecture name here needs to be something like armv7-gnueabihf to allow other variants. This is not necessarily something you need to worry about right now, but could you file an issue about taking care of that in future, when the port is in a better shape?

gribozavr · 2015-12-11T23:09:54Z

Sign in to view

@@ -1115,8 +1115,13 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
  // Add the linker script that coalesces protocol conformance sections.
  Arguments.push_back("-Xlinker");
  Arguments.push_back("-T");
-  Arguments.push_back(
-      context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld"));
+#if defined(__arm__)


Swift is a cross-compiler, we don't do #ifs in the C++ sources. Please query the target and use the correct path. getTriple().getArchName(), I think, but it should also include the gnueabihf suffix, so please leave a fixme for that.

gribozavr · 2015-12-11T23:18:11Z

In general this looks good to me, please fix those issues and I'll merge.

hpux735 · 2015-12-11T23:48:12Z

With this comment: "There are soft float and hard float variants of armv7 ABI (and even multiple variants of those, IIRC). To ensure that the arm port is future-proof, the architecture name here needs to be something like armv7-gnueabihf to allow other variants. This is not necessarily something you need to worry about right now, but could you file an issue about taking care of that in future, when the port is in a better shape?"

It's not clear with block of code you're referring to. You're absolutely correct that I have made no attempt to correctly handle soft-float versions, or any other abis, for that matter. I'd like to learn more about how the target triples are passed through the build scripts so that these are correctly handled, as well as eventual hope for cross-compiling.

I've implemented all of your suggestions (thank you for them!), and I'll let you know when I finish testing it all again.

gribozavr · 2015-12-12T01:23:10Z

It's not clear with block of code you're referring to.

I'm referring to the code in general, where it uses armv7 to identify the architecture.

I'd like to learn more about how the target triples are passed through the build scripts so that these are correctly handled, as well as eventual hope for cross-compiling.

Currently we don't have anything like hard/soft variants for any of the supported architectures, so there isn't anything you can look at. The first approximation would be to just use armv7-gnueabihf as the architecture name, I think. That will require some modifications to the compiler where we pass that name directly to LLVM.

gribozavr · 2015-12-12T02:06:31Z

Sign in to view

+  // FIXME: This should also query the abi type (i.e. gnueabihf)
+  if (getTriple().getArch() == llvm::Triple::arm) {
+    Arguments.push_back(
+      context.Args.MakeArgString(Twine(RuntimeLibPath) + "/armv7/swift.ld"));


Why not just concatenate in getTriple().getArchName()? Or does it return something strange? If that's the case, convert the if chain to switch.

gribozavr · 2015-12-12T09:43:12Z

Sign in to view

-      context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld"));
+
+  // FIXME: This should also query the abi type (i.e. gnueabihf)
+    Arguments.push_back(context.Args.MakeArgString(


Indentation on this line is off.

gribozavr · 2015-12-12T09:43:22Z

Sign in to view

  set(SWIFT_PRIMARY_VARIANT_SDK_default "LINUX")
-  set(SWIFT_PRIMARY_VARIANT_ARCH_default "x86_64")
+
+# FIXME: This will not work while trying to cross-compile


Indentation of the comment is off.

gribozavr · 2015-12-12T09:55:00Z

Sign in to view

+// LINUX-armv7-DAG: -lswiftCore
+// LINUX-armv7-DAG: -L [[STDLIB_PATH:[^ ]+/lib/swift]]
+// LINUX-armv7-DAG: -Xlinker -rpath -Xlinker [[STDLIB_PATH]]
+// LINUX-armv7-DAG: -Xlinker -T /{{[^ ]+}}/linux/arm/swift.ld


This line needs to say .../armv7/swift.ld

Hm, interesting. On OS X that test fails with that symptom, but on Linux x86-64 it passes.

Ah, no, it does not pass because the whole file is // XFAIL: linux.

Feel free to factor out Linux-specific or Apple-specific parts into a separate file to increase test coverage.

gribozavr · 2015-12-12T10:00:13Z

The patch LGTM with those few issues fixed. May I also ask you to squash the commits?

gribozavr · 2015-12-12T10:32:55Z

Sign in to view

+    configure_sdk_unix(LINUX "Linux" "linux" "linux" "x86_64" "x86_64-unknown-linux-gnu")
+    set(SWIFT_HOST_VARIANT_ARCH "x86_64")
+    set(SWIFT_PRIMARY_VARIANT_ARCH_default "x86_64")
+  else()


Could you make an explicit branch based on the CMAKE_SYSTEM_PROCESSOR value? This will simplify adding further ports.

I believe that I've done this, but it's not clear from the pull request (apple:master hpux735:master) that it has been completed. Let me know if I need to try again.

Sorry for being unclear, I meant instead of else() assuming armv7 using an explicit value here.

timbodeit · 2015-12-12T18:20:15Z

Sign in to view

-case "$(uname -s)" in
-    Linux)
+# FIXME: This will not work while trying to cross-compile
+# It gets the architecture from the system processor arch.


Can you elaborate on what you mean by this?
The way I understand it, the processor architecture of the build machine is exactly what we'd want here.
Or what exactly is the issue while cross compiling?

Excellent point, you're right. I've removed the comment. It's not collapsing this change in the pull request view, because I moved this development into the armv7 branch, and it's unclear to me how PRs work with branches that only exist on one fork.

You can choose a head branch when opening the pull request. The changes on this head branch (in your case master) will be tracked in the pull request.
Normally, I create a separate branch for each pull-request before opening it.

So, you'd either have to continue working on your master or close and resubmit the pull request with your armv7 branch selected as the HEAD. I don't think it's possible to change the head branch once a pull request has been created.

Yes, I think this comment can be removed.

timbodeit · 2015-12-12T20:58:13Z

Sign in to view

-case "$(uname -s)" in
-    Linux)
+# FIXME: This will not work while trying to cross-compile
+# It gets the architecture from the system processor arch.


I think this one can be removed as well.

I hope I am understanding this correctly. Would be good if someone else could confirm my logic:
STDLIB_DEPLOYMENT_TARGETS specifies all targets that the native build machine is capable of building.
See how Darwin \x86_64 contains the iphoneos-arm targets?
This means, that a Darwin\ x86_64 build machine is able to (cross-)compile for all of the listed targets.

gribozavr · 2015-12-13T08:10:18Z

Thank you, merging!

Beginning support for ARMv7 hosts (RasPi, etc.)

adtrevor · 2015-12-13T08:22:41Z

Does this mean that now, we will be able to program in Swift on Raspberry Pi?

hpux735 · 2015-12-13T16:01:20Z

Thanks Dmitri! I appreciate all of your comments!

We're getting close, Trevor. Swiftc can make executable files, but there is a remaining problem in the linker part of the process, so they can't run just yet.

MagaTailor · 2015-12-13T18:35:47Z

Is there a binary build somewhere to try out?

hpux735 · 2015-12-13T19:09:38Z

I'm not sure how to package it up yet, but I'll look into it. The executables that swiftc makes don't run yet, so a binary build isn't all that useful. This is more of a starting point to fixing that last problem.

MagaTailor · 2015-12-13T19:16:02Z

Great, thx; a tarball similar to what rust offers (unofficially) should be enough to play with.

modocache · 2015-12-14T05:53:23Z

lib/Driver/ToolChains.cpp

-  Arguments.push_back(
-      context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld"));
+
+  // FIXME: This should also query the abi type (i.e. gnueabihf)


@hpux735 @gribozavr Sorry if I'm missing something, but would something like the following work?

diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp index 712ea65..872843a 100644 --- a/lib/Driver/ToolChains.cpp +++ b/lib/Driver/ToolChains.cpp @@ -1115,10 +1115,11 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job, // Add the linker script that coalesces protocol conformance sections. Arguments.push_back("-Xlinker"); Arguments.push_back("-T"); - - // FIXME: This should also query the abi type (i.e. gnueabihf) + Arguments.push_back(context.Args.MakeArgString( - Twine(RuntimeLibPath) + "/" + getTriple().getArchName() + "/swift.ld")); + Twine(RuntimeLibPath) + "/" + getTriple().getArchName() + \ + llvm::Triple::getEnvironmentTypeName(getTriple().getEnvironment()) + \ + "/swift.ld")); // This should be the last option, for convenience in checking output. Arguments.push_back("-o");

I think so, with a dash in between.

Awesome. I'll send a pull request; there's also a test that needs updating.

I think you’ll need to update the location where the stdlib is built into, otherwise the paths won’t match. I tried this last night.

On Dec 14, 2015, at 7:25 AM, Brian Gesiak notifications@github.com wrote:

In lib/Driver/ToolChains.cpp #439 (comment):

@@ -1115,8 +1115,10 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
// Add the linker script that coalesces protocol conformance sections.
Arguments.push_back("-Xlinker");
Arguments.push_back("-T");

Arguments.push_back(

context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld"));

// FIXME: This should also query the abi type (i.e. gnueabihf)
Awesome. I'll send a pull request; there's also a test that needs updating.

—
Reply to this email directly or view it on GitHub https://github.com/apple/swift/pull/439/files#r47509595.

Ah, gotcha. Looks like it isn't as simple as I thought in #536, then. 😛

I think it's a good idea, but there's just one more piece to the puzzle. :)

hpux735 · 2015-12-20T18:11:03Z

@petevine I've finally finished a downloadable package for a working (but still very alpha) swift compiler and Foundation for ARM: http://www.housedillon.com/?p=2287

MagaTailor · 2015-12-21T14:02:38Z

Thanks, I'll give it a try on my Odroid.

EDIT:
Nope, doesn't work from an arbitrary directory:

swiftc hello.swift
<unknown>:0: error: opening import file for module 'SwiftShims': No such file or directory

What variables can be set to provide (presumably) the correct search paths?

hpux735 · 2015-12-21T19:40:46Z

I didn't get the exact same error message, but it doesn't work for me, either.
Would you mind creating a bug report on bugs.swift.org?

MagaTailor · 2015-12-21T19:57:07Z

No problem if it's a bug and not user error. Depending on the absence/presence of -module-cache-path
SwiftShims was being created in some directory inside of, for example:

/tmp/org.llvm.clang.odroid/

after unpacking your distro in /tmp

hpux735 · 2015-12-22T02:10:06Z

I think it’s just as likely that I don’t know how to make the distribution package correctly.

Joe Bell is looking into making a debian repository for publishing this. Hopefully he’s able to make that work a little better.

I definitely like having things in the issue tracker. Even if it ends up being user error, no worries, it can just be closed. Otherwise, I’m very likely to forget all the different little issues that people mention to me. The latter is a much worse outcome! :)

On Dec 21, 2015, at 12:01 PM, petevine notifications@github.com wrote:

No problem if it's a bug and not user error. Depending on the absence/presence of -module-cache-path
SwiftShims was being created in some directory inside of, for example:

/tmp/org.llvm.clang.odroid/

after unpacking your distro in /tmp

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

iachievedit · 2015-12-22T17:27:30Z

@petevine Try out the package just posted at http://dev.iachieved.it/iachievedit/debian-packages-for-swift-on-arm/, both snippets of Swift code at the bottom of the post work on BeagleBone Black and BeagleBoard X15. I need to run out and get me a RaspPi 2, oddly enough I don't own one yet.

MagaTailor · 2015-12-22T17:49:26Z

I'll need a direct link as I'm not interested in installing system-wide. Thx.

iachievedit · 2015-12-22T18:05:47Z

You can use apt-get download and dpkg -x:

root@beaglebone:~# cd /tmp
root@beaglebone:/tmp# apt-get download swift-2.2
Get:1 http://iachievedit-repos.s3.amazonaws.com/ jessie/main swift-2.2 armhf 1:2.2-0ubuntu7 [63.0 MB]
Fetched 63.0 MB in 14s (4,330 kB/s)                                                                                                                          
root@beaglebone:/tmp# dpkg -x swift-2.2_1%3a2.2-0ubuntu7_armhf.deb ./swift-2.2
root@beaglebone:/tmp# cd swift-2.2/
root@beaglebone:/tmp/swift-2.2# ls
usr
root@beaglebone:/tmp/swift-2.2# ./usr/bin/swiftc -v
Swift version 2.2-dev (LLVM 3ebdbb2c7e, Clang f66c5bb67b, Swift 30f90dc111)
Target: armv7-unknown-linux-gnueabihf

MagaTailor · 2015-12-22T18:08:34Z

Thx, that's exactly what I had in mind. I'll let you know as soon as I've tried it out.
(and you don't need root just to do apt-get download BTW)

EDIT:
Nope, I'm getting the same error as before. From the strace it seems it's failing in an external process (clang?) so there's probably a problem with clang's configuration which fails to generate the object file.

https://bugs.swift.org/browse/SR-333

hpux735 · 2015-12-22T20:16:51Z

Yah, I’m very confused. I can’t reproduce this bug. On my fresh install (are you using Ubuntu or Debian?), it works fine when I install at /opt/apple. The file you’re seeing in /tmp is generated by the build process. A huge part of the swift build process is clang. Can you paste in your source code, just in case?

On Dec 22, 2015, at 12:06 PM, petevine notifications@github.com wrote:

Nope, I'm getting the same error as before. From the strace it seems it's failing in an external process (clang?) so there's probably a problem with clang's configuration which fails to generate the object file.

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

MagaTailor · 2015-12-22T20:24:34Z

It's Ubuntu 14.04 so that probably means clang is not getting installed correctly. Code is just one line:
print("Hello, world!")

Could you paste your ls -l /usr/bin/clang*?

Mine looks like this:

lrwxrwxrwx 1 root root 23 Dec 22 10:42 /usr/bin/clang -> /etc/alternatives/clang
lrwxrwxrwx 1 root root 25 Dec 22 09:58 /usr/bin/clang++ -> /etc/alternatives/clang++
lrwxrwxrwx 1 root root 25 Apr 28  2015 /usr/bin/clang-3.6 -> ../lib/llvm-3.6/bin/clang
lrwxrwxrwx 1 root root 27 Apr 28  2015 /usr/bin/clang++-3.6 -> ../lib/llvm-3.6/bin/clang++
lrwxrwxrwx 1 root root 44 Apr 28  2015 /usr/bin/clang-apply-replacements-3.6 -> ../lib/llvm-3.6/bin/clang-apply-replacements
lrwxrwxrwx 1 root root 31 Apr 28  2015 /usr/bin/clang-check-3.6 -> ../lib/llvm-3.6/bin/clang-check
lrwxrwxrwx 1 root root 31 Apr 28  2015 /usr/bin/clang-query-3.6 -> ../lib/llvm-3.6/bin/clang-query
lrwxrwxrwx 1 root root 32 Apr 28  2015 /usr/bin/clang-rename-3.6 -> ../lib/llvm-3.6/bin/clang-rename
lrwxrwxrwx 1 root root 32 Apr 28  2015 /usr/bin/clang-tblgen-3.6 -> ../lib/llvm-3.6/bin/clang-tblgen
lrwxrwxrwx 1 root root 30 Apr 28  2015 /usr/bin/clang-tidy-3.6 -> ../lib/llvm-3.6/bin/clang-tidy

iachievedit · 2015-12-22T21:56:39Z

@petevine I am on Ubuntu 14.04 as well, here is my version of Clang and /usr/bin listing:

root@arm:/usr/bin# dpkg -l|grep clang
ii  clang-3.6                           1:3.6-2ubuntu1~trusty1                    armhf        C, C++ and Objective-C compiler (LLVM based)
ii  libclang-common-3.6-dev             1:3.6-2ubuntu1~trusty1                    armhf        clang library - Common development package
ii  libclang1-3.6:armhf                 1:3.6-2ubuntu1~trusty1                    armhf        C interface to the clang library
root@arm:/usr/bin# ls -l clang*
lrwxrwxrwx 1 root root 23 Dec 18 13:59 clang -> /etc/alternatives/clang
lrwxrwxrwx 1 root root 25 Dec 18 13:59 clang++ -> /etc/alternatives/clang++
lrwxrwxrwx 1 root root 25 Apr 28  2015 clang-3.6 -> ../lib/llvm-3.6/bin/clang
lrwxrwxrwx 1 root root 27 Apr 28  2015 clang++-3.6 -> ../lib/llvm-3.6/bin/clang++
lrwxrwxrwx 1 root root 44 Apr 28  2015 clang-apply-replacements-3.6 -> ../lib/llvm-3.6/bin/clang-apply-replacements
lrwxrwxrwx 1 root root 31 Apr 28  2015 clang-check-3.6 -> ../lib/llvm-3.6/bin/clang-check
lrwxrwxrwx 1 root root 31 Apr 28  2015 clang-query-3.6 -> ../lib/llvm-3.6/bin/clang-query
lrwxrwxrwx 1 root root 32 Apr 28  2015 clang-rename-3.6 -> ../lib/llvm-3.6/bin/clang-rename
lrwxrwxrwx 1 root root 32 Apr 28  2015 clang-tblgen-3.6 -> ../lib/llvm-3.6/bin/clang-tblgen
lrwxrwxrwx 1 root root 30 Apr 28  2015 clang-tidy-3.6 -> ../lib/llvm-3.6/bin/clang-tidy
root@arm:/usr/bin# clang -v
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.8.4
Found candidate GCC installation: /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9.1
Found candidate GCC installation: /usr/lib/gcc/arm-linux-gnueabihf/4.8
Found candidate GCC installation: /usr/lib/gcc/arm-linux-gnueabihf/4.8.4
Found candidate GCC installation: /usr/lib/gcc/arm-linux-gnueabihf/4.9
Found candidate GCC installation: /usr/lib/gcc/arm-linux-gnueabihf/4.9.1
Selected GCC installation: /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.8
Candidate multilib: .;@m32
Selected multilib: .;@m32

Of course I can't reproduce your issue either, and I've installed the package on 3 different ARM systems, all armv7l based.

MagaTailor · 2015-12-22T22:21:26Z

The only apparent difference is gcc 4.9 on my system. Could you attach a strace from a successful compilation?

hpux735 · 2015-12-23T02:43:15Z

Yep, sure thing: http://ramone.coas.oregonstate.edu/hello.trace

hpux735 · 2015-12-23T05:14:56Z

I'm fairly certain that this is a duplicate of this bug: https://bugs.swift.org/browse/SR-23 and is not an Arm specific thing.

MagaTailor · 2015-12-23T09:44:23Z

@hpux735 That's definitely not a successful compilation! (source file didn't exist)

If the issue is not ARM-specific, never mind - I'll have a go at swift when it's ready.

hpux735 · 2015-12-23T18:07:04Z

Oops. I updated it. Also note that I don’t think that it’s tracing the clang invocation. That’s likely where the issue really is.

On Dec 23, 2015, at 1:45 AM, petevine notifications@github.com wrote:

@hpux735 https://github.com/hpux735 That's definitely not a successful compilation! (source file didn't exist)

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

gribozavr self-assigned this Dec 11, 2015

gribozavr reviewed Dec 11, 2015
View changes

gribozavr reviewed Dec 12, 2015
View changes

timbodeit reviewed Dec 12, 2015
View changes

Build working on ARMv7l

4bf81e0

gribozavr added a commit that referenced this pull request Dec 13, 2015

Merge pull request #439 from hpux735/master

f28d348

Beginning support for ARMv7 hosts (RasPi, etc.)

gribozavr merged commit f28d348 into apple:master Dec 13, 2015

modocache reviewed Dec 14, 2015
View changes

modocache mentioned this pull request Dec 14, 2015

[Driver] Denote ABI type in driver invocation #536

Closed

This was referenced Oct 10, 2020

[workflow] add markdown link checker jessesquires/jessesquires.com#120

Closed

TESTING DO NOT MERGE jessesquires/jessesquires.com#121

Closed

Testing jessesquires/jessesquires.com#122

Closed

apple / swift

Beginning support for ARMv7 hosts (RasPi, etc.) #439

Beginning support for ARMv7 hosts (RasPi, etc.) #439

Conversation

hpux735 commented Dec 11, 2015

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

gribozavr commented Dec 11, 2015

This comment has been minimized.

gribozavr Dec 11, 2015 Collaborator

gribozavr commented Dec 11, 2015

hpux735 commented Dec 11, 2015

gribozavr commented Dec 12, 2015

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

gribozavr commented Dec 12, 2015

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

hpux735 Dec 12, 2015 Author Contributor

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

timbodeit Dec 12, 2015 Contributor

This comment has been minimized.

hpux735 Dec 12, 2015 Author Contributor

This comment has been minimized.

timbodeit Dec 12, 2015 Contributor

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

This comment has been minimized.

timbodeit Dec 12, 2015 Contributor

This comment has been minimized.

gribozavr Dec 12, 2015 Collaborator

gribozavr commented Dec 13, 2015

adtrevor commented Dec 13, 2015

hpux735 commented Dec 13, 2015

This comment has been minimized.

MagaTailor commented on 4bf81e0 Dec 13, 2015

This comment has been minimized.

hpux735 replied Dec 13, 2015

This comment has been minimized.

MagaTailor replied Dec 13, 2015

This comment has been minimized.

modocache Dec 14, 2015 Collaborator

This comment has been minimized.

gribozavr Dec 14, 2015 Collaborator

This comment has been minimized.

modocache Dec 14, 2015 Collaborator

This comment has been minimized.

hpux735 Dec 14, 2015 Author Contributor

This comment has been minimized.

modocache Dec 14, 2015 Collaborator

This comment has been minimized.

hpux735 Dec 14, 2015 Author Contributor

hpux735 commented Dec 20, 2015

MagaTailor commented Dec 21, 2015

hpux735 commented Dec 21, 2015

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 11, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

gribozavr Dec 12, 2015
Collaborator

hpux735 Dec 12, 2015
Author Contributor

gribozavr Dec 12, 2015
Collaborator

timbodeit Dec 12, 2015
Contributor

hpux735 Dec 12, 2015
Author Contributor

timbodeit Dec 12, 2015
Contributor

gribozavr Dec 12, 2015
Collaborator

timbodeit Dec 12, 2015
Contributor

gribozavr Dec 12, 2015
Collaborator

MagaTailor commented on `4bf81e0` Dec 13, 2015

modocache Dec 14, 2015
Collaborator

gribozavr Dec 14, 2015
Collaborator

modocache Dec 14, 2015
Collaborator

hpux735 Dec 14, 2015
Author Contributor

modocache Dec 14, 2015
Collaborator

hpux735 Dec 14, 2015
Author Contributor