Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

boz...@gmail.com> wrote:On Wed, Dec 9, 2015 at 7:05 PM, Dmitri Gribenko <griboz...@gmail.com> wrote:On Wed, Dec 9, 2015 at 3:05 PM, William Dillon via swift-dev<swift-dev@swift.org> wrote:Nick was correct in noting that __muloti4 wasn’t needed on 32-bit platforms.  I added a

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

hanks for looking into this! >> - Will >> >> >> >> On Dec 9, 2015, at 7:14 PM, Dmitri Gribenko wrote: >> >> On Wed, Dec 9, 2015 at 7:05 PM, Dmitri Gribenko wrote: >> >> On Wed, Dec 9, 2015 at 3:05 PM, William Dillon via swift-dev >

Re: [swift-dev] Ubuntu build error

I’ve been getting that, and a smattering of other memory exhaustion errors in my work with ARM. I can say that with a reasonable (10-20GB) swap file you should be able to build the release variant (-R) with 2GB or ram. I haven’t been able to successfully build the debug variant with 2GB of ram

Re: [swift-dev] Porting Swift to Linux aarch64 (arm64)

I’m on a limb here, but is it possible that the gold linker is causing issues, or is it required? - Will > On Dec 13, 2015, at 11:45 PM, Dmitri Gribenko via swift-dev > wrote: > > Hi, > > This weekend I have been playing with Swift on Linux on 64-bit arm. I > have summarized my findings in

Re: [swift-dev] Porting Swift to Linux aarch64 (arm64)

Thanks Dmitri, I’ve been reading cmake files all day, and noticing that some references to the gold linker (specifically this one in cmake/modules/AddSwift): 1058 # Handle gold linker flags for shared libraries. 1059 if(SWIFT_ENABLE_GOLD_LINKER AND SWIFTLIB_SINGLE_SHARED) 1060 if("${SWIF

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

32 003af914 _TMps13GeneratorType >>> >>> _TMps13GeneratorType ---> protocol descriptor for Swift.GeneratorType >>> >>> Dmitri >>> >>> On Wed, Dec 9, 2015 at 7:25 PM, William Dillon >>> wrote: >>>> I’m looking at

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

// Swift.NonObjectiveCBase.__deallocating_deinit hello.sil-arm:sil_witness_table NonObjectiveCBase: AnyObject module Swift > On Dec 14, 2015, at 6:22 PM, Dmitri Gribenko wrote: > > On Mon, Dec 14, 2015 at 5:57 PM, William Dillon via swift-dev > wrote: >> I’m still stuck on thi

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

via swift-dev > wrote: > > On Tue, Dec 15, 2015 at 2:39 AM, Nick Wellnhofer via swift-dev > mailto:swift-dev@swift.org>> wrote: >> On 10/12/2015 00:05, William Dillon via swift-dev wrote: >>> >>> At this point, the compiler and standard library are all built,

Re: [swift-dev] [swift-users] Cross Compiling Swift for Bare Metal?

Though it might sound a little silly (because why not run linux), but starting with a beagle bone black would not be a terrible way to begin with bare metal work. It has plenty of RAM, you know that LLVM writes good machine code for it, it has JTAG accessible, it’s inexpensive, etc... This wou

[swift-dev] bugs.swift.org usage

Now that I’ve published a tarball of the ARM swift compiler, I’m getting some messages about this or that not working. I’m curious about the intended usage/audience of bugs.apple.com . Should I encourage people to file bug reports, or do you only want bugs relating to t

[swift-dev] LLDB Invalid address (32 bit arm)

Hi all, I’m working on addressing issues that are preventing lldb from compiling on 32-bit arm platforms. Many warnings are generated by the definition of LLDB_INVALID_ADDRESS as UINT64_MAX. Ultimately, it stems from the fact that size_t is 32 bits, which changes it to the value to UINT32_MAX

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

15 at 3:15 PM, Dmitri Gribenko via swift-lldb-dev > mailto:swift-lldb-...@swift.org>> wrote: > + swift-lldb-dev > > On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev > mailto:swift-dev@swift.org>> wrote: > > Hi all, > > > > I’m working on ad

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

