[Bug 230399] devel/libunwind: fails to build with Clang 7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230399 --- Comment #11 from Dimitry Andric --- (In reply to Kubilay Kocak from comment #10) > is/will a/the workaround in the port still be required, until base r337585 > ends up in -RELEASES? Previous releases shouldn't be affected, this problem was only applicable to the clang700-import branch. (E.g., due to the optimization I described, the __gxx_personality_v0 reference does not end up in libgcc_s.so with previous versions of clang. It would only affect people who rebuilt their libgcc_s.so by hand, using -O0.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 230454] Compiling world fails on /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org Assignee|toolch...@freebsd.org |d...@freebsd.org Status|New |In Progress --- Comment #3 from Dimitry Andric --- Most likely, you are running out of memory. Try lowering your make -j level, or adding some more swap (or memory :). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard <
mark.mill...@nexustechnology.com> wrote:
> On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
> >
> > On 11 Aug 2018, at 19:31, Warner Losh wrote:
> >>
> >> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
> >> On 11 Aug 2018, at 16:55, Warner Losh wrote:
> >>>
> >>> It looks like armv5 clang bogusly uses lld:
> >>>
> >>> From a 'make buildkernel' of the RT1310 kernel config:
> >>>
> >>> cc -target arm-gnueabi-freebsd12.0
> > ...
> >>> ld: warning: lld uses extended branch encoding, no object with
> architecture
> >>> supporting feature detected.
> >>> ld: warning: lld may use movt/movw, no object with architecture
> supporting
> >>> feature detected.
> > ...
>
> Did the build get either of the below notices? Both?
>
> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined
> that CC=cc matches the source tree. Not bootstrapping a cross-compiler.
>
This one I have.
> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
> LD=ld matches the source tree. Not bootstrapping a cross-linker.
>
This one I don't.
Warner
> ?
>
> (The example text was taken from an amd64 -> aarch64 cross build.)
>
> >> Host is amd64. Target is arm. No src.conf. Did a full buildworld
> TARGET=arm a few days ago. /usr/bin/ld is lld.
> >
> > Okay, so in the above "cc" command, can you somehow figure out which cc
> > executable it is using? And please add a -v to the "linking kernel.full"
> > command line, so it shows exactly which linker it runs?
> >
> > I have the idea that it is preferring your /usr/bin/ld over
> > ${WORLDTMP}/usr/bin/ld...
>
>
>
> ===
>
> Mark Millard
> Nexus Technology, Inc.
> 78 Northeastern Blvd., Unit #2
> Nashua NH 03062
>
> 877-595-8116 x821
>
> mark.mill...@nexustechnology.com
>
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 230454] Compiling world fails on /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454 Rodney W. Grimes changed: What|Removed |Added CC||toolch...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 230454] Compiling world fails on /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454 Rodney W. Grimes changed: What|Removed |Added CC||rgri...@freebsd.org --- Comment #4 from Rodney W. Grimes --- (In reply to Dimitry Andric from comment #3) >From other issues we have seen on aarch64 and small memory amd64 VM's adding swap is rarely the solution to this, you either have to add memory or reduce -j level. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 230454] Compiling world fails on /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #5 from Warner Losh --- (In reply to Rodney W. Grimes from comment #4) You need to add non-flash swap typically to make any headway, although reducing -j is more effective. Spinning disks suffer much less from these issues, but are slower. Also, on rpi3 there appears to be a hanging bug in the USB stack which can sometimes be triggered. The arm64 issues stem from crappy nand and bad drivers causing undue (multi-second) delays. But the original poster is running on amd64 where that's not an issue because most people aren't putting swap on crappy SD cards, crappy USB thumb drives and our SATA drivers there are much, much more mature and resilient. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 11 Aug 2018, at 16:55, Warner Losh wrote: > > It looks like armv5 clang bogusly uses lld: > > From a 'make buildkernel' of the RT1310 kernel config: > > cc -target arm-gnueabi-freebsd12.0 > --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp > -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe > -g -nostdinc -I. -I/usr/home/imp/git/head/sys > -I/usr/home/imp/git/head/sys/contrib/ck/include > -I/usr/home/imp/git/head/sys/contrib/libfdt > -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te > -funwind-tables -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -mfpu=none -std=iso9899:1999 -Werror vers.c > linking kernel.full > ld: warning: lld uses extended branch encoding, no object with architecture > supporting feature detected. > ld: warning: lld may use movt/movw, no object with architecture supporting > feature detected. > text data bss dechex filename > 3448944 176776 655360 4281080 0x4152f8 kernel.full > > Any clues on how I can track this down? What does /usr/bin/ld -v output? As far as I can see, MK_LLD_BOOTSTRAP and MK_LLD_IS_LD are only enabled by default for aarch64 and amd64. So do you have any of those settings in your src.conf or environment? -Dimitry signature.asc Description: Message signed with OpenPGP
Broken arm support in clang now?
It looks like armv5 clang bogusly uses lld: >From a 'make buildkernel' of the RT1310 kernel config: cc -target arm-gnueabi-freebsd12.0 --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/home/imp/git/head/sys -I/usr/home/imp/git/head/sys/contrib/ck/include -I/usr/home/imp/git/head/sys/contrib/libfdt -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te -funwind-tables -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mfpu=none -std=iso9899:1999 -Werror vers.c linking kernel.full ld: warning: lld uses extended branch encoding, no object with architecture supporting feature detected. ld: warning: lld may use movt/movw, no object with architecture supporting feature detected. text data bss dechex filename 3448944 176776 655360 4281080 0x4152f8 kernel.full Any clues on how I can track this down? Warner ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 230454] Compiling world fails on /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #6 from Mark Millard --- (In reply to Warner Losh from comment #5) While Bob P.'s reports were with large gstat reporting large ms/w and/or ms/r, Trev had made reports of getting the problem without gstat indicating multi-second delays (averages for some time intervals) and having lots of swap still available, starting at: https://lists.freebsd.org/pipermail/freebsd-arm/2018-June/018151.html (But Trev only provided short segments of the records in messages instead of posting the whole logs somewhere. This limits confirmation.) Note to avoid misinterpretation: I am in general agreement with the following as appropriate experiments . . . "You need to add non-flash swap" and "Spinning disks suffer much less from these issues" although I would explicitly add that there are SSD-based USB drives and at least some of these might be about as good as using a direct SATA SSD environment with good SSDs. (Correct me if I'm wrong for some reason.) Notes on testing: Having records from, say, periodic gstat runs, is a good cross check in all cases. Having the information-reporting patches from Mark Johnston are appropriate for testing as well. http://www.zefox.net/~fbsd/rpi3/swaptests/tools/ has various things that have been used in testing. But batchqueue.patch did not pan out and likely should be avoided. Similarly for config_options. The readme is what talks about: sysctl vm.pageout_oom_seq=120 The rest are patches for reporting of additional information during operation. These are likely more important than the gstat ms/w and ms/r records. The context for the patches is recent head, not 11.x . -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote: > On 11 Aug 2018, at 16:55, Warner Losh wrote: > > > > It looks like armv5 clang bogusly uses lld: > > > > From a 'make buildkernel' of the RT1310 kernel config: > > > > cc -target arm-gnueabi-freebsd12.0 > > --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp > > -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe > > -g -nostdinc -I. -I/usr/home/imp/git/head/sys > > -I/usr/home/imp/git/head/sys/contrib/ck/include > > -I/usr/home/imp/git/head/sys/contrib/libfdt > > -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL > > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te > > -funwind-tables -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > > -Wno-error-tautological-compare -Wno-error-empty-body > > -Wno-error-parentheses-equality -Wno-error-unused-function > > -Wno-error-pointer-sign -Wno-error-shift-negative-value > > -Wno-address-of-packed-member -mfpu=none -std=iso9899:1999 -Werror > vers.c > > linking kernel.full > > ld: warning: lld uses extended branch encoding, no object with > architecture > > supporting feature detected. > > ld: warning: lld may use movt/movw, no object with architecture > supporting > > feature detected. > > text data bss dechex filename > > 3448944 176776 655360 4281080 0x4152f8 kernel.full > > > > Any clues on how I can track this down? > > What does /usr/bin/ld -v output? As far as I can see, MK_LLD_BOOTSTRAP > and MK_LLD_IS_LD are only enabled by default for aarch64 and amd64. So > do you have any of those settings in your src.conf or environment? > Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm a few days ago. /usr/bin/ld is lld. Warner > ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 11 Aug 2018, at 19:31, Warner Losh wrote:
>
> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
> On 11 Aug 2018, at 16:55, Warner Losh wrote:
> >
> > It looks like armv5 clang bogusly uses lld:
> >
> > From a 'make buildkernel' of the RT1310 kernel config:
> >
> > cc -target arm-gnueabi-freebsd12.0
...
> > ld: warning: lld uses extended branch encoding, no object with architecture
> > supporting feature detected.
> > ld: warning: lld may use movt/movw, no object with architecture supporting
> > feature detected.
...
> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm a
> few days ago. /usr/bin/ld is lld.
Okay, so in the above "cc" command, can you somehow figure out which cc
executable it is using? And please add a -v to the "linking kernel.full"
command line, so it shows exactly which linker it runs?
I have the idea that it is preferring your /usr/bin/ld over
${WORLDTMP}/usr/bin/ld...
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: Broken arm support in clang now?
On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
>
> On 11 Aug 2018, at 19:31, Warner Losh wrote:
>>
>> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
>> On 11 Aug 2018, at 16:55, Warner Losh wrote:
>>>
>>> It looks like armv5 clang bogusly uses lld:
>>>
>>> From a 'make buildkernel' of the RT1310 kernel config:
>>>
>>> cc -target arm-gnueabi-freebsd12.0
> ...
>>> ld: warning: lld uses extended branch encoding, no object with architecture
>>> supporting feature detected.
>>> ld: warning: lld may use movt/movw, no object with architecture supporting
>>> feature detected.
> ...
Did the build get either of the below notices? Both?
make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
LD=ld matches the source tree. Not bootstrapping a cross-linker.
?
(The example text was taken from an amd64 -> aarch64 cross build.)
>> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm
>> a few days ago. /usr/bin/ld is lld.
>
> Okay, so in the above "cc" command, can you somehow figure out which cc
> executable it is using? And please add a -v to the "linking kernel.full"
> command line, so it shows exactly which linker it runs?
>
> I have the idea that it is preferring your /usr/bin/ld over
> ${WORLDTMP}/usr/bin/ld...
===
Mark Millard
Nexus Technology, Inc.
78 Northeastern Blvd., Unit #2
Nashua NH 03062
877-595-8116 x821
mark.mill...@nexustechnology.com
smime.p7s
Description: S/MIME cryptographic signature
[Bug 230400] devel/cmake, devel/qt5-buildtools: fails to build with libc++ 7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230400 --- Comment #8 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Aug 11 20:08:26 UTC 2018 New revision: 337654 URL: https://svnweb.freebsd.org/changeset/base/337654 Log: Undo r337593 (commenting out of timespec_get in libc++'s header), now that r337576 added that function. PR: 230400 Changes: projects/clang700-import/contrib/libc++/include/ctime -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
[Resent from the right account. I wish I could remove the prior send.]
On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
>
> On 11 Aug 2018, at 19:31, Warner Losh wrote:
>>
>> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
>> On 11 Aug 2018, at 16:55, Warner Losh wrote:
>>>
>>> It looks like armv5 clang bogusly uses lld:
>>>
>>> From a 'make buildkernel' of the RT1310 kernel config:
>>>
>>> cc -target arm-gnueabi-freebsd12.0
> ...
>>> ld: warning: lld uses extended branch encoding, no object with architecture
>>> supporting feature detected.
>>> ld: warning: lld may use movt/movw, no object with architecture supporting
>>> feature detected.
> ...
Did the build get either of the below notices? Both?
make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
LD=ld matches the source tree. Not bootstrapping a cross-linker.
?
(The example text was taken from an amd64 -> aarch64 cross build.)
>> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm
>> a few days ago. /usr/bin/ld is lld.
>
> Okay, so in the above "cc" command, can you somehow figure out which cc
> executable it is using? And please add a -v to the "linking kernel.full"
> command line, so it shows exactly which linker it runs?
>
> I have the idea that it is preferring your /usr/bin/ld over
> ${WORLDTMP}/usr/bin/ld...
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net
Re: Broken arm support in clang now?
[Replying from the intended Email address, rather
than the one I accidentally used originally.]
On 2018-Aug-11, at 5:05 PM, Warner Losh wrote:
> On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard
> wrote:
> On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
> >
> > On 11 Aug 2018, at 19:31, Warner Losh wrote:
> >>
> >> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
> >> On 11 Aug 2018, at 16:55, Warner Losh wrote:
> >>>
> >>> It looks like armv5 clang bogusly uses lld:
> >>>
> >>> From a 'make buildkernel' of the RT1310 kernel config:
> >>>
> >>> cc -target arm-gnueabi-freebsd12.0
> > ...
> >>> ld: warning: lld uses extended branch encoding, no object with
> >>> architecture
> >>> supporting feature detected.
> >>> ld: warning: lld may use movt/movw, no object with architecture supporting
> >>> feature detected.
> > ...
>
> Did the build get either of the below notices? Both?
>
> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
> CC=cc matches the source tree. Not bootstrapping a cross-compiler.
>
> This one I have.
>
> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
> LD=ld matches the source tree. Not bootstrapping a cross-linker.
>
> This one I don't.
>
> Warner
So the system-clang needs to find and use the bootstrap-ld.
Interesting. (Hopefully the two distinct builds can not
create any mismatches for such mixed use.)
I'll note that the original Email listed a cc command for
compiling vers.c and the messages about "linking
kernel.full":
PARTIAL QUOTE
cc -target arm-gnueabi-freebsd12.0
--sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp
-B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c
. . .
-std=iso9899:1999 -Werror vers.c
linking kernel.full
ld: warning: lld uses extended branch encoding, no object with architecture
supporting feature detected.
ld: warning: lld may use movt/movw, no object with architecture supporting
feature detected.
. . .
END PARTIAL QUOTE
Is the link command itself available? (The .../sys/*/kernel.full.meta
likely has it if it is still around.)
> ?
>
> (The example text was taken from an amd64 -> aarch64 cross build.)
>
> >> Host is amd64. Target is arm. No src.conf. Did a full buildworld
> >> TARGET=arm a few days ago. /usr/bin/ld is lld.
> >
> > Okay, so in the above "cc" command, can you somehow figure out which cc
> > executable it is using? And please add a -v to the "linking kernel.full"
> > command line, so it shows exactly which linker it runs?
> >
> > I have the idea that it is preferring your /usr/bin/ld over
> > ${WORLDTMP}/usr/bin/ld...
>
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
