search

uraimo / buildSwiftOnARM

All you need to build Swift on a RaspberryPi or other ARM boards, updated to Swift 5.1.5
489 stars 37 forks source link

[arm32][5.x] The Swift toolchain does not contain clang/libicu #60

Open uraimo opened 4 years ago

uraimo commented 4 years ago

The usual preset buildbot_linux,no_test does not work for arm32 right now, near the end of the process SPM complains that it can't find libicu (correct, it's not being copied over) when building the bootstrap SPM.

The result of this is that Swift 5.x on armv6/armv7 still requires the clang and libicu dependencies, but depending on an old system version of clang or an obsolete release of libicu (e.g. on distributions derived from Stretch/Buster) leads to issues like #148.

uraimo commented 4 years ago

Skipping SPM and specifying a "minimal" set of build options similar to buildbot_linux,no_test the toolchain has everything we expect (minus SPM obviously). Considering that we kept the build command more or less the same for the last few years, we were missing a few new options and more importantly --llvm-install-components=, that's what actually specifies which llvm sub-components should be installed.

./swift/utils/build-script \
    -R \
    --build-subdir buildbot_linux --install-prefix=/usr \
    --install-destdir=${INSTALL_DIR} --installable-package=${PACKAGE} \
    --lldb --llbuild --xctest --libicu --libcxx --foundation --libdispatch \
    --skip-test-cmark --skip-test-lldb --skip-test-swift --skip-test-llbuild --skip-test-swiftpm --skip-test-xctest --skip-test-foundation --skip-test-libdispatch --skip-test-playgroundsupport --skip-test-libicu --skip-test-indexstore-db --skip-test-sourcekit-lsp \
    -- --install-libdispatch --install-foundation --install-swift --install-lldb --install-llbuild --install-xctest --install-libicu --install-libcxx \
    '--swift-install-components=autolink-driver;compiler;clang-builtin-headers;stdlib;swift-remote-mirror;sdk-overlay;dev' \
    '--llvm-install-components=llvm-cov;llvm-profdata;clang;clang-headers;compiler-rt;clangd' \
    --build-swift-static-stdlib --build-swift-static-sdk-overlay
uraimo commented 4 years ago

Note to self: Even the silly workaround of building without SPM using the command above, over an install dir already populated with an SPM generated the usual way doesn't work. Still get this: 

./buildSwiftOnARM/install/usr/bin/swift build
/home/buildSwiftOnARM/install/usr/bin/swift-build: error while loading shared libraries: libicudataswift.so.61: cannot open shared object file: No such file or directory

because:

$ ldd /home/buildSwiftOnARM/install/usr/bin/swift-build
        linux-vdso.so.1 (0xbee28000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb69a5000)
        ...
        libatomic.so.1 => /usr/lib/arm-linux-gnueabihf/libatomic.so.1 (0xb56cc000)
        libicuuc.so.60 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.60 (0xb5596000)
        libicui18n.so.60 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.60 (0xb53cd000)
        libicuucswift.so.61 => /home/buildSwiftOnARM/install/usr/bin/../lib/swift/linux/libicuucswift.so.61 (0xb5218000)
        libicui18nswift.so.61 => /home/buildSwiftOnARM/install/usr/bin/../lib/swift/linux/libicui18nswift.so.61 (0xb4f6f000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb4f59000)
        libllbuild.so => /home/buildSwiftOnARM/install/usr/bin/../lib/swift/pm/llbuild/libllbuild.so (0xb4df1000)
        libicudata.so.60 => /usr/lib/arm-linux-gnueabihf/libicudata.so.60 (0xb3438000)
        libicudataswift.so.61 => not found
        libicudataswift.so.61 => not found

How come it links to libicudata.so.60,libicuuc.so.60,libicui18n.so.60?

But at least it's there:

$ ls /home/buildSwiftOnARM/install/usr/lib/swift/linux/
armv7/                        libicudataswift.so            libicuucswift.so.61
libBlocksRuntime.so           libicudataswift.so.61         libicuucswift.so.61.1
libFoundation.so              libicudataswift.so.61.1       libswiftCore.so
libFoundationNetworking.so    libicui18nswift.so            libswiftDispatch.so
libFoundationXML.so           libicui18nswift.so.61         libswiftGlibc.so
libXCTest.so                  libicui18nswift.so.61.1       libswiftRemoteMirror.so
libdispatch.so                libicuucswift.so              libswiftSwiftOnoneSupport.so

All the variables related to libicu location seem to be in swift/utils/build-script-impl, swift/lib/Driver/CMakeLists.txt or swift/utils/gen-static-stdlib-link-args (e.g. ICU_UC_LIBRARIES).

