Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing)

[I found where the tools are listed that are copied, the list that is missing head.] On 2017-Jun-29, at 3:33 PM, Mark Millard wrote: > [This is a clang targetting powerpc64 context from my > experimentation efforts, not the normal gcc 4.2.1 context > for powerpc64.] > > I break out the PATH int

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard : >I'm not currently set up to run more than head on >any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >(which are all I target). And I'm in the middle of >attempting a fairly large jump to head -r320458 on >those. Oh, then I had misu

head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing)

[This is a clang targetting powerpc64 context from my experimentation efforts, not the normal gcc 4.2.1 context for powerpc64.] I break out the PATH into lines below to make it easier to scan. See the later "sh: head: not found" line and the even later ls of the directory with the x86-64 program d

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

On 29 Jun 2017, at 19:16, Mark Millard wrote: > > On 2017-Jun-29, at 5:54 AM, Konstantin Belousov > wrote: >> >> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: >>> One nasty problem with this is that it is not possible to figure out at >>> compile time what the size of time_t

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

[Good news from the llvm side of things. . .] On 2017-Jun-29, at 3:47 AM, Dimitry Andric wrote: > On 29 Jun 2017, at 12:04, Mark Millard wrote: >> >> [The libc++ code in question appears to not be ready for >> 32-bit contexts with 64 bit times. Disable >> experimental/filesystem for now? I've

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

On 2017-Jun-29, at 5:54 AM, Konstantin Belousov wrote: > > On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: >> One nasty problem with this is that it is not possible to figure out at >> compile time what the size of time_t is. You always need some sort of >> configure-time test, a

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: > One nasty problem with this is that it is not possible to figure out at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. It is arguably possible, with constexpr.

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

On 2017-Jun-29, at 3:10 AM, Gerald Pfeifer wrote: > Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard dsl-only.net>: >> A primary test is building lang/gcc5-devel under release/11.0.1 >> and then using it under stable/11 or some draft of release/11.1.0 . > > Thank you, Mark. Let me know

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

On 29 Jun 2017, at 12:04, Mark Millard wrote: > > [The libc++ code in question appears to not be ready for > 32-bit contexts with 64 bit times. Disable > experimental/filesystem for now? I've submitted > llvm bugzilla 33638 for the issue and have > added it to llvm's 25780, the FreeBSD META for >

Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work

Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard : >A primary test is building lang/gcc5-devel under release/11.0.1 >and then using it under stable/11 or some draft of release/11.1.0 . Thank you, Mark. Let me know how it went. In the meantime I'll prepare the change for gcc5 itself. >I

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

[The libc++ code in question appears to not be ready for 32-bit contexts with 64 bit times. Disable experimental/filesystem for now? I've submitted llvm bugzilla 33638 for the issue and have added it to llvm's 25780, the FreeBSD META for clang.] On 2017-Jun-29, at 2:21 AM, Mark Millard wrote: >

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

[TARGET_ARCH=powerpc64 fails similarly in its world32 part of its build.] On 2017-Jun-29, at 1:33 AM, Mark Millard wrote: > Beyond static_assert failures and overflow/underflow of long long > it also it complains in some cases about: > > static_assert expression is not an integral constant expr

head -r320458 (e.g.) amd64 -> powerpc cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

Beyond static_assert failures and overflow/underflow of long long it also it complains in some cases about: static_assert expression is not an integral constant expression [I will note that attempting a gcc 4.2.1 build did not stop and report such things for its libstdc++. The below is somehow l

Re: /usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi)

Hello Mark, On Wed, 28 Jun 2017 20:52:17 -0700 Mark Millard wrote: > On 2017-Jun-28, at 7:44 PM, Mark Millard wrote: > > > Is the below a BSDL vs. GPL DTS issue? > > > > In my attempt to build sysutils/u-boot-pine64 I got: > > > > OBJCOPY u-boot.srec > > OBJCOPY u-boot-nodtb.bin > > star