Re: change of nfsd->kernel interface in head
On Sat, Jun 30, 2018 at 06:39:57PM +, Rick Macklem wrote: > r335012 (the big patch that added the pNFS server support) revised the > nfsd->kernel > nfssvc(2) syscall interface. > It has compatibility code, so that old nfsd binaries still work. > > I now need to revise this interface again to add a new pNFS server feature. > Since the revised interface is only in head/current starting at r335012, I > believe I can revise it again without an additional compatibility shim for > r335012 or later nfsd binaries. Is this correct? > > I would post a HEADS UP to this email list and the only code affected would be > sites running current/head and using the "-p" (pNFS server) option, so they > would > be few, if any. > You are right. More, it is not clear if nfsd interface should be considered part of the stable contract even on stable. It is clearly the management interface, nfsd is not required to get the system operational enough to install the right nfsd. If possible, stable should not add more troubles for upgrade, while for HEAD it does not matter. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 11:53 AM, John Baldwin wrote: > On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] > > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: >>> >>> Yes, but this is kind of a feature, not a bug, and the issue there is that >>> as much as possible we should allow FreeBSD to work with the standard >>> headers >>> that are supposed to be part of the language (and thus provided by the >>> toolchain). Right now we don't ship any of the 'std*.h' headers clang >>> provides for example in our base system clang, though a few months ago I >>> fixed the one place that was using instead of >>> in userland that was breaking the use of the toolchain-provided >>> stdarg.h (both GCC and clang). >>> Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? >>> >>> It depends on the header. This particular failure is due to a quirk of >>> on FreeBSD/i386. I have built other platforms with external >>> GCC just fine. To the extent that we encounter any other issues we >>> should try to make our source more conformant with C and only fall back to >>> axeing the toolchain-provided language headers as a last resort. >> >> It is too bad that the review https://reviews.freebsd.org/D16055 did not >> catch the change in what headers are used by buildworld and buildkernel. >> I'd view such switching of long established header bindings as a >> fairly big deal, possibly even warranting being explicitly proposed and >> debated. >> >> I'm not claiming my opinion on which search order that I have is >> actually relevant. I'm just now nervous about my powerpc64-gcc based >> builds having unexpected differences, for example. [I sometimes explore >> the status of powerpc family builds via more modern toolchains.] >> >> (But lib32 for powerpc64 via modern gcc's is messed up anyway, >> generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about >> that.) > > Looks like my being nervous is justified: there is a conflicting altivec.h > that has nothing to do with C/C++ language standards: > > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h spe.h > stdarg.hstddef.hstdint.h > varargs.h > float.h iso646.hppu_intrinsics.h > spu2vmx.h stdatomic.h stdfix.h > stdnoreturn.h vec_types.h > htmintrin.h paired.hsi2vmx.h > stdalign.h stdbool.h stdint-gcc.h > tgmath.h > > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h > > Actually, that is a compiler intrinsincs header similar to the , > etc. headers used for SSE on x86 that are always provided by the compiler. > However, this header is '' not '' so it won't > conflict. > > (On x86, these headers provide the _mm_* functions documented in Intel's > SDM as the official C bindings for vector extensions, and > probably plays a similar role in providing the vendor-specified C > bindings for altivec instructions.) [This is based on a -r335812 build still.] If I have a modern gcc build a system that includes building the system clang, I do not expect it is that simple. There is: /usr/src/contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:#include and altivec.h files around: /usr/lib/clang/6.0.0/include/altivec.h /usr/src/contrib/llvm/tools/clang/lib/Headers/altivec.h /usr/src/contrib/gcc/config/rs6000/altivec.h /usr/src/sys/powerpc/include/altivec.h /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/altivec.h
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] > > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: >>> >>> Yes, but this is kind of a feature, not a bug, and the issue there is that >>> as much as possible we should allow FreeBSD to work with the standard >>> headers >>> that are supposed to be part of the language (and thus provided by the >>> toolchain). Right now we don't ship any of the 'std*.h' headers clang >>> provides for example in our base system clang, though a few months ago I >>> fixed the one place that was using instead of >>> in userland that was breaking the use of the toolchain-provided >>> stdarg.h (both GCC and clang). >>> Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? >>> >>> It depends on the header. This particular failure is due to a quirk of >>> on FreeBSD/i386. I have built other platforms with external >>> GCC just fine. To the extent that we encounter any other issues we >>> should try to make our source more conformant with C and only fall back to >>> axeing the toolchain-provided language headers as a last resort. >> >> It is too bad that the review https://reviews.freebsd.org/D16055 did not >> catch the change in what headers are used by buildworld and buildkernel. >> I'd view such switching of long established header bindings as a >> fairly big deal, possibly even warranting being explicitly proposed and >> debated. >> >> I'm not claiming my opinion on which search order that I have is >> actually relevant. I'm just now nervous about my powerpc64-gcc based >> builds having unexpected differences, for example. [I sometimes explore >> the status of powerpc family builds via more modern toolchains.] >> >> (But lib32 for powerpc64 via modern gcc's is messed up anyway, >> generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about >> that.) > > Looks like my being nervous is justified: there is a conflicting altivec.h > that has nothing to do with C/C++ language standards: > > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h spe.h > stdarg.hstddef.hstdint.h > varargs.h > float.h iso646.hppu_intrinsics.h > spu2vmx.h stdatomic.h stdfix.h > stdnoreturn.h vec_types.h > htmintrin.h paired.hsi2vmx.h > stdalign.h stdbool.h stdint-gcc.h > tgmath.h > > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h Actually, that is a compiler intrinsincs header similar to the , etc. headers used for SSE on x86 that are always provided by the compiler. However, this header is '' not '' so it won't conflict. (On x86, these headers provide the _mm_* functions documented in Intel's SDM as the official C bindings for vector extensions, and probably plays a similar role in providing the vendor-specified C bindings for altivec instructions.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
change of nfsd->kernel interface in head
r335012 (the big patch that added the pNFS server support) revised the nfsd->kernel nfssvc(2) syscall interface. It has compatibility code, so that old nfsd binaries still work. I now need to revise this interface again to add a new pNFS server feature. Since the revised interface is only in head/current starting at r335012, I believe I can revise it again without an additional compatibility shim for r335012 or later nfsd binaries. Is this correct? I would post a HEADS UP to this email list and the only code affected would be sites running current/head and using the "-p" (pNFS server) option, so they would be few, if any. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > >> On 6/30/18 9:17 AM, Mark Millard wrote: >>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >>> On 6/29/18 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] As indicated by my other mail, this is i386 and amd64 specific as it only matters for float.h on i386 due to the disagreement on LDBL_MANT_DIG. >>> >>> I was correct about the search order for include files being >>> different before -r335782 vs. -r335782 and later: >> >> Yes, but this is kind of a feature, not a bug, and the issue there is that >> as much as possible we should allow FreeBSD to work with the standard headers >> that are supposed to be part of the language (and thus provided by the >> toolchain). Right now we don't ship any of the 'std*.h' headers clang >> provides for example in our base system clang, though a few months ago I >> fixed the one place that was using instead of >> in userland that was breaking the use of the toolchain-provided >> stdarg.h (both GCC and clang). >> >>> Might this reversal have other effects even for >>> architectures for which the code does compile >>> via devel/*-gcc ? >> >> It depends on the header. This particular failure is due to a quirk of >> on FreeBSD/i386. I have built other platforms with external >> GCC just fine. To the extent that we encounter any other issues we >> should try to make our source more conformant with C and only fall back to >> axeing the toolchain-provided language headers as a last resort. > > It is too bad that the review https://reviews.freebsd.org/D16055 did not > catch the change in what headers are used by buildworld and buildkernel. > I'd view such switching of long established header bindings as a > fairly big deal, possibly even warranting being explicitly proposed and > debated. > > I'm not claiming my opinion on which search order that I have is > actually relevant. I'm just now nervous about my powerpc64-gcc based > builds having unexpected differences, for example. [I sometimes explore > the status of powerpc family builds via more modern toolchains.] > > (But lib32 for powerpc64 via modern gcc's is messed up anyway, > generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about > that.) Looks like my being nervous is justified: there is a conflicting altivec.h that has nothing to do with C/C++ language standards: # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ altivec.h htmxlintrin.h ppc-asm.h spe.h stdarg.hstddef.hstdint.h varargs.h float.h iso646.hppu_intrinsics.h spu2vmx.h stdatomic.h stdfix.h stdnoreturn.h vec_types.h htmintrin.h paired.hsi2vmx.h stdalign.h stdbool.h stdint-gcc.htgmath.h I've not checked for other name conflicts vs. FreeBSD. I just happen to recognize altivec.h . There is: /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > On 6/30/18 9:17 AM, Mark Millard wrote: >> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >> >>> On 6/29/18 2:37 PM, Mark Millard wrote: [I expect this is more than just amd64-gcc related but that is all that ci.freebsd.org normally builds via a devel/*-gcc .] >>> >>> As indicated by my other mail, this is i386 and amd64 specific as it >>> only matters for float.h on i386 due to the disagreement on >>> LDBL_MANT_DIG. >> >> I was correct about the search order for include files being >> different before -r335782 vs. -r335782 and later: > > Yes, but this is kind of a feature, not a bug, and the issue there is that > as much as possible we should allow FreeBSD to work with the standard headers > that are supposed to be part of the language (and thus provided by the > toolchain). Right now we don't ship any of the 'std*.h' headers clang > provides for example in our base system clang, though a few months ago I > fixed the one place that was using instead of > in userland that was breaking the use of the toolchain-provided > stdarg.h (both GCC and clang). > >> Might this reversal have other effects even for >> architectures for which the code does compile >> via devel/*-gcc ? > > It depends on the header. This particular failure is due to a quirk of > on FreeBSD/i386. I have built other platforms with external > GCC just fine. To the extent that we encounter any other issues we > should try to make our source more conformant with C and only fall back to > axeing the toolchain-provided language headers as a last resort. It is too bad that the review https://reviews.freebsd.org/D16055 did not catch the change in what headers are used by buildworld and buildkernel. I'd view such switching of long established header bindings as a fairly big deal, possibly even warranting being explicitly proposed and debated. I'm not claiming my opinion on which search order that I have is actually relevant. I'm just now nervous about my powerpc64-gcc based builds having unexpected differences, for example. [I sometimes explore the status of powerpc family builds via more modern toolchains.] (But lib32 for powerpc64 via modern gcc's is messed up anyway, generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about that.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/30/18 9:17 AM, Mark Millard wrote: > On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > >> On 6/29/18 2:37 PM, Mark Millard wrote: >>> [I expect this is more than just amd64-gcc related but that is all >>> that ci.freebsd.org normally builds via a devel/*-gcc .] >> >> As indicated by my other mail, this is i386 and amd64 specific as it >> only matters for float.h on i386 due to the disagreement on >> LDBL_MANT_DIG. > > I was correct about the search order for include files being > different before -r335782 vs. -r335782 and later: Yes, but this is kind of a feature, not a bug, and the issue there is that as much as possible we should allow FreeBSD to work with the standard headers that are supposed to be part of the language (and thus provided by the toolchain). Right now we don't ship any of the 'std*.h' headers clang provides for example in our base system clang, though a few months ago I fixed the one place that was using instead of in userland that was breaking the use of the toolchain-provided stdarg.h (both GCC and clang). > Might this reversal have other effects even for > architectures for which the code does compile > via devel/*-gcc ? It depends on the header. This particular failure is due to a quirk of on FreeBSD/i386. I have built other platforms with external GCC just fine. To the extent that we encounter any other issues we should try to make our source more conformant with C and only fall back to axeing the toolchain-provided language headers as a last resort. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] > > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: head -r335812 uses the gcc headers (and fails): ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include End of search list. head -r335245 uses the FreeBSD headers and works: ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" ignoring duplicate directory "/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include End of search list. Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/29/18 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] As indicated by my other mail, this is i386 and amd64 specific as it only matters for float.h on i386 due to the disagreement on LDBL_MANT_DIG. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r335813 [ broke ci.freebsd.org 's FreeBSD-head-{aarch64,amd64,i386}-build ]
On 30 Jun 2018, at 15:22, Mark Millard wrote: > > https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8358/consoleText > > --- all_subdir_armv8crypto --- > /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:10: fatal error: > 'arm_neon.h' file not found > #include > ^~~~ > 1 error generated. > *** [armv8_crypto_wrap.o] Error code 1 > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9268/consoleText > > --- lib/liblzma__L --- > In file included from /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23: > /usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal error: > 'immintrin.h' file not found > # include >^ > 1 error generated. > *** [lz_encoder.o] Error code 1 Yeah, sorry about that, working on it now. I'm awaiting a full build to see if there are any other issues. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: svn commit: r335813 [ broke ci.freebsd.org 's FreeBSD-head-{aarch64,amd64,i386}-build ]
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/8358/consoleText --- all_subdir_armv8crypto --- /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:10: fatal error: 'arm_neon.h' file not found #include ^~~~ 1 error generated. *** [armv8_crypto_wrap.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9268/consoleText --- lib/liblzma__L --- In file included from /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23: /usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal error: 'immintrin.h' file not found # include ^ 1 error generated. *** [lz_encoder.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-i386-build/8370/consoleText --- aesni_ghash.o --- cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/i386.i386/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -g -I/usr/obj/usr/src/i386.i386/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -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 -Wno-error-cast-qual -mno-aes -mno-avx -std=iso9899:1999 -Werror -mmmx -msse -msse4 -maes -mpc lmul /usr/src/sys/crypto/aesni/aesni_ghash.c /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' file not found #include ^ 1 error generated. *** [aesni_ghash.o] Error code 1 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DNSSEC/Log Spam for partially DNSSEC domain
On 30 Jun 2018, at 04:03, Larry Rosenman wrote: > > I'm running Exim, with DNSSEC enabled, and my zone (lerctr.org) is > DNSSEC signed, but my dyn.lerctr.org subdomain is NOT DNSSEC signed due > to HE.net don't support DNSSEC. > > I get a ton of: > Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked for > "borg.lerctr.org IN ", got type "RRSIG" > Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked for > "borg.lerctr.org IN A", got type "RRSIG" > > in my logs, which comes from libc: > /usr/src/lib/libc/net/getaddrinfo.c: > 2092 #ifdef DEBUG > 2093 if (type != T_KEY && type != T_SIG && > 2094 type != ns_t_dname) > 2095 syslog(LOG_NOTICE|LOG_AUTH, > 2096"gethostby*.getanswer: asked for \"%s %s %s\", got type > \"%s\"", > 2097qname, p_class(C_IN), > p_type(qtype), > 2098p_type(type)); > 2099 #endif > > Is there an easy way to make this quieter? I see this code is only included if DEBUG is defined. Maybe undefine DEBUG, for this particular file? Or hack it so it has #undef DEBUG at the top? That said, I'm not sure if debug messages like this should be enabled by default, and impossible to squelch without recompiling libc. So maybe we should #if 0 it, instead. -Dimitry signature.asc Description: Message signed with OpenPGP