> On Jan 4, 2016, at 9:17 AM, Todd Fiala wrote: > > I added some more comments to the pull request that I Think is related to > this thread here: > https://github.com/apple/swift-lldb/pull/3 > > > The archspec changes really need to happen in llvm.

Re: [swift-dev] Cortex M0

I’m no expert on the M0, but I looked it up. It seems to be Thumb(2) only, and I don’t think thumb support in linux is finished. This is of course in addition to the *significant* constraints that Dmitri noted. - Will > On Mar 15, 2016, at 1:11 PM, Dmitri Gribenko via swift-dev > wrote: >

Re: [swift-dev] Cortex M0

> On Mar 15, 2016, at 1:22 PM, Tanner Nelson wrote: > > >> On Mar 15, 2016, at 4:14 PM, William Dillon wrote: >> >> I’m no expert on the M0, but I looked it up. It seems to be Thumb(2) only, >> and I don’t think thumb support in linux is finished. This is of course in >> addition to the *s

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

> > Phew. Well I finally got everything ready to where I could bisect > binutils. I won't bore with the details of what it took to actually be > able to bisect binutils (unless someone actually wants to know). > I would be interested if it’s not too much trouble. I’ve been in a similar predic

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

WOW! That is fantastic! Thanks for sharing. - Will > On Mar 22, 2016, at 1:36 PM, Ryan Lovelett wrote: > > On Tue, Mar 22, 2016, at 01:26 PM, William Dillon wrote: >> >>> >>> Phew. Well I finally got everything ready to where I could bisect >>> binutils. I won't bore with the details of wha

Re: [swift-dev] Error with SwiftGlibs building for arm-linux

I believe the bug still exists. I tried to build armv7 on native hardware yesterday and hit this bug. I haven't had time to look into it at all though. - Will > On Mar 31, 2016, at 1:11 PM, Iliya Trub via swift-dev > wrote: > > Dear colleagues > What about my last message from this thread?

Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on Pi from source

What LLVM are you using? You have to use the one from my github (and the arm branch) or it won't work: https://github.com/hpux735/swift-llvm/tree/arm I haven't had time to upstream the changes to LLVM. - Will > On Apr 16, 2016, at 1:49 PM, Michael Gottesman via swift-dev > wrote: > > +CC L

Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on Pi from source

Lang is, he was helping me write the LLVM tests, but I'm stacked at the moment. > On Apr 16, 2016, at 2:54 PM, Michael Gottesman wrote: > > >> On Apr 16, 2016, at 2:23 PM, William Dillon > > wrote: >> >> What LLVM are you using? >> >> You have to use the one fr

Re: [swift-dev] test-repl-glibc failure

For me an objection to xfailing this is that it really isn't an expected fail. Linux is actually broken. > On Apr 22, 2016, at 10:46 AM, Daniel Dunbar via swift-dev > wrote: > > I saw that, my question is specifically how this is going to be resolved. We > shouldn't have failures on the bots

Re: [swift-dev] Requiring gold linker for Linux targets?

I'm in favor. The current disparate use of linkers overly complicates the build scripts, and given that BFD seems to be a liability, I think it makes sense to transition. In the interest of full disclosure, I don't fully understand all the implications of this change, especially on x86. - Wil

Re: [swift-dev] [RFC] Finer grained OS checks

Hi all, I Agree with Saleem that this is a worthwhile discussion, and I think I agree with Jordan that word environment seems a little bit wrong to me. Following the discussion, it feels to me like what we're really concerned about is libc and ABI. Most of the examples that Saleem gave seems t

Re: [swift-dev] Android: Build error: No such module "SwiftGlibc"

I haven't succeeded in re-creating the requisite magic since the release of Swift 3. The full moon is coming, though, so we may see success soon. In all seriousness, what has worked in the past has been using the swift-3.0 branch, but also, not trying to build everything at once. I'll start wi

Re: [swift-dev] More Swift 3 Raspberry Pi 2 build problems

> On Sep 20, 2016, at 1:01 PM, Eric Wing wrote: > > On 9/20/16, william wrote: >> Hi Eric, >> >> Can you check whether what you're building on has this commit? >> https://github.com/apple/swift-package-manager/commit/0268214b5477ca338b502c90aaa3e9ba50b68e18 >>

