Initially I had an issue building due to a discrepancy with uint64 type in darling/platform-include/i386/types.h with the one on my system. I resolved it by changing it to the following
Line 46
#ifndef __LP64__
typedef long long __int64_t;
typedef unsigned long long __uint64_t;
#else
#undef __int64_t
#undef __uint64_t
typedef long int __int64_t;
typedef unsigned long int __uint64_t;
#endif /* !__LP64__ */
But now I get a new build error farther along which I can't seem to find any info about.
/home/duislingr/build/darling/src/libc/stdtime/FreeBSD/time32.c:47:1: error:
conflicting types for '_time64_to_time'
_time64_to_time(__int64_t t64)
^
/home/duislingr/build/darling/src/libc/include/timeconv.h:54:8: note: previous
declaration is here
time_t _time64_to_time(int64_t t64);
^
/home/duislingr/build/darling/src/libc/stdtime/FreeBSD/time32.c:57:1: error:
conflicting types for '_time_to_time64'
_time_to_time64(time_t t)
^
/home/duislingr/build/darling/src/libc/include/timeconv.h:55:9: note: previous
declaration is here
int64_t _time_to_time64(time_t t);
^
If its of any note the Arch system is Apricity OS and is running 4.10 kernel.
DuIslingr
All 41 comments
Could you please show us the original error, prior to modifying i386/types.h?
LubosD
on 23 Mar 2017
Heres a full build log of the original error:
https://ghostbin.com/paste/e9u65
Heres full build log with my fix applied if that helps at all.
https://ghostbin.com/paste/e6fmv
DuIslingr
on 23 Mar 2017
I got similar issues before. There are endless conflicts between Linux headers in /usr/include and Darwin headers in darling. I believe using-machos-experiment is the way to go. Currently that branch results in mysterious SIGSEGV errors. The simplest workaround is installing linux-lts. For other workarounds, see #259.
yan12125
on 25 Mar 2017
Unless what is being built isn't in the prefix (darling.c, etc) there is no reason to search /usr/include for headers.
ahyattdev
on 25 Mar 2017
Well the thing is the second set of errors regarding time is not from headers from linux. its saying its defined twice in darlings own headers which i dont understand.
DuIslingr
on 25 Mar 2017
What version of clang are you using?
ahyattdev
on 25 Mar 2017
@ahyattdev clang 3.9.1 is what was currently installed last i tested.
Edit: I found the arch aur package but the same issues still occurs with that even though it installed additional dependencies i apparently needed.
@X0rg You can update the package and remove the binutils <2.27 dependency. the bug was fixed in 2.28
DuIslingr
on 26 Mar 2017
@DuIslingr: Yup, sorry, I forgot to do it previously. That's done, but I'm sorry, I don't have time to try to build this package.
X0rg
on 26 Mar 2017
@yan12125 So i tried your suggestion of building machos experiment but i get a different set of errors
In file included from /home/duislingr/build/darling/src/external/libpthread/src/pthread_atfork.c:24:
In file included from /home/duislingr/build/darling/src/external/libpthread/src/internal.h:105:
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:473:18: warning:
implicit declaration of function 'atomic_compare_exchange_strong_explicit'
is invalid in C99 [-Wimplicit-function-declaration]
if (!OSLOCK_STD(atomic_compare_exchange_strong_explicit)(
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:475:15: error:
use of undeclared identifier 'memory_order_acquire'
OSLOCK_STD(memory_order_acquire),
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:476:15: error:
use of undeclared identifier 'memory_order_relaxed'
OSLOCK_STD(memory_order_relaxed))) {
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:507:15: error:
use of undeclared identifier 'memory_order_acquire'
OSLOCK_STD(memory_order_acquire),
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:508:15: error:
use of undeclared identifier 'memory_order_relaxed'
OSLOCK_STD(memory_order_relaxed))) {
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:542:15: error:
use of undeclared identifier 'memory_order_acquire'
OSLOCK_STD(memory_order_acquire), OSLOCK_STD(mem...
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:542:49: error:
use of undeclared identifier 'memory_order_relaxed'
OSLOCK_STD(memory_order_acquire), OSLOCK_STD(mem...
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:565:15: error:
use of undeclared identifier 'memory_order_release'
OSLOCK_STD(memory_order_release),
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:566:15: error:
use of undeclared identifier 'memory_order_relaxed'
OSLOCK_STD(memory_order_relaxed))) {
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:610:15: error:
use of undeclared identifier 'memory_order_acquire'
OSLOCK_STD(memory_order_acquire),
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:611:15: error:
use of undeclared identifier 'memory_order_relaxed'
OSLOCK_STD(memory_order_relaxed))) {
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:636:15: error:
use of undeclared identifier 'memory_order_release'
OSLOCK_STD(memory_order_release),
^
/home/duislingr/build/darling/src/external/libplatform/include/os/lock_private.h:637:15: error:
use of undeclared identifier 'memory_order_relaxed'
OSLOCK_STD(memory_order_relaxed))) {
^
In file included from /home/duislingr/build/darling/src/external/libpthread/src/pthread_atfork.c:24:
/home/duislingr/build/darling/src/external/libpthread/src/internal.h:376:9: warning:
incompatible integer to pointer conversion returning 'uint64_t' (aka
'unsigned long long') from a function with result type 'pthread_t'
(aka 'struct _pthread *') [-Wint-conversion]
return (_pthread_self_direct())->thread_id;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/duislingr/build/darling/src/external/libpthread/src/internal.h:529:9: warning:
incompatible pointer to integer conversion returning 'void *' from a
function with result type 'mach_port_t' (aka 'unsigned int')
[-Wint-conversion]
return t->tsd[_PTHREAD_TSD_SLOT_MACH_THREAD_SELF];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/duislingr/build/darling/src/external/libpthread/src/internal.h:539:45: warning:
incompatible integer to pointer conversion assigning to 'void *' from
'mach_port_t' (aka 'unsigned int') [-Wint-conversion]
t->tsd[_PTHREAD_TSD_SLOT_MACH_THREAD_SELF] = p;
^ ~
In file included from /home/duislingr/build/darling/src/external/libpthread/src/pthread_atfork.c:29:
/home/duislingr/build/darling/src/external/libplatform/include/platform/compat.h:59:9: warning:
'memmove' macro redefined [-Wmacro-redefined]
#define memmove _platform_memmove
^
/home/duislingr/build/darling/src/libc/include/secure/_string.h:70:9: note:
previous definition is here
#define memmove(dest, src, len) \
^
In file included from /home/duislingr/build/darling/src/external/libpthread/src/pthread_atfork.c:29:
/home/duislingr/build/darling/src/external/libplatform/include/platform/compat.h:61:9: warning:
'memset' macro redefined [-Wmacro-redefined]
#define memset _platform_memset
^
/home/duislingr/build/darling/src/libc/include/secure/_string.h:76:9: note:
previous definition is here
#define memset(dest, val, len) \
^
/home/duislingr/build/darling/src/external/libpthread/src/pthread_atfork.c:67:21: warning:
incompatible integer to pointer conversion assigning to 'struct
pthread_atfork_entry *' from 'mach_vm_address_t'
(aka 'unsigned long long') [-Wint-conversion]
globals->atfork = storage;
^ ~~~~~~~
7 warnings and 12 errors generated.
make[2]: *** [src/external/libpthread/src/CMakeFiles/system_pthread_obj.dir/build.make:63: src/external/libpthread/src/CMakeFiles/system_pthread_obj.dir/pthread_atfork.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1233: src/external/libpthread/src/CMakeFiles/system_pthread_obj.dir/all] Error 2
make: *** [Makefile:128: all] Error 2
I can confirm the build failure. After debugging for a while, it turns out that f5446b23bf05118ecc7fc11f88be58badeadc0f7 already fixed it :)
yan12125
on 27 Mar 2017
Here comes another error:
[ 29%] Building C object src/libm/CMakeFiles/system_m_extra.dir/Source/Intel/xmm_misc.o
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmm_misc.c:10:
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmmLibm_prefix.h:11:
In file included from /home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:27:
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:646:3: error: use of unknown builtin
'__builtin_ia32_storeups' [-Wimplicit-function-declaration]
__builtin_ia32_storeups(__p, __a);
^
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:696:3: error: use of unknown builtin
'__builtin_ia32_movntps' [-Wimplicit-function-declaration]
__builtin_ia32_movntps(__p, __a);
^
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:696:3: note: did you mean '__builtin_ia32_movntq'?
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:690:3: note: '__builtin_ia32_movntq' declared here
__builtin_ia32_movntq(__p, __a);
^
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmm_misc.c:10:
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmmLibm_prefix.h:11:
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:389:10: error: use of unknown builtin
'__builtin_ia32_cvtps2pd' [-Wimplicit-function-declaration]
return __builtin_ia32_cvtps2pd(__a);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:389:10: note: did you mean
'__builtin_ia32_cvtps2pi'?
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:430:17: note: '__builtin_ia32_cvtps2pi' declared
here
return (__m64)__builtin_ia32_cvtps2pi(__a);
^
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmm_misc.c:10:
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmmLibm_prefix.h:11:
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:389:10: error: returning 'int' from a function with
incompatible result type '__m128d' (vector of 2 'double' values)
return __builtin_ia32_cvtps2pd(__a);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:395:10: error: use of unknown builtin
'__builtin_ia32_cvtdq2pd' [-Wimplicit-function-declaration]
return __builtin_ia32_cvtdq2pd((__v4si)__a);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:395:10: note: did you mean
'__builtin_ia32_cvtps2pd'?
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:389:10: note: '__builtin_ia32_cvtps2pd' declared
here
return __builtin_ia32_cvtps2pd(__a);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:395:10: error: returning 'int' from a function with
incompatible result type '__m128d' (vector of 2 'double' values)
return __builtin_ia32_cvtdq2pd((__v4si)__a);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:601:3: error: use of unknown builtin
'__builtin_ia32_storeupd' [-Wimplicit-function-declaration]
__builtin_ia32_storeupd(__dp, __a);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:601:3: note: did you mean '__builtin_ia32_storeups'?
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:646:3: note: '__builtin_ia32_storeups' declared here
__builtin_ia32_storeups(__p, __a);
^
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmm_misc.c:10:
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmmLibm_prefix.h:11:
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:1234:3: error: use of unknown builtin
'__builtin_ia32_storedqu' [-Wimplicit-function-declaration]
__builtin_ia32_storedqu((char *)__p, (__v16qi)__b);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:1255:3: error: use of unknown builtin
'__builtin_ia32_movntpd' [-Wimplicit-function-declaration]
__builtin_ia32_movntpd(__p, __a);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:1255:3: note: did you mean '__builtin_ia32_movntps'?
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:696:3: note: '__builtin_ia32_movntps' declared here
__builtin_ia32_movntps(__p, __a);
^
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmm_misc.c:10:
In file included from /home/yen/Projects/tmp/darling/src/libm/Source/Intel/xmmLibm_prefix.h:11:
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:1261:3: error: use of unknown builtin
'__builtin_ia32_movntdq' [-Wimplicit-function-declaration]
__builtin_ia32_movntdq(__p, __a);
^
/home/yen/Projects/tmp/darling/compiler-include/emmintrin.h:1261:3: note: did you mean '__builtin_ia32_movntq'?
/home/yen/Projects/tmp/darling/compiler-include/xmmintrin.h:690:3: note: '__builtin_ia32_movntq' declared here
__builtin_ia32_movntq(__p, __a);
^
10 errors generated.
make[2]: *** [src/libm/CMakeFiles/system_m_extra.dir/build.make:63: src/libm/CMakeFiles/system_m_extra.dir/Source/Intel/xmm_misc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4764: src/libm/CMakeFiles/system_m_extra.dir/all] Error 2
make: *** [Makefile:128: all] Error 2
Random Googling leads me to https://github.com/perl11/potion/issues/86. Seems Apple adds quite a few built-ins without upstreaming them? __builtin_ia32_storeups can be found in Apple's clang-800.0.42.1 but not in http://llvm.org/git/clang.git.
$ grep -r 'storeups\>' ../clang
[1]$ grep -r 'storeups\>' .
./order-files/inputs/OmniGroupFrameworks__NSBezierPath-OAExtensions.m: __builtin_ia32_storeups(p, a);
./src/tools/clang/lib/Headers/xmmintrin.h: __builtin_ia32_storeups(__p, __a);
./src/tools/clang/lib/Headers/avxintrin.h: __builtin_ia32_storeups(__addr_lo, __v128);
./src/tools/clang/lib/Headers/avxintrin.h: __builtin_ia32_storeups(__addr_hi, __v128);
./src/tools/clang/include/clang/Basic/BuiltinsX86.def:TARGET_BUILTIN(__builtin_ia32_storeups, "vf*V4f", "", "sse")
./src/include/llvm/IR/IntrinsicsX86.td: def int_x86_sse_storeu_ps : GCCBuiltin<"__builtin_ia32_storeups">,
./src/projects/compiler-rt/lib/msan/tests/msan_test.cc: __builtin_ia32_storeups((float*)&y, x);
@yan12125 @LubosD actually technically this stuff is part of clang already. The problem is Apple is using outdated code in these files for some reason. If you compare an older version of clangs files you will see that the code is present in them. however I don't think we can simply just use an older clang to compile everything here :/
https://github.com/llvm-mirror/clang/blob/release_34/lib/Headers/avxintrin.h
https://opensource.apple.com/source/clang/clang-800.0.42.1/src/tools/clang/lib/Headers/avxintrin.h.auto.html
DuIslingr
on 27 Mar 2017
FYI using-machos-experiment has been merged into master some minutes ago.
The original problem is that Darling has to use -nostdinc to prevent Linux headers from leaking into the build (except for areas where this is actually necessary). This unfortunately not only kills paths such as /usr/include, but also the include path for compiler-specific files such as stdbool.h or xmmintrin.h.
I think I'll have to write a CMake script that parses the output of clang -M testfile.c (where the testfile includes something like stdbool.h) and adds this path via include_directories().
LubosD
on 27 Mar 2017
actually technically this stuff is part of clang already.
Thanks @DuIslingr. I checked LLVM 3.8 and 3.7 and found nothing - it's surprising to me that Apple's version is that old...
I think I'll have to write a CMake script that parses the output of clang -M testfile.c (where the testfile includes something like stdbool.h) and adds this path via include_directories().
I gave it a try. First replace darling's compiler-include with clang's headers.
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index a7ecaf74..9428f318 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -60,7 +60,7 @@ include_directories("${CMAKE_CURRENT_SOURCE_DIR}/kernel/libsyscall/wrappers")
include_directories("${DARLING_TOP_DIRECTORY}/platform-include")
include_directories("${DARLING_TOP_DIRECTORY}/platform-include/pthread")
include_directories("${DARLING_TOP_DIRECTORY}/kernel-include")
-include_directories("${DARLING_TOP_DIRECTORY}/compiler-include")
+include_directories("/usr/lib/clang/3.9.1/include/")
include_directories("${CMAKE_CURRENT_SOURCE_DIR}/duct/include")
include_directories("${CMAKE_CURRENT_SOURCE_DIR}/external/libplatform/include")
And in src/external/coregraphics/,
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2edcd39..2dc24c2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -62,7 +62,7 @@ include_directories(
${DARLING_TOP_DIRECTORY}/platform-include
${DARLING_TOP_DIRECTORY}/platform-include/machine
${DARLING_TOP_DIRECTORY}/kernel-include
- ${DARLING_TOP_DIRECTORY}/compiler-include
+ /usr/lib/clang/3.9.1/include
${DARLING_TOP_DIRECTORY}/src/libffi/include
${DARLING_TOP_DIRECTORY}/src/libc/stdtime/FreeBSD
${DARLING_TOP_DIRECTORY}/src/libc/gen
That leads to another compile error:
[ 35%] Building CXX object src/external/objc4/runtime/CMakeFiles/objc_obj.dir/maptable.o
clang-3.9: warning: argument unused during compilation: '-nostdinc++'
In file included from /home/yen/Projects/tmp/darling/src/external/objc4/runtime/maptable.mm:33:
In file included from /home/yen/Projects/tmp/darling/src/external/objc4/runtime/objc-private.h:294:
In file included from /home/yen/Projects/tmp/darling/src/external/objc4/runtime/objc-os.h:104:
In file included from /home/yen/Projects/tmp/darling/src/external/libplatform/include/os/lock_private.h:440:
/home/yen/Projects/tmp/darling/src/external/libcxx/include/atomic:812:21: error: expected ')'
kill_dependency(_Tp __y) _NOEXCEPT
^
/home/yen/Projects/tmp/darling/src/external/libcxx/include/atomic:812:1: note: to match this '('
kill_dependency(_Tp __y) _NOEXCEPT
^
/usr/lib/clang/3.9.1/include/stdatomic.h:70:28: note: expanded from macro 'kill_dependency'
#define kill_dependency(y) (y)
^
Seems that's due to conflicts between clang's <stdatomic.h> and libc++'s <atomic>, so I remove headers that may include <stdatomic.h>:
diff --git a/include/os/lock_private.h b/include/os/lock_private.h
index f5cbac8..f1daee2 100644
--- a/include/os/lock_private.h
+++ b/include/os/lock_private.h
@@ -27,8 +27,6 @@
#include <stddef.h>
#include <stdint.h>
#include <stdbool.h>
-#include <stdatomic.h>
-#include <machine/atomic.h>
#include <os/base_private.h>
#include <os/lock.h>
After all those changes the whole tree builds fine and run fine (with the ptrace() workaround) on Arch Linux.
UPDATE: Found this: https://github.com/darlinghq/darling-libplatform/commit/9d42f6943076b2def435aa9eb371a6f44698ec2b#diff-1d87a71b1601791196b4d943879cdbb7. It can be reverted :)
yan12125
on 27 Mar 2017
It doesn't build: make.txt
(BTW, I have updated PKGBUILD to reflect build instructions changes in ec7637d24a3f987849f4a4902fe0e9c0f20f97fe.)
X0rg
on 27 Mar 2017
The atomic stuff needs more changes, but I'm working on it.
LubosD
on 27 Mar 2017
Now it builds for me locally. I'm working on getting the build server working again.
LubosD
on 27 Mar 2017
@yan12125 I don't think its that old but I do believe its hacked together various versions of clang. Like I said before they decided to keep code for these files from the older version for w/e reason.
DuIslingr
on 27 Mar 2017
Ok, that's a bit better, but I have another issue:
make.txt
@LubosD: Why not use Travis CI? It's free for open source projects, and it can automatically build your project on each push. 😃
X0rg
on 27 Mar 2017
@X0rg looks like its missing a framework or header. What happens if you don't build for 32 bit?
DuIslingr
on 27 Mar 2017
@DuIslingr: I don't explicitly build for 32-bit. With LubosD work, there is no more need for 32-bit build. IDK if we can disable the 32-bit build.
The PKGBUILD is for x86_64 only.
X0rg
on 27 Mar 2017
I don't explicitly build for 32-bit. With LubosD work, there is no need for 32-bit build.
Just to clarify, there is now only one "build", and it creates both 32- and 64-bit binaries (fat binaries, actually) -- so you still need to build for 32-bit, but you don't need to run a separate command for that.
bugaevc
on 27 Mar 2017
Ok, that's my fault. As said @yan12125, disabling user build flags solve the build issue.
X0rg
on 27 Mar 2017
It could be fixed by an additional compiler_rt -> libplatform reference, but I was wondering if some extra flags were passed.
We use TeamCity at https://teamcity.dolezel.info - the advantage being we can test build on various distros (Debian Testing + Ubuntu 16.04 for now).
LubosD
on 27 Mar 2017
@LubosD is 32 bit required though? Cause I can successfully build by just adding these flags to the toolchain.cmake one.
-DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64
DuIslingr
on 27 Mar 2017
Yes, by default, makepkg use custom flags (CFLAGS, CXXFLAGS, LDFLAGS), but don't worry about it, that was an Arch-packaging-specific issue.
Unfortunately, I still have an issue at runtime:
$ darling shell
Loaded the kernel module
/bin/mldr: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
Patch in #259 doesn't solve it.
dmesg output for information:
[ 30.167785] Darling Mach: <1413> ipc_space_init() on space ffffffffa05504c0
[ 30.167787] Darling Mach: <1413> Allocated new port: ffff8801114d3000
[ 30.167788] Darling Mach: <1413> Allocated new port: ffff8801114d4000
[ 30.167789] Darling Mach: <1413> Allocated right ffff88010ed13580 for port ffff8801114d4000
[ 30.167790] Darling Mach kernel emulation loaded, API version 2
Hmmm with my flags it installs and everything but I get this when trying to load darling shell
darling shell   1Â
dyld: Library not loaded: /usr/lib/libc++.1.dylib
Referenced from: /usr/lib/libobjc.A.dylib
Reason: image not found
@DuIslingr Sorry, my bad, I just broke it when I was rewriting the libc++ build script today. Fixed.
LubosD
on 27 Mar 2017
@DuIslingr There is no way to avoid the 32-bit build, you can only introduce further issues by doing this - Darling controls the multilib build with -arch switches, not -mXX.
The only reason why "i386" is frequently mentioned in link errors is because the i386 part of the resulting fat Mach-O file is being linked first.
LubosD
on 27 Mar 2017
@X0rg Could you please share your contents of $INSTALL_PREFIX/libexec/darling/etc/ld.so.conf.d/*? And please tell us where libpthread.so.0 is located on Arch Linux.
LubosD
on 27 Mar 2017
@LubosD ok well everything builds for me. however the issue still occurs with the c++.1.dylib file. though i checked the folder and it is now present unlike before.
DuIslingr
on 27 Mar 2017
@DuIslingr Run darling shutdown and try again.
LubosD
on 28 Mar 2017
@LubosD figures. Shoulda tried that first lol. It works now. Awesome. Now on to testing the toolchain from xcode 8
DuIslingr
on 28 Mar 2017
@DuIslingr Hint: I've recently added unxip into Darling, which could come handy. Ignore any "cannot create file" warnings printed out by cpio in the process.
We're now working on getting xcodebuild and friends working (see https://github.com/darlinghq/darling/milestone/5).
LubosD
on 28 Mar 2017
Sweet. Good stuff. Do you guys have a discord? I don't particularly care for irc.
Welp the expected segfault error with another error with ptrace when trying to run unxip
Darling [~]$ unxip
Segmentation fault: 11 (core dumped)
Darling [~]$ ptrace(unxip)
bash: syntax error near unexpected token `unxip'
Darling [~]$
Note I am running the linux-lts package which is the 4.9 kernel which supposedly resolved the sig issues in the previously mentioned issue :/
Edit: Shiet I forgot to isntall the lts headers. ima try rebuilding this stuff after i do that and report back.
Update: did that and all is working well with that. So I suggest for the time being require linux-lts with linux-lts-headers. heres a link on how to switch to running the lts kernel http://unix.stackexchange.com/questions/284617/how-to-switch-arch-linux-to-lts-kernel and i guess reboot after building everything or add a message saying to reboot first if you installed the lts kernel or something.
@X0rg
DuIslingr
on 28 Mar 2017
@LubosD: This directory is empty, that explains the problem.
I manually run setup-ld-so.sh with the current directory set to ${CMAKE_INSTALL_PREFIX}/libexec/darling and it did the trick.
This is a packaging-related issue, I'll investigate myself.
libpthread is under /usr/lib/.
X0rg
on 28 Mar 2017
There is no more issues for me. Can you confirm for you @DuIslingr and @yan12125?
X0rg
on 29 Mar 2017
@X0rg I haven't had build issues since the commit that fixed libc++ issues. I didn't even have your ld issue.
However as I said before I recommend editing your package to depend on linux-lts and linux-lts-headers for the time being since we currently have segfault errors on kernel 4.10 which is the latest. You want the lts kernel to be installed and running before you build the mach_kernel though.
DuIslingr
on 29 Mar 2017
Downgrading the linux package is another solution (but I dislike it).
Adding a hard dependency to linux-lts is a "workaround", but a lot of packages can provide Linux < 4.10, that's why I'll not do that.
DKMS does the work, you don't need to boot on linux-lts to build the kernel module.
Maybe there is no more segfault on Linux 4.10.6?
X0rg
on 29 Mar 2017
@X0rg if that's true i couldn't find anything on telling dkms to target the lts headers. if i removed the regular linux headers it errored out saying they were missing hence why i think the lts kernel needs to be installed and running. I literally googled for hours on specifically targeting a certain set of headers with dkms and came up with nothing.
DuIslingr
on 29 Mar 2017
There is no more issues for me.
I once got another missing libpthread.so error, which turned out to be corrupted ~/.darling. I ran darling shutdown, removed this folder and re-ran darling shell. Everything works! Thanks for the packaging script @X0rg. I guess this issue can be closed as remaining are Arch-specific packaging issues, which can be discussed on https://aur.archlinux.org/packages/darling-git
yan12125
on 30 Mar 2017
Related issues
LubosD
·
5Comments
josepmc
·
5Comments
mrtino
·
3Comments
fervi
·
3Comments
LubosD
·
3Comments
Most helpful comment
The atomic stuff needs more changes, but I'm working on it.