R_ARM_GOT_PREL error when building Swift on Pi from source

Timothy_J_Wood · 2016-04-15T20:24:20.000Z

I was able to get Swift running on my Raspberry Pi using a variant of the instructions at <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so things like `associatedtype` don’t work nicely between Mac and Linux).

So, I thought I’d try building from source again hoping that the previous failure was resolved. But I’m still hitting the unimplemented relocation issue in LLVM’s RuntimeDyldELF.cpp, in RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is being requested is R_ARM_GOT_PREL.

I thought I read in my last go-round on this that this was a regression in LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.

Is there a trick to avoiding this issue in LLVM, or an existing patch somewhere that I can cherry-pick?

Thanks!

-tim

Joe_Groff · 2016-04-16T01:45:21.000Z

What linker are you using? GNU ld 2.26 in particular changed the behavior of protected visibility in a way that's incompatible with our usage, and we haven't fully implemented a workaround. You might try using gold or an older binutils, if that's what you're currently using.

-Joe

···

On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:

I was able to get Swift running on my Raspberry Pi using a variant of the instructions at <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so things like `associatedtype` don’t work nicely between Mac and Linux).

So, I thought I’d try building from source again hoping that the previous failure was resolved. But I’m still hitting the unimplemented relocation issue in LLVM’s RuntimeDyldELF.cpp, in RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is being requested is R_ARM_GOT_PREL.

I thought I read in my last go-round on this that this was a regression in LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.

Is there a trick to avoiding this issue in LLVM, or an existing patch somewhere that I can cherry-pick?

Michael_Gottesman · 2016-04-16T20:49:31.000Z

+CC Lang Hames (Just in case)

···

On Apr 15, 2016, at 6:45 PM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:

On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:

I was able to get Swift running on my Raspberry Pi using a variant of the instructions at <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so things like `associatedtype` don’t work nicely between Mac and Linux).

So, I thought I’d try building from source again hoping that the previous failure was resolved. But I’m still hitting the unimplemented relocation issue in LLVM’s RuntimeDyldELF.cpp, in RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is being requested is R_ARM_GOT_PREL.

I thought I read in my last go-round on this that this was a regression in LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.

Is there a trick to avoiding this issue in LLVM, or an existing patch somewhere that I can cherry-pick?

What linker are you using? GNU ld 2.26 in particular changed the behavior of protected visibility in a way that's incompatible with our usage, and we haven't fully implemented a workaround. You might try using gold or an older binutils, if that's what you're currently using.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

Timothy_J_Wood · 2016-04-17T20:55:31.000Z

I could have sworn I was using gold, but looking at my logs it was using the standard linker. Perhaps I’m remembering an attempt from the Swift 3 sources… Anyway, my current attempts are using this invocation now (though I’m getting other failures now):

utils/build-script -t -R -j 4 -- --use-gold-linker

Thanks!

-tim

···

On Apr 15, 2016, at 6:45 PM, Joe Groff <jgroff@apple.com> wrote:
What linker are you using? GNU ld 2.26 in particular changed the behavior of protected visibility in a way that's incompatible with our usage, and we haven't fully implemented a workaround. You might try using gold or an older binutils, if that's what you're currently using.

William_Dillon2 · 2016-04-16T21:23:42.000Z

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 <swift-dev@swift.org> wrote:

+CC Lang Hames (Just in case)

On Apr 15, 2016, at 6:45 PM, Joe Groff via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

I was able to get Swift running on my Raspberry Pi using a variant of the instructions at <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so things like `associatedtype` don’t work nicely between Mac and Linux).

So, I thought I’d try building from source again hoping that the previous failure was resolved. But I’m still hitting the unimplemented relocation issue in LLVM’s RuntimeDyldELF.cpp, in RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is being requested is R_ARM_GOT_PREL.

I thought I read in my last go-round on this that this was a regression in LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.

Is there a trick to avoiding this issue in LLVM, or an existing patch somewhere that I can cherry-pick?

What linker are you using? GNU ld 2.26 in particular changed the behavior of protected visibility in a way that's incompatible with our usage, and we haven't fully implemented a workaround. You might try using gold or an older binutils, if that's what you're currently using.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Michael_Gottesman · 2016-04-16T21:54:08.000Z

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.

I am not actually involved in this discussion beyond ensuring that Lang who works in this area is aware of it.

···

On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com> wrote:

- Will

On Apr 16, 2016, at 1:49 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

+CC Lang Hames (Just in case)

On Apr 15, 2016, at 6:45 PM, Joe Groff via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

I was able to get Swift running on my Raspberry Pi using a variant of the instructions at <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so things like `associatedtype` don’t work nicely between Mac and Linux).

So, I thought I’d try building from source again hoping that the previous failure was resolved. But I’m still hitting the unimplemented relocation issue in LLVM’s RuntimeDyldELF.cpp, in RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is being requested is R_ARM_GOT_PREL.

I thought I read in my last go-round on this that this was a regression in LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.

Is there a trick to avoiding this issue in LLVM, or an existing patch somewhere that I can cherry-pick?

What linker are you using? GNU ld 2.26 in particular changed the behavior of protected visibility in a way that's incompatible with our usage, and we haven't fully implemented a workaround. You might try using gold or an older binutils, if that's what you're currently using.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

Timothy_J_Wood · 2016-04-17T20:46:33.000Z