Re: [swift-dev] More Swift 3 Raspberry Pi 2 build problems

Hi Eric, I'm glad you're making progress. I've seen the swift-autolink-extract issue before. For some reason that symlink to swift isn't being made for you. You can try making a new symlink to `swift` and see if that gets you forward. I'd recommend using the github swift-arm repos, specifica

Re: [swift-dev] State of Swift on Linux/ARM

It is better in general, yes. However, there are details that make having a separate repo desirable. Think of it more as a place for arm-specific patches to get merged in very quickly and easily while the official swift PR system is running. Because arm (32-bit specifically) is such an odd du

[swift-dev] Minimal clang to support swift?

HI all, I'm working on a resource-constrained embedded system, and I'd like to reduce the size of my swift install as much as possible.  In deployment, I'll need to figure out what a non-compiling swift support install looks like, but that's not the question for today.  Currently, I'd like to h

Re: [swift-dev] Glibc.swift: error: no such module 'SwiftGlibc'

Thanks so much for getting to the bottom of this! I was getting by with hacks to get around this for a while.  I'm very glad we have a reproducible change that triggers. - Will On November 10, 2016 at 1:34:27 PM, Eric Wing via swift-dev (swift-dev@swift.org) wrote: On 11/9/16, Eric Wing wrot

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

I think Greg is right.  I’ve seen this before, and the way I fixed it was by fixing the Xcode configuration, specifically relating to the command-line tools. - Will On December 8, 2016 at 1:24:59 PM, Greg Parker via swift-dev (swift-dev@swift.org) wrote: On Dec 8, 2016, at 7:28 AM, Frederick

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

The Apple folks might know better and correct me, but I’m pretty certain you don’t want to be using any toolchains in /opt/local.  It all needs to be from the Xcode.app. - Will On December 8, 2016 at 2:14:42 PM, Frederick Kellison-Linn via swift-dev (swift-dev@swift.org) wrote: The output of

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

What if you try: which ld And, what’s your PATH? On December 8, 2016 at 2:19:20 PM, Frederick Kellison-Linn (fred...@me.com) wrote: Yeah that seems wrong to me as well. Do you know how I can change the linker that clang invokes? Freddy On Dec 8, 2016, at 5:16 PM, William Dillon wrote: The

Re: [swift-dev] Build failing on CMakeTestCCompiler.cmake

Try it with a PATH that does not include /opt/local/* I haven’t build on MacOS in a long time, so I can’t say with any more detail how the tools (clang, ld, etc.) are chosen when building swift ¯\_(ツ)_/¯  Good luck :) - Will On December 8, 2016 at 6:05:12 PM, Frederick Kellison-Linn (fred...@me

Re: [swift-dev] Porting Swift to Haiku

Hi Joseph, That’s awesome!!  I love BeOS back in the day. I work on the 32-bit swift port for ARM/Linux.  Swift works just fine with 32-bit systems. Good luck! - Will On May 7, 2017 at 2:19:15 PM, Joseph Calvin Hill via swift-dev (swift-dev@swift.org) wrote: Hello swift-dev! I'm one of th

Re: [swift-dev] Adding Ubuntu 32-bit support

If I remember correctly, Float80 is also unimplemented in 32-bit arm. I would suggest adding a conditional compilation block to disable this code for 32-bit. I'm not that familiar with gyb, however, so I don't know what that looks like. Cheers, - Will > On Nov 27, 2017, at 1:08 AM, Ionel Lesc

Re: [swift-dev] Default deployment target for swiftc

It would be my assumption that it would build for the currently running OS. It would be very confusing to me to have availability checks failing for an OS version lower that what I'm using. I'm sure that I would be swearing for a few hours before I finally found the obscure documentation that

Re: [swift-dev] Default deployment target for swiftc

ailability directives, if needed). > > On Mon, Nov 27, 2017 at 4:53 PM William Dillon via swift-dev > mailto:swift-dev@swift.org>> wrote: > It would be my assumption that it would build for the currently running OS. > It would be very confusing to me to have availability ch