Re: /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function

> On 8 Apr 2023, at 20:21, Gary Jennejohn wrote: > > This isn't a fatal error, but it would be easy to fix: > > /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function > 'inet6_get_plen' [-Wunused-function] > inet6_get_plen(const struct in6_addr *addr) >

/usr/src/sys/netlink/route/iface.c:738:1: warning: unused function

This isn't a fatal error, but it would be easy to fix: /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function 'inet6_get_plen' [-Wunused-function] inet6_get_plen(const struct in6_addr *addr) ^ 1 warning generated. This function is called in get_sa_plen(const struct sockaddr *sa

Re: dmesg: ACPI Warning: Firmware issue warning spaming

running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it?    I think this spam message is from linux.    So, I th

Re: dmesg: ACPI Warning: Firmware issue warning spaming

>> What do you think opening a review about this fix/tweak to stop this >> spamming that blinds dmesg? [snip] FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit:

Re: dmesg: ACPI Warning: Firmware issue warning spaming

loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it?    I think this spam message is from linux.    So, I think we should discuss on linux forum bu

Re: dmesg: ACPI Warning: Firmware issue warning spaming

Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it?    I think this spam message is from linux.    So, I think we should discuss on linux forum but I don't familier to linux. FYI, b

Re: dmesg: ACPI Warning: Firmware issue warning spaming

On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive

Re: dmesg: ACPI Warning: Firmware issue warning spaming

On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms

Re: dmesg: ACPI Warning: Firmware issue warning spaming

> What do you think opening a review about this fix/tweak to stop this > spamming that blinds dmesg? > >> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg >> warnings: >> > --- >> > ACPI Warning: Firmware issue: Excessive sleep t

Re: dmesg: ACPI Warning: Firmware issue warning spaming

What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? Masachika ISHIZUKA escreveu no dia domingo, 12/06/2022 à(s) 09:03: > > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg > warnings: > > --- > > ACPI Wa

Re: dmesg: ACPI Warning: Firmware issue warning spaming

> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: > --- > ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > > 10 ms) in ACPI Control Method (20220331/exsystem-347) > --- > Is there a way to silence it? Hi. I think th

dmesg: ACPI Warning: Firmware issue warning spaming

Hello, I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? Thanks in advance, Nuno Teixeira

Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery

rescue > > > them and store the data on ZFS volumes. Mounting of the HDD doesn't work, > > > FreeBSD > > > 12.3 obviously lack in some etx2 features, namely "needs_recovery". The > > > kernel > > > reports: > > > > > >

Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery

work, FreeBSD > > 12.3 obviously > > lack in some etx2 features, namely "needs_recovery". The kernel reports: > > > > WARNING: mount of da4p3 denied due to unsupported optional features: > > needs_recovery > > > > How can this problem be solved? > >

Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery

The kernel reports: WARNING: mount of da4p3 denied due to unsupported optional features: needs_recovery How can this problem be solved? Thanks in advance, oh Probably as the name of the mailing list suggest you should upgrade to 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it.

ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery

Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue them and store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3 obviously lack in some etx2 features, namely "needs_recovery". The kernel reports: WARNING: mount of da4p3

How can I suppress ACPI Warning messages ?

I'm using 14.0-current on old DELL xps12 notebook. Xconsole on it is fillfulled the 'ACPI Warning: Firmware issue: Excessive sleep time (0x0014 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347)' messages and I'm failling to see other important messages. How can I suppr

ASAN: "ls -l, *" AddressSanitizer warning: "unexpected format specifier in printf interceptor: %*j'"

# ls -l, * /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/lib/libc/stdio/fread.c:133:10 in ==47404==AddressSanitizer: WARNING: unexpected format specifier in printf

new boot message: "/etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5)."?

aarch64 1400043 1400043 my boot sequences are getting a report of: # dmesg -a | grep zfsk /etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5). for the likes of a system (aarch64 example) based on: # gpart show =>40 2000409184 ada0 GPT (954G) 40 409

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

Am Wed, 11 Aug 2021 15:03:54 -0400 Ed Maste schrieb: > On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote: > > > > Hallo, > > > > latest upgrade of CURRENT sources renders buildworld into failure, box is > > running > > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