jmartinesp commented 4 years ago

You probably already know this, but I believe the issue with libicudata is in the icu side, not swift. If I build just the icu project and then try ldd libicuuc.so:

pi@raspberrypi:~/buildSwiftOnARM/icu/icu4c/source/stubdata $ ldd ../lib/libicuuc.so
    linux-vdso.so.1 (0xbee93000)
    /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6db0000)
    libicudata.so.65 => not found
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6d86000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6d73000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6cf1000)
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6baa000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6b7d000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6a2f000)
    /lib/ld-linux-armhf.so.3 (0xb6f94000)

However, when libcuuc.so is built, icu's libicudata stub is already built and present in icu/icu4c/sources/stubdata, which appears in the libicuuc build command:

clang++ -O3  -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11  -Qunused-arguments -Wno-parentheses-equality -Wglobal-constructors   -shared -Wl,-Bsymbolic -Wl,-soname -Wl,libicuuc.so.65 -o ../lib/libicuuc.so.65.1 errorcode.o putil.o umath.o utypes.o uinvchar.o umutex.o ucln_cmn.o uinit.o uobject.o cmemory.o charstr.o cstr.o udata.o ucmndata.o udatamem.o umapfile.o udataswp.o utrie_swap.o ucol_swp.o utrace.o uhash.o uhash_us.o uenum.o ustrenum.o uvector.o ustack.o uvectr32.o uvectr64.o ucnv.o ucnv_bld.o ucnv_cnv.o ucnv_io.o ucnv_cb.o ucnv_err.o ucnvlat1.o ucnv_u7.o ucnv_u8.o ucnv_u16.o ucnv_u32.o ucnvscsu.o ucnvbocu.o ucnv_ext.o ucnvmbcs.o ucnv2022.o ucnvhz.o ucnv_lmb.o ucnvisci.o ucnvdisp.o ucnv_set.o ucnv_ct.o resource.o uresbund.o ures_cnv.o uresdata.o resbund.o resbund_cnv.o ucurr.o localebuilder.o localeprioritylist.o messagepattern.o ucat.o locmap.o uloc.o locid.o locutil.o locavailable.o locdispnames.o locdspnm.o loclikely.o locresdata.o lsr.o loclikelysubtags.o locdistance.o localematcher.o bytestream.o stringpiece.o bytesinkutil.o stringtriebuilder.o bytestriebuilder.o bytestrie.o bytestrieiterator.o ucharstrie.o ucharstriebuilder.o ucharstrieiterator.o dictionarydata.o edits.o appendable.o ustr_cnv.o unistr_cnv.o unistr.o unistr_case.o unistr_props.o utf_impl.o ustring.o ustrcase.o ucasemap.o ucasemap_titlecase_brkiter.o cstring.o ustrfmt.o ustrtrns.o ustr_wcs.o utext.o unistr_case_locale.o ustrcase_locale.o unistr_titlecase_brkiter.o ustr_titlecase_brkiter.o normalizer2impl.o normalizer2.o filterednormalizer2.o normlzr.o unorm.o unormcmp.o loadednormalizer2impl.o chariter.o schriter.o uchriter.o uiter.o patternprops.o uchar.o uprops.o ucase.o propname.o ubidi_props.o characterproperties.o ubidi.o ubidiwrt.o ubidiln.o ushape.o uscript.o uscript_props.o usc_impl.o unames.o utrie.o utrie2.o utrie2_builder.o ucptrie.o umutablecptrie.o bmpset.o unisetspan.o uset_props.o uniset_props.o uniset_closure.o uset.o uniset.o usetiter.o ruleiter.o caniter.o unifilt.o unifunct.o uarrsort.o brkiter.o ubrk.o brkeng.o dictbe.o filteredbrk.o rbbi.o rbbidata.o rbbinode.o rbbirb.o rbbiscan.o rbbisetb.o rbbistbl.o rbbitblb.o rbbi_cache.o serv.o servnotf.o servls.o servlk.o servlkf.o servrbf.o servslkf.o uidna.o usprep.o uts46.o punycode.o util.o util_props.o parsepos.o locbased.o cwchar.o wintz.o dtintrv.o ucnvsel.o propsvec.o ulist.o uloc_tag.o icudataver.o icuplug.o sharedobject.o simpleformatter.o unifiedcache.o uloc_keytype.o ubiditransform.o pluralmap.o static_unicode_sets.o restrace.o -L../lib -L../stubdata -licudata -lpthread -ldl -lm
jmartinesp commented 4 years ago

