Re: Compiling LLDB
On 31 Mar 2015, at 02:53, Ed Maste ema...@freebsd.org wrote: I'd suggest checking /var/log/messages for further information. Is this i386 or amd64, how much memory does your build host have, and are you compiling with debug information or no? If had to guess, you're running out of memory (or running into ulimit) during linking, and the process is being killed as a result. Ninja defaults to using a large number of concurrent processes, which can exacerbate this. If you are on a 32-bit system, or only have 4GB or so of RAM (or have 2GB per core), you may want to explicitly do ninja -j1 to get a serial build. Your best bet is probably something like: $ ninja -k100 $ ninja -j1 The first will do a parallel build of everything that doesn't crash. The second will do a serial build of whatever's left. It's also possible to configure different pools for Ninja, though I'm not sure that this is exposed via the CMake interface yet. This mechanism exists to allow you to say things like 'only run one link job at a time', which can improve matters. You may also find that using gold from ports (or possibly lld, which I believe can now link lldb) will improve matters. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import
On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric d...@freebsd.org wrote: On 31 Mar 2015, at 20:13, Dimitry Andric d...@freebsd.org wrote: ... but then: + patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: contrib/libc++/include/type_traits |=== |--- contrib/libc++/include/type_traits (revision 280762) |+++ contrib/libc++/include/type_traits (working copy) -- Patching file contrib/libc++/include/type_traits using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 842. Hunk #2 succeeded at 877. Hmm... Ignoring the trailing garbage. done E.g., it undoes the change to type_traits that was merged in the subversion update. OK, I undid the patch. Now the clang and libc++ parts build, but I'm still getting problems building rescue: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import
On 31 Mar 2015, at 19:17, Craig Rodrigues rodr...@freebsd.org wrote: On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric d...@freebsd.org wrote: ... Yes, this is a bug in libc++, when compiling it with newer versions of gcc. I reported this upstream some time ago: https://llvm.org/PR22771 Still haven't had enough time to test Eric Fiselier's patch for it. I hope I see the bottom of my TODO list anytime soon... -Dimitry Hi, I just updated my tree to include your latest fixes such as r28064. I'm still getting this: from /builds/FreeBSD_HEAD_external_toolchain_gcc/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclBase.cpp:14: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:845:28: error: initializing argument 1 of 'char std::__1::__is_convertible_imp::__test(_Tp) [with _Tp = clang::StoredDeclsList]' template class _Tp char __test(_Tp); ^ *** [DeclBase.o] Error code 1 make[6]: stopped in /builds/FreeBSD_HEAD_external_toolchain_gcc/lib/clang/libclangast Any ideas? Yes, see your log: Started by user rodrigc Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD_external_toolchain_gcc Updating svn://svn.freebsd.org/base/head at revision '2015-03-31T00:49:32.815 +' [...] G contrib/libc++/include/type_traits U contrib/libarchive/libarchive/archive_read_disk_posix.c At revision 280872 [...] but then: + patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: contrib/libc++/include/type_traits |=== |--- contrib/libc++/include/type_traits (revision 280762) |+++ contrib/libc++/include/type_traits (working copy) -- Patching file contrib/libc++/include/type_traits using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 842. Hunk #2 succeeded at 877. Hmm... Ignoring the trailing garbage. done E.g., it undoes the change to type_traits that was merged in the subversion update. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import
On 31 Mar 2015, at 22:06, Craig Rodrigues rodr...@freebsd.org wrote:
On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric d...@freebsd.org wrote:
On 31 Mar 2015, at 21:38, Craig Rodrigues rodr...@freebsd.org wrote:
On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric d...@freebsd.org wrote:
On 31 Mar 2015, at 20:13, Dimitry Andric d...@freebsd.org wrote:
...
but then:
+ patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: contrib/libc++/include/type_traits
|===
|--- contrib/libc++/include/type_traits (revision 280762)
|+++ contrib/libc++/include/type_traits (working copy)
--
Patching file contrib/libc++/include/type_traits using Plan A...
Reversed (or previously applied) patch detected! Assume -R? [y]
Hunk #1 succeeded at 842.
Hunk #2 succeeded at 877.
Hmm... Ignoring the trailing garbage.
done
E.g., it undoes the change to type_traits that was merged in the
subversion update.
OK, I undid the patch. Now the clang and libc++ parts build, but I'm
still getting problems building rescue:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console
Hm, that is strange. I have just completed a build with
amd64-xtoolchain-gcc, and apart from boot2, everything worked...
What does readelf say when you run it on the cat.lo file which is
complained about in the log? And what happens if you delete it, and
restart the build?
See:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
I'm suspecting this might have something to do with crunchide, or least,
the copy of crunchide that is run for this:
--- cat.lo ---
/usr/local/x86_64-freebsd/bin/ld -dc -r -o cat.lo cat_stub.o
/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue//builds/FreeBSD_HEAD_external_toolchain_gcc/bin/cat/cat.o
crunchide -k _crunched_cat_stub cat.lo
If I look at my own build logs, it seems to pick the crunchide
executable in /usr/bin, and Makefile.inc1 does *not* build it during the
cross-tools stage if ${TARGET_ARCH} is the same as ${MACHINE_ARCH}:
.if ${TARGET_ARCH} != ${MACHINE_ARCH}
.if ${MK_RESCUE} != no || defined(RELEASEDIR)
_crunchide= usr.sbin/crunch/crunchide
.endif
However, this does not explain why my /usr/bin/crunchide seems to not
screw up cat.lo, while yours does. As far as I can see, we're both
building this on a stable/10 amd64 box...
Maybe, as a hack, you can force cross-tools to build crunchide, by
patching Makefile.inc1 to ignore the arch check, and see what that
results in?
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
[Differential] [Accepted] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage
bapt accepted this revision. bapt added a comment. This revision is now accepted and ready to land. yup you are right This looks ok for me I still would be more confident with @imp reviewing as well :) BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D2187 To: dim, imp, rodrigc, bapt Cc: imp, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Kernel compilation failures with gcc 4.9
On Mar 31, 2015, at 14:04, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I put this in make.conf: NO_WERROR=yes WERROR= WITHOUT_BOOT=yes WITHOUT_RESCUE=yes and used this script to build: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh I managed to build a lot of stuff, but then got build failures in the aesni part of the kernel build. See the full build log here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/30/console I think this is the error: In file included from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/mm_malloc.h:27:0, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/xmmintrin.h:34, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/emmintrin.h:31, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/wmmintrin.h:31, from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:74: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/stdlib.h:93:7: error: conflicting types for 'free' void free(void *); ^ In file included from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/crypto/aesni/aesni.h:33:0, from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:69: /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/sys/malloc.h:177:6: note: previous declaration of 'free' was here void free(void *addr, struct malloc_type *type); It shouldn't be using the stdlib when it's built with -ffreestanding or -nostdlib. Can you make sure? -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Kernel compilation failures with gcc 4.9
On Mar 31, 2015, at 4:53 PM, Rui Paulo rpa...@me.com wrote: On Mar 31, 2015, at 14:04, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I put this in make.conf: NO_WERROR=yes WERROR= WITHOUT_BOOT=yes WITHOUT_RESCUE=yes and used this script to build: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh I managed to build a lot of stuff, but then got build failures in the aesni part of the kernel build. See the full build log here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/30/console I think this is the error: In file included from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/mm_malloc.h:27:0, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/xmmintrin.h:34, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/emmintrin.h:31, from /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/wmmintrin.h:31, from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:74: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/stdlib.h:93:7: error: conflicting types for 'free' void free(void *); ^ In file included from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/crypto/aesni/aesni.h:33:0, from /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:69: /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/sys/malloc.h:177:6: note: previous declaration of 'free' was here void free(void *addr, struct malloc_type *type); It shouldn't be using the stdlib when it's built with -ffreestanding or -nostdlib. Can you make sure? The AES stuff breaks the rules, and this is a consequence of it :( That stuff should be fixed. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