On Wed, Aug 11, 2021, 3:52 PM FreeBSD User wrote: > Am Wed, 11 Aug 2021 15:03:54 -0400 > Ed Maste schrieb: > > > On Wed, 11 Aug 2021 at 05:41, FreeBSD User > wrote: > > > > > > Hallo, > > > > > > latest upgrade of CURRENT sources renders buildworld into failure, box > is running > > > FreeBSD

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

Am Wed, 11 Aug 2021 15:03:54 -0400 Ed Maste schrieb: > On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote: > > > > Hallo, > > > > latest upgrade of CURRENT sources renders buildworld into failure, box is > > running > > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST

Re: ar: warning: can't open file: ccopy.pieo: No such file or directory

On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote: > > Hallo, > > latest upgrade of CURRENT sources renders buildworld into failure, box is > running > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST > 2021 amd64: Assuming this was with BEARSSL enabled, it should be

ar: warning: can't open file: ccopy.pieo: No such file or directory

bin --- --- all_subdir_sbin/dmesg --- ===> sbin/dmesg (all) --- all_subdir_stand --- ar: warning: can't open file: ccopy.pieo: No such file or directory 1.72 real 3.57 user 1.07 sys Kind regards oh -- O. Hartmann

Re: etcupdate warning: "No previous tree to compare against, a sane comparison is not possible."

Hello Jonh! I did it and it worked fine: etcupdate extract etcupdate diff > /tmp/etc.diff cd / patch -R < /tmp/etc.diff Patch can't find diff paths so I run it inside /etc /etc/defalts ... until all diff is applied. Now when I run 'etcupdate' I don't get any warning and 'etcupdat

Re: CURRENT: acpi_wakecode.S error: unknown -Werror warning specifier: '-Wno-error-tautological-compare'