I think I got it to build with --libicu.

First, I modified ./icu/icu4c/source/config/mh-linux as explained here, removing the LDFLAGSICUDT variable altogether or assigning nothing to it:

https://www.raspberrypi.org/forums/viewtopic.php?p=392071&sid=6138a1969a19cbc0be9d0d8641502aae#p392071

Then I tried building without the --libicu modifier and I got the swift-build: error while loading shared libraries: libicudata.so.65: cannot open shared object file: No such file or directory error. However, I copied libicudata.so* to /usr/lib, as it's the prefix provided in build.sh and the error was gone and ldd showed libicudata.so.65 properly linked.

I tried again with --libicu, got the same error, copied libicuswift* to /usr/lib and:

pi@raspberrypi:~/buildSwiftOnARM $ ldd build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/swift-build
    linux-vdso.so.1 (0xbebe5000)
    /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6a3c000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6a12000)
    libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0xb69ff000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb69ec000)
    libswiftCore.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/swift-linux-armv7/lib/swift/linux/libswiftCore.so (0xb6448000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb63c6000)
    libswiftGlibc.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/swift-linux-armv7/lib/swift/linux/libswiftGlibc.so (0xb63b9000)
    libFoundation.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/../lib/swift/linux/libFoundation.so (0xb5ae1000)
    libswiftDispatch.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/../lib/swift/linux/libswiftDispatch.so (0xb5ab7000)
    libdispatch.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/../lib/swift/linux/libdispatch.so (0xb5a74000)
    libBlocksRuntime.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/../lib/swift/linux/libBlocksRuntime.so (0xb5a61000)
    libllbuildSwift.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/llbuild-linux-armv7/lib/libllbuildSwift.so (0xb5a43000)
    libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0 (0xb593b000)
    libncurses.so.6 => /lib/arm-linux-gnueabihf/libncurses.so.6 (0xb590d000)
    libtinfo.so.6 => /lib/arm-linux-gnueabihf/libtinfo.so.6 (0xb58dc000)
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb5795000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb5768000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb561a000)
    /lib/ld-linux-armhf.so.3 (0xb6fc2000)
    libatomic.so.1 => /usr/lib/arm-linux-gnueabihf/libatomic.so.1 (0xb5601000)
    libicuuc.so.65 => /usr/local/lib/libicuuc.so.65 (0xb5432000)
    libicui18n.so.65 => /usr/local/lib/libicui18n.so.65 (0xb516a000)
    libicuucswift.so.65 => /usr/lib/libicuucswift.so.65 (0xb4f95000)
    libicui18nswift.so.65 => /usr/lib/libicui18nswift.so.65 (0xb4cbd000)
    librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb4ca4000)
    libllbuild.so => /home/pi/buildSwiftOnARM/build/buildbot_linux/llbuild-linux-armv7/lib/libllbuild.so (0xb4b38000)
    libicudata.so.65 => /usr/lib/libicudata.so.65 (0xb3078000)
    libicudataswift.so.65 => /usr/lib/libicudataswift.so.65 (0xb15b8000)

This however did not solve the issues with Strings manipulation being really time expensive on 32bit as I hope it would (issue #63), so I guess it's a different issue altogether.

Kaiede commented 4 years ago

If the library needs to be moved to /usr/lib to work, then something related to the RUNPATH is likely not correct somewhere. Because really all that moving files there does is put it in the LDPATH, but Swift is designed to rely on RUNPATH to make a self-contained tarball.

I'd be very curious what you get from chrpath build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/swift-build (may need to install the tool first), and how that compares to where libicudataswift.so.65 and libicudata.so.65 wind up in the build/ folder.

Because right now it looks the only paths for swift-build (from 5.1.5) are:

So if libicudata is under some other path instead, it should be clearer what's going on at that point.

jmartinesp commented 4 years ago

The chrpath command returns:

pi@raspberrypi:~/buildSwiftOnARM $ chrpath build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/swift-build
build/buildbot_linux/swiftpm-linux-armv7/armv7-unknown-linux-gnueabihf/release/swift-build: RUNPATH=/home/pi/buildSwiftOnARM/build/buildbot_linux/swift-linux-armv7/lib/swift/linux:/usr/lib/swift:$ORIGIN:$ORIGIN/../lib/swift/linux:/home/pi/buildSwiftOnARM/build/buildbot_linux/swiftpm-linux-armv7/.bootstrap/lib/swift/linux:$ORIGIN/../lib/swift/pm/llbuild:/home/pi/buildSwiftOnARM/build/buildbot_linux/llbuild-linux-armv7/lib