diff options
3 files changed, 129 insertions, 0 deletions
diff --git a/testing/emscripten-fastcomp/APKBUILD b/testing/emscripten-fastcomp/APKBUILD new file mode 100644 index 0000000000..8532d923d1 --- /dev/null +++ b/testing/emscripten-fastcomp/APKBUILD @@ -0,0 +1,79 @@ +# Contributor: Jakub Jirutka <jakub@jirutka.cz> +# Maintainer: Jakub Jirutka <jakub@jirutka.cz> + +# NOTE: This is a fork of LLVM project needed for emscripten. It provides +# JSBackend and WebAssembly, these will be hopefully someday merged into +# upstream LLVM. +# TODO: Remove unneeded binaries. +pkgname=emscripten-fastcomp +# Keep in sync with package emscripten! +pkgver=1.37.9 +pkgrel=0 +pkgdesc="The Clang + LLVM backend for Emscripten" +url="https://kripken.github.io/emscripten-site/" +arch="all" +license="UOI-NCSA" +depends="python2" +makedepends="cmake paxmark zlib-dev" +source="$pkgname.tar.gz::https://github.com/kripken/$pkgname/archive/$pkgver.tar.gz + $pkgname-clang.tar.gz::https://github.com/kripken/$pkgname-clang/archive/$pkgver.tar.gz + fix-build-with-musl-libc.patch + fix-DynamicLibrary-to-build-with-musl-libc.patch" +builddir="$srcdir/$pkgname-$pkgver" +options="!check" # some tests are broken, don't bother with it for now + +_prefix="/usr/lib/$pkgname" +ldpath="$_prefix/lib" + +prepare() { + ln -sf ../../$pkgname-clang-$pkgver "$builddir"/tools/clang + + default_prepare +} + +build() { + mkdir -p "$builddir"/build + cd "$builddir"/build + + # XXX: Is it a good idea to omit X86 in LLVM_TARGETS_TO_BUILD? + # https://github.com/kripken/emscripten-fastcomp/issues/174 + cmake .. \ + -DCMAKE_BUILD_TYPE=Release \ + -DCMAKE_INSTALL_PREFIX="$_prefix" \ + -DCMAKE_CXX_FLAGS="$CXXFLAGS" \ + -DCMAKE_C_FLAGS="$CFLAGS" \ + -DPYTHON_EXECUTABLE=/usr/bin/python2 \ + -DLLVM_HOST_TRIPLE="$CHOST" \ + -DLLVM_BUILD_LLVM_DYLIB=ON \ + -DLLVM_LINK_LLVM_DYLIB=ON \ + -DLLVM_TARGETS_TO_BUILD=JSBackend \ + -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly \ + -DLLVM_BUILD_RUNTIME=OFF \ + -DLLVM_INCLUDE_EXAMPLES=OFF \ + -DLLVM_ENABLE_ZLIB=ON \ + -DCLANG_INCLUDE_EXAMPLES=OFF + make -j ${JOBS:-2} + + paxmark m bin/llvm-rtdyld \ + bin/lli \ + bin/lli-child-target +} + +package() { + cd "$builddir"/build + make install DESTDIR="$pkgdir" + + cd "$pkgdir"/$_prefix + + # emcc -v expects this file to exist. + cp ../emscripten-version.txt . + + # Remove unneeded files and clutter. + rm -r include libexec share lib/clang lib/cmake + rm lib/*.a bin/*-test +} + +sha512sums="443d22163866a409b6218bb686d52b845051350ef4af546e2d52ffaca03ed363f3cbf8f8e61b7fc28c1e1007d7e2789bfd74d91159deff46e3c6e1913ffebf34 emscripten-fastcomp.tar.gz +5c1fae88e87575571fef767f9c3d664c0eed106d566517871503c75cb5e31777d5fd5773f914fbe932abde3b42870b25e4ca58cf458ceecd0f9a7a50e7d86af9 emscripten-fastcomp-clang.tar.gz +5596bb1b4d4f7da8fef5f7e85a50de797dd88c1d93c7fcc9ff585093fd56d292222496e8e28e6a7d90effcfbf11c486636025646d65ba928fcb52352d1eb6336 fix-build-with-musl-libc.patch +01c0f994eb364fc0b02f7c97268f0bc470ed9d404bb2c013196005a6c0be91c9634f092aa262fc5c4e7ae72e36140f259efe9d8ec3a613f4b9aa7aa7b4b57759 fix-DynamicLibrary-to-build-with-musl-libc.patch" diff --git a/testing/emscripten-fastcomp/fix-DynamicLibrary-to-build-with-musl-libc.patch b/testing/emscripten-fastcomp/fix-DynamicLibrary-to-build-with-musl-libc.patch new file mode 100644 index 0000000000..7d9dc855b0 --- /dev/null +++ b/testing/emscripten-fastcomp/fix-DynamicLibrary-to-build-with-musl-libc.patch @@ -0,0 +1,24 @@ +From: Natanael Copa <ncopa@alpinelinux.org> +Date: Thu, 18 Feb 2016 15:33:21 +0100 +Subject: [PATCH] Fix DynamicLibrary to build with musl libc + +stdin/out/err is part of the libc and not the kernel so we check for the +specific libc that does the unexpected instead of linux. + +This is needed for making it build with musl libc. + +--- a/lib/Support/DynamicLibrary.cpp ++++ b/lib/Support/DynamicLibrary.cpp +@@ -140,10 +140,10 @@ void* DynamicLibrary::SearchForAddressOfSymbol(const char *symbolName) { + #define EXPLICIT_SYMBOL(SYM) \ + if (!strcmp(symbolName, #SYM)) return &SYM + +-// On linux we have a weird situation. The stderr/out/in symbols are both ++// On GNU libc we have a weird situation. The stderr/out/in symbols are both + // macros and global variables because of standards requirements. So, we + // boldly use the EXPLICIT_SYMBOL macro without checking for a #define first. +-#if defined(__linux__) and !defined(__ANDROID__) ++#if defined(__GLIBC__) + { + EXPLICIT_SYMBOL(stderr); + EXPLICIT_SYMBOL(stdout); diff --git a/testing/emscripten-fastcomp/fix-build-with-musl-libc.patch b/testing/emscripten-fastcomp/fix-build-with-musl-libc.patch new file mode 100644 index 0000000000..223b7306db --- /dev/null +++ b/testing/emscripten-fastcomp/fix-build-with-musl-libc.patch @@ -0,0 +1,26 @@ +From: Natanael Copa <ncopa@alpinelinux.org> +Date: Thu, 18 Feb 2016 10:33:04 +0100 +Subject: [PATCH] Fix build with musl libc + +On musl libc the fopen64 and fopen are the same thing, but for +compatibility they have a `#define fopen64 fopen`. Same applies for +fseek64, fstat64, fstatvfs64, ftello64, lstat64, stat64 and tmpfile64. + +--- a/include/llvm/Analysis/TargetLibraryInfo.h ++++ b/include/llvm/Analysis/TargetLibraryInfo.h +@@ -18,6 +18,15 @@ + #include "llvm/IR/Module.h" + #include "llvm/Pass.h" + ++#undef fopen64 ++#undef fseeko64 ++#undef fstat64 ++#undef fstatvfs64 ++#undef ftello64 ++#undef lstat64 ++#undef stat64 ++#undef tmpfile64 ++ + namespace llvm { + /// VecDesc - Describes a possible vectorization of a function. + /// Function 'VectorFnName' is equivalent to 'ScalarFnName' vectorized |