On 22 Jun 2021, at 20:24, John Baldwin wrote: > > On 6/22/21 11:13 AM, O. Hartmann wrote: >> Hello, >> on a recent CURRENT (FreeBSD 14.0-CURRENT #6 main-n247512-e3be51b2bc7c: Tue >> Jun 22 15:31:03 >> CEST 2021 amd64) we build a 13-STABLE based NanoBSD from a dedicated source >> tree for a

Re: CURRENT: acpi_wakecode.S error: unknown -Werror warning specifier: '-Wno-error-tautological-compare'

On 6/22/21 11:13 AM, O. Hartmann wrote: Hello, on a recent CURRENT (FreeBSD 14.0-CURRENT #6 main-n247512-e3be51b2bc7c: Tue Jun 22 15:31:03 CEST 2021 amd64) we build a 13-STABLE based NanoBSD from a dedicated source tree for a small routing appliance. It should be " ...we built ..." because

Re: etcupdate warning: "No previous tree to compare against, a sane comparison is not possible."

On 6/22/21 12:34 AM, Nuno Teixeira wrote: Hello, Should I be worry about etcupdate warning "No previous tree to compare against, a sane comparison is not possible." when I recompile and update current? I receive same warning when I do a 'etcupdate -p' after installworld too. Yes,

CURRENT: acpi_wakecode.S error: unknown -Werror warning specifier: '-Wno-error-tautological-compare'

apu2c4/src/sys/amd64/acpica/acpi_wakecode.S error: unknown -Werror warning specifier: '-Wno-error-tautological-compare' [-Werror,-Wunknown-warning-option] error: unknown -Werror warning specifier: '-Wno-error-empty-body' [-Werror,-Wunknown-warning-option] error: unknown -Werror warning sp

etcupdate warning: "No previous tree to compare against, a sane comparison is not possible."

Hello, Should I be worry about etcupdate warning "No previous tree to compare against, a sane comparison is not possible." when I recompile and update current? I receive same warning when I do a 'etcupdate -p' after installworld too. Thanks, Nuno Teixeira

Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

oot or log console messages: > > > > [...] > > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD > > 13.0. > > > > Where does this message come from and what is causing the warning? I tried > > to identify > > and eliminate this message,

Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

From: Mark Millard Subject: Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. Date: Fri, 15 Jan 2021 16:54:26 -0800 > Other examples for the general type of question . . . > > > For example, various aarch64, armv7, and powerpc*: > &g

Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O. wrote: > Running FreeBSD CURRENT on a USB only platform with a customised kernel, I > see this > message all the time I reboot or log console messages: > > [...] > WARNING: Device "kbd" is Giant locked and may be d

WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

Running FreeBSD CURRENT on a USB only platform with a customised kernel, I see this message all the time I reboot or log console messages: [...] WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. Where does this message come from and what is causing the

Re: fix WARNING pid 24503 (uhsoctl): ioctl sign-extension ioctl ffffffff8044692b

On Fri, 2 Nov 2018, Hans Petter Selasky wrote: > On 11/2/18 5:24 PM, Enji Cooper (yaneurabeya) wrote: > > signed ioctl value warnings > > in uhsoctl(). > > Here you go: > > https://svnweb.freebsd.org/changeset/base/340089 Thanks! Marcin smime.p7s Description: S/MIME Cryptographic Signature

Re: fix WARNING pid 24503 (uhsoctl): ioctl sign-extension ioctl ffffffff8044692b

On 11/2/18 5:24 PM, Enji Cooper (yaneurabeya) wrote: signed ioctl value warnings in uhsoctl(). Here you go: https://svnweb.freebsd.org/changeset/base/340089 --HPS ___ freebsd-current@freebsd.org mailing list

Re: fix WARNING pid 24503 (uhsoctl): ioctl sign-extension ioctl ffffffff8044692b

FYI! > On Oct 25, 2018, at 4:38 AM, Marcin Cieslak wrote: > > The following patch seems to fix the signed ioctl value warnings > in uhsoctl(). > > The code is the same in the current and stable branches. > > Marcin > > Index: usr.sbin/uhsoctl/uhsoctl.c >

Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1

On 10/26/18 10:48 AM, Dag-Erling Smørgrav wrote: Rebecca Cran writes: After installing 12.0-BETA1, on the first boot I noticed a warning about $local_unbound_tls not being set properly. Ah, I should probably have added it to /etc/defaults/rc.conf. Can you do that (just set

Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1

Rebecca Cran writes: > After installing 12.0-BETA1, on the first boot I noticed a warning > about $local_unbound_tls not being set properly. Ah, I should probably have added it to /etc/defaults/rc.conf. Can you do that (just set it to “no”) and let me know if it helps? DES -- Dag-

Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1

After installing 12.0-BETA1, on the first boot I noticed a warning about $local_unbound_tls not being set properly. It looks like that flag was only added recently by Dag-Erling, in "Add support for DNS-over-TLS to the local_unbound service."

Re: 12-BETA1 contains warning about non-PNP ISA device

On Thu, Oct 25, 2018 at 10:46 AM Warner Losh wrote: > > > On Thu, Oct 25, 2018 at 10:26 AM Rebecca Cran > wrote: > >> On 10/25/18 10:20 AM, Rebecca Cran wrote: >> >> > >> > uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0 >> > uart1 pnpinfo _HID=AMDI0020 _UID=1 at

Re: 12-BETA1 contains warning about non-PNP ISA device

On 10/25/18 10:46 AM, Warner Losh wrote: Oh! that looks mostly right, though IIRC the higher UIDs might be something else. Harmless enough for now, though. Thanks. I also think you might be able to test if we can remove a special case kludge we have for the AMDI0020 device since it

Re: 12-BETA1 contains warning about non-PNP ISA device

On Thu, Oct 25, 2018 at 10:26 AM Rebecca Cran wrote: > On 10/25/18 10:20 AM, Rebecca Cran wrote: > > > > > uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0 > > uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1 > > uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2 >

Re: 12-BETA1 contains warning about non-PNP ISA device

On 10/25/18 10:20 AM, Rebecca Cran wrote:     uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0     uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1     uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2     uart3 pnpinfo _HID=AMDI0020 _UID=3 at handle=\_SB_.FUR3 Also, in

Re: 12-BETA1 contains warning about non-PNP ISA device

On 10/25/18 10:18 AM, Warner Losh wrote: That seems incorrect. It looks like we're attaching too much. what does devinfo -v | grep uart tell you?     uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0     uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1     uart2 pnpinfo

Re: 12-BETA1 contains warning about non-PNP ISA device

On Thu, Oct 25, 2018 at 10:16 AM Rebecca Cran wrote: > On 10/25/18 10:00 AM, Warner Losh wrote: > > > > > I suspect you can just lose those hints in the hints file and be fine. > The > > uart should attach via acpi. The keyboard won't, however, since it isn't > > enabled. Can you try removing

Re: 12-BETA1 contains warning about non-PNP ISA device

On 10/25/18 10:00 AM, Warner Losh wrote: I suspect you can just lose those hints in the hints file and be fine. The uart should attach via acpi. The keyboard won't, however, since it isn't enabled. Can you try removing these lines from your hints file and see if the problem persists? Note this

Re: 12-BETA1 contains warning about non-PNP ISA device

On Thu, Oct 25, 2018 at 9:35 AM Rebecca Cran wrote: > On 10/25/18 5:02 AM, Rodney W. Grimes wrote: > > > Can you please reply with the specific device. > > If you have seen one it may be an issue to removing it, > > especially if this is on a "new AMD" system. > > > This is a new Ryzen system.

Re: 12-BETA1 contains warning about non-PNP ISA device

On 10/25/18 5:02 AM, Rodney W. Grimes wrote: Can you please reply with the specific device. If you have seen one it may be an issue to removing it, especially if this is on a "new AMD" system. This is a new Ryzen system. For me, I get warnings about atkbdc0 and uart0: atkbdc0: at port

Re: 12-BETA1 contains warning about non-PNP ISA device

> On Thu, Oct 25, 2018 at 8:10 AM Eric van Gyzen wrote: > > > On 10/25/18 6:57 AM, Rodney W. Grimes wrote: > > >>> I noticed a warning on a new AMD system running 12-BETA1: > > >>> > > >>> non-PNP ISA device will be remove

Re: 12-BETA1 contains warning about non-PNP ISA device

On Thu, Oct 25, 2018 at 8:10 AM Eric van Gyzen wrote: > On 10/25/18 6:57 AM, Rodney W. Grimes wrote: > >>> I noticed a warning on a new AMD system running 12-BETA1: > >>> > >>> non-PNP ISA device will be removed from GENERIC in FreeBSD 12. > >&g

Re: 12-BETA1 contains warning about non-PNP ISA device

On 10/25/18 6:57 AM, Rodney W. Grimes wrote: I noticed a warning on a new AMD system running 12-BETA1: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. Can you please reply with the specific device. If you have seen one it may be an issue to removing it, especially

Re: 12-BETA1 contains warning about non-PNP ISA device

> > I noticed a warning on a new AMD system running 12-BETA1: > > > > non-PNP ISA device will be removed from GENERIC in FreeBSD 12. > Can you please reply with the specific device. > If you have seen one it may be an issue to removing it, > especially if th

fix WARNING pid 24503 (uhsoctl): ioctl sign-extension ioctl ffffffff8044692b

The following patch seems to fix the signed ioctl value warnings in uhsoctl(). The code is the same in the current and stable branches. Marcin Index: usr.sbin/uhsoctl/uhsoctl.c === --- usr.sbin/uhsoctl/uhsoctl.c (revision 339406)

Re: 12-BETA1 contains warning about non-PNP ISA device

> I noticed a warning on a new AMD system running 12-BETA1: > > non-PNP ISA device will be removed from GENERIC in FreeBSD 12. Can you please reply with the specific device. If you have seen one it may be an issue to removing it, especially if this is on a "new AMD" sys

12-BETA1 contains warning about non-PNP ISA device

I noticed a warning on a new AMD system running 12-BETA1: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. It looks like it was introduced by Warner in r327120. Should those devices have been removed already? — Rebecca ___ freebsd

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

en@head:~/head/sys/i386/conf % config -g TCP > WARNING: duplicate option `GEOM_PART_GPT' encountered. > Kernel build directory is ../compile/TCP > Don't forget to do ``make cleandepend && make depend'' > tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/ > tuexen@

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

> +.endif Using this patch I was able to build/install world and kernel on an i386 system. However, after removing it, I can't build world then. When trying to compile a kernel "the old way" I end up with: tuexen@head:~/head/sys/i386/conf % config -g TCP WARNING: duplicate option `GEOM_P

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 10:10 PM, Rebecca Cran wrote: > On 9/21/18 10:00 PM, Warner Losh wrote: > >> That may be the issue... Does the patch I included help? I'm building now >> on my stable system, but it's slow... > > It does seem to have got further this time, so a cautious yes. I can change that to a

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

One thing that may allow progress is explicitly passing the path to a new enough linker to make. In the past when some I encountered a similar problem (I use amd64-xtoolchain-gcc, amd64-gcc, and binutils for toolchain, and due to some miscommunication the wrong linker was selected automatically),

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 10:00 PM, Warner Losh wrote: > That may be the issue... Does the patch I included help? I'm building now > on my stable system, but it's slow... It does seem to have got further this time, so a cautious yes. -- Rebecca ___

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 9:57 PM, Warner Losh wrote: > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? > > They look good for me, but the only way you get this error is if they > are wrong. bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE bfd bcran@cube:~/workspace/freebsd % make -V

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:59 PM Rebecca Cran wrote: > On 9/21/18 9:57 PM, Warner Losh wrote: > > > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? > > > > They look good for me, but the only way you get this error is if they > > are wrong. > > >

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? They look good for me, but the only way you get this error is if they are wrong. Although from your typescript, I see: ===> lib/libc (cleandir) make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: amd64 libc

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:34 PM Warner Losh wrote: > > > On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote: > >> On 9/21/18 9:09 PM, Warner Losh wrote: >> >> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < >> > freebsd-toolch...@freebsd.org> wrote: >> > >> >> On 9/21/18

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 9:34 PM, Warner Losh wrote: > What does ld.lld say?  > > However, it shouldn't matter: we don't build libc until *AFTER* we > build ld.lld, so this error is bogusly triggering. I suspect that it > needs to be limited to only building targets, since tree traversal > ones, as well as

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 9:35 PM, Warner Losh wrote: > > I meant to add, can you give a few lines before the error is spewed > here in email? My IRC computer died before I could see any answers > there... > > My 11.2-stable system has 6.0.1, so I can't test from there. I've uploaded the full 'buildworld'

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote: > On 9/21/18 9:09 PM, Warner Losh wrote: > > > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < > > freebsd-toolch...@freebsd.org> wrote: > > > >> On 9/21/18 4:06 PM, Mark Johnston wrote: > >>>

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 9:09 PM, Warner Losh wrote: > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < > freebsd-toolch...@freebsd.org> wrote: > >> On 9/21/18 4:06 PM, Mark Johnston wrote: >>> https://reviews.freebsd.org/D17279 for anyone else that would like to >>> review. >> >> Is that

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < freebsd-toolch...@freebsd.org> wrote: > On 9/21/18 4:06 PM, Mark Johnston wrote: > > > > https://reviews.freebsd.org/D17279 for anyone else that would like to > > review. > > > Is that possibly related to the error I'm getting

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 9/21/18 4:06 PM, Mark Johnston wrote: > > https://reviews.freebsd.org/D17279 for anyone else that would like to > review. Is that possibly related to the error I'm getting trying to build -CURRENT on 11.2? make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: amd64 libc

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 04:37:08PM -0400, Ed Maste wrote: > On 21 September 2018 at 15:31, Mark Johnston wrote: > > > > Perhaps the following? It's not quite right since it'll still use > > -zifunc-noplt with an external LLVM toolchain, but I can't seem to > > figure out how to define a linker

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 21 September 2018 at 15:31, Mark Johnston wrote: > > Perhaps the following? It's not quite right since it'll still use > -zifunc-noplt with an external LLVM toolchain, but I can't seem to > figure out how to define a linker feature for only non-cross toolchains. > In any case, we're going to

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On Fri, Sep 21, 2018 at 02:54:04PM -0400, Ed Maste wrote: > On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain > wrote: > > In looking into another report about using devel/amd64-gcc to buld > > head I tried a build of -r338675 ( with WERROR= ). It got: > > > ... > > > > Question:

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain wrote: > In looking into another report about using devel/amd64-gcc to buld > head I tried a build of -r338675 ( with WERROR= ). It got: > ... > > Question: > > Is ignoring "-z ifunc-noplt" a problem for using what > is built?

building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

In looking into another report about using devel/amd64-gcc to buld head I tried a build of -r338675 ( with WERROR= ). It got: --- kernel.full --- linking kernel.full /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored. ctfmerge -L VERSION -g -o kernel.full ... text

Re: Current amd64 new error or warning from today's current with ruby r320323

On Tue, Jun 27, 2017 at 1:56 PM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote: > > > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > >

Re: Current amd64 new error or warning from today's current with ruby r320323

On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote: > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > > > This patch made ruby23 happy on my end.

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > > > This patch made ruby23 happy on my end. Can't say the same for > > emacs-nox11 or temacs while building

Re: Current amd64 new error or warning from today's current with ruby r320323

On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote: > > > On Jun 26, 2017, at 13:25, Konstantin Belousov wrote: > > > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov >

Re: Current amd64 new error or warning from today's current with ruby r320323

> On Jun 26, 2017, at 13:25, Konstantin Belousov wrote: > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov >> wrote: >> >>> No need, I understood why MAP_STACK failed in this

Re: Current amd64 new error or warning from today's current with ruby r320323

On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov > wrote: > > > No need, I understood why MAP_STACK failed in this case, thanks to the > > ktrace log. This is indeed something ruby-specific, or rather,

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov wrote: > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > This patch made ruby23 happy on my end. Can't say the same for > emacs-nox11 or temacs while building the former. What exactly do you mean ? Explain the behaviour and show

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote: > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov > > > wrote: > > > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: >

Re: Current amd64 new error or warning from today's current with ruby r320323

> On Jun 25, 2017, at 10:21 AM, Konstantin Belousov wrote: > > On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote: >> >>> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov >>> wrote: >>> >>> On Sun, Jun 25, 2017 at 08:21:33AM -0700,

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov > > wrote: > > > > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > >> > >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov

Re: Current amd64 new error or warning from today's current with ruby r320323

> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov wrote: > > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: >> >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov >>> wrote: >>> >>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov > > wrote: > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > >> maybe message got reformatted in mail program (mac mail). > >> could

Re: Current amd64 new error or warning from today's current with ruby r320323

> > > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > > >>>> New world and kernel r320323 > > > > > >>>> I get a new error or message when using ruby: > > > > >

Re: Current amd64 new error or warning from today's current with ruby r320323

gt; >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov > > > > >>> <kostik...@gmail.com> wrote: > > > > >>> > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > > >>

Re: Current amd64 new error or warning from today's current with ruby r320323

l.com> wrote: > > > >>> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > > > >>>> New world and kernel r320323 > > > >>>> I get a new error or message when using ruby: > > > >&

Re: Current amd64 new error or warning from today's current with ruby r320323

:08:50PM -0700, Manfred Antar wrote: > > >>>> New world and kernel r320323 > > >>>> I get a new error or message when using ruby: > > >>>> > > >>>> > > >>>> /usr/local/sbin/portupgrade -av > > >>>> : warning: p

Re: Current amd64 new error or warning from today's current with ruby r320323

Jun 24, 2017, at 6:23 PM, Konstantin Belousov <kostik...@gmail.com> > >>> wrote: > >>> > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > >>>> New world and kernel r320323 > >>>> I get a new error or mes

Re: Current amd64 new error or warning from today's current with ruby r320323

>>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: >>>> New world and kernel r320323 >>>> I get a new error or message when using ruby: >>>> >>>> >>>> /usr/local/sbin/portupgrade -av >>>>

Re: Current amd64 new error or warning from today's current with ruby r320323

> On Jun 24, 2017, at 6:55 PM, David Wolfskill wrote: > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: >> ... >>> ktrace your failing ruby invocation, then post output of kdump -H somewhere. >>> >> >> Ok not sure if this is right , but this is what i

Re: Current amd64 new error or warning from today's current with ruby r320323

323 > >> I get a new error or message when using ruby: > >> > >> > >> /usr/local/sbin/portupgrade -av > >> : warning: pthread_create failed for timer: Resource temporarily > >> unavailable, scheduling broken > >> > >> ever

Re: Current amd64 new error or warning from today's current with ruby r320323

> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov <kostik...@gmail.com> wrote: > > On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: >> New world and kernel r320323 >> I get a new error or message when using ruby: >> >> >>

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > New world and kernel r320323 > I get a new error or message when using ruby: > > > /usr/local/sbin/portupgrade -av > : warning: pthread_create failed for timer: Resource temporarily > unavailab

Current amd64 new error or warning from today's current with ruby r320323

New world and kernel r320323 I get a new error or message when using ruby: /usr/local/sbin/portupgrade -av : warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken everything works just this message when using ruby. I recompiled ruby , still same

  1   2   3   4   5   6   >