Ah, thanks! I was using <https://github.com/apple/swift-llvm/tree/swift-2.2-branch>, but will give your fork a try!

-tim

···

On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com> wrote:

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

William_Dillon2 · 2016-04-16T21:58:43.000Z

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 <mgottesman@apple.com> wrote:

On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com <mailto:william@housedillon.com>> wrote:

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.

I am not actually involved in this discussion beyond ensuring that Lang who works in this area is aware of it.

- Will

On Apr 16, 2016, at 1:49 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

+CC Lang Hames (Just in case)

On Apr 15, 2016, at 6:45 PM, Joe Groff via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

I was able to get Swift running on my Raspberry Pi using a variant of the instructions at <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so things like `associatedtype` don’t work nicely between Mac and Linux).

So, I thought I’d try building from source again hoping that the previous failure was resolved. But I’m still hitting the unimplemented relocation issue in LLVM’s RuntimeDyldELF.cpp, in RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is being requested is R_ARM_GOT_PREL.

I thought I read in my last go-round on this that this was a regression in LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.

Is there a trick to avoiding this issue in LLVM, or an existing patch somewhere that I can cherry-pick?

What linker are you using? GNU ld 2.26 in particular changed the behavior of protected visibility in a way that's incompatible with our usage, and we haven't fully implemented a workaround. You might try using gold or an older binutils, if that's what you're currently using.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

iachievedit · 2016-04-17T20:52:20.000Z

I'll join in Tim and try compiling again on the BeagleX15, it failed the other day but I forgot about using Wills LLVM

Joe

···

On Apr 17, 2016, at 3:46 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:

On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com> wrote:

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

Ah, thanks! I was using <https://github.com/apple/swift-llvm/tree/swift-2.2-branch>, but will give your fork a try!

-tim

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Timothy_Wood · 2016-04-18T06:33:08.000Z

I reset my Pi 3 to a fresh install of Jessie (2016-03-18), did the clang-3.6 install from <http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/> and tried building with the above mentioned branch of llvm. This fixed the spurious build failures I was seeing, but I’m hitting a persistent build failure now:

[939/1818] Building CXX object tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
FAILED: /usr/bin/clang++-3.6 -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/utils/TableGen -I/home/pi/Source/Swift/llvm/tools/clang/utils/TableGen -I/home/pi/Source/Swift/llvm/tools/clang/include -Itools/clang/include -Iinclude -I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3 -UNDEBUG -fno-exceptions -fno-rtti -MMD -MT tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o -MF tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o.d -o tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o -c /home/pi/Source/Swift/llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp
/home/pi/Source/Swift/llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp:1075:23: error: no viable conversion from 'ArrayRef<std::pair<Record *, SMRange>>' to 'ArrayRef<llvm::Record *>'
    ArrayRef<Record*> Bases = Search->getSuperClasses();
                      ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/Source/Swift/llvm/include/llvm/ADT/ArrayRef.h:32:9: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'ArrayRef<std::pair<Record *, SMRange> >' to 'const llvm::ArrayRef<llvm::Record *> &' for 1st argument
  class ArrayRef {
        ^
/home/pi/Source/Swift/llvm/include/llvm/ADT/ArrayRef.h:32:9: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'ArrayRef<std::pair<Record *, SMRange> >' to 'llvm::ArrayRef<llvm::Record *> &&' for 1st argument
  class ArrayRef {
...

I might try again tomorrow updating to a newer clang build, or maybe I should just wave the white flag and rewrite my tiny codebase in C++ instead of trying to use Swift here, and wait for it to be a bit more stable/supported.

-tim

···

On Apr 17, 2016, at 1:46 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:

On Apr 16, 2016, at 2:23 PM, William Dillon <william@housedillon.com <mailto:william@housedillon.com>> wrote:

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

Ah, thanks! I was using <https://github.com/apple/swift-llvm/tree/swift-2.2-branch>, but will give your fork a try!

-tim

Timothy_J_Wood · 2016-04-20T01:03:53.000Z

FWIW, last night I tried taking the current swift-llvm swift-2.2.branch and cherry picking your ARM_REL32/GOT_PREL patch atop it. This got *much* further through the build, but eventually failed while building the Swift standard library:

swift: /home/pi/Source/Swift/llvm/include/llvm/ADT/PointerIntPair.h:114: void llvm::PointerIntPair<swift::ProtocolConformance *, 2, swift::ConformanceKind, llvm::PointerLikeTypeTraits<swift::ProtocolConformance *> >::setPointerAndInt(PointerTy, IntType) [PointerTy = swift::ProtocolConformance *, IntBits = 2, IntType = swift::ConformanceKind, PtrTraits = llvm::PointerLikeTypeTraits<swift::ProtocolConformance *>]: Assertion `(PtrWord & ~PointerBitMask) == 0 && "Pointer is not sufficiently aligned"' failed.
…
1. While type-checking 'EnumerateSequence' at /home/pi/Source/Swift/swift/stdlib/public/core/Algorithm.swift:192:8
ninja: build stopped: subcommand failed.

-tim

···

On Apr 17, 2016, at 11:33 PM, Timothy Wood via swift-dev <swift-dev@swift.org> wrote:

I might try again tomorrow updating to a newer clang build, or maybe I should just wave the white flag and rewrite my tiny codebase in C++ instead of trying to use Swift here, and wait for it to be a bit more stable/supported.