Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
Am 19.06.19 um 21:20 schrieb Bryan Drewery:
> On 6/19/19 11:05 AM, Bryan Drewery wrote:
>> On 6/19/19 11:02 AM, Bryan Drewery wrote:
>>> On 6/16/19 9:33 AM, Warner Losh wrote:
On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling wrote:
> If I try to build world almost recent sources (r349100) on HEAD amd64
> (r348775), it stops with the following error:
>
>
> [..snip..]
> (cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.libkern_crc32
> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
> PROG=libkern_crc32 )
> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
> .depend.libkern_crc32
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe
> -DUSERSPACE_TESTING -MD -MF.depend.libkern_crc32.libkern_crc32.o
> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Qunused-arguments -c
> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-address-of-packed-member
> -Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
> libkern_crc32.o /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
> ld: error: duplicate symbol: sse42_crc32c
defined at crc32_sse42.c
/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
defined at crc32_sse42.c
/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [libkern_crc32] Error code 1
> make[6]: stopped in /usr/src/tests/sys/kern
> 1 error
> make[6]: stopped in /usr/src/tests/sys/kern
> *** [libkern_crc32] Error code 2
>
>
> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
> II X6 1090T).
>
> Am I the only one, who observes this breakage? Thanks for any hint.
>
Try adding -DWITHOUT_TESTS to buildworld...
Warner
>>>
>>> ~/git/freebsd2/tests/sys/kern # env|grep TEST
>>> MK_TESTS=no
>>>
>>>
>>> Doh. Turns out I've had TESTS disabled in some of my recent build tests
>>> / commits. This is likely my fault.
>>>
>>
>> Yup it is from my r349065.
>>
>> It's an ambiguity between LDADD. and my newly added
>> LDADD..
>>
>> LDADD.libkern_crc32+= ${SRCTOP}/sys/libkern/x86/crc32_sse42.c
>>
>> So it's added in twice.
>>
>>
>
> This should be fixed in r349202. Sorry for the trouble.
>
Many thanks for this fix. It works fine for me on the box with Intel
Core 17-4770, but it fails on AMD Phenom II X6 1090T (both systems
mentioned in the initial mail):
[..snip..]
c++ -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe
-I/usr/src/contrib/llvm/tools/lldb/include
-I/usr/src/contrib/llvm/tools/lldb/source
-I/usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD
-I/usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/POSIX
-I/usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/Utility
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm
-I/usr/obj/usr/src/amd64.amd64/lib/clang/libclang -DLLDB_DISABLE_PYTHON
-I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT
-DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\"
-DLLVM_TARGET_ENABLE_X86
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target
-DLLVM_NATIVE_TAR
Re: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 7:55 PM Alan Somers wrote: > On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: > > > > > > > > On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: > >> > >> On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > >> > > >> > > >> > > >> > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers > wrote: > >> >> > >> >> Does anybody know how to check out a local copy of the CSRG > >> >> repository? I can view it with ViewVC, but I would really like local > >> >> access. It doesn't seem to be available on the usual > repo.FreeBSD.org > >> >> or svn.FreeBSD.org. > >> >> > >> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg > >> >> svn: E170013: Unable to connect to a repository at URL > >> >> 'https://svn.freebsd.org/csrg' > >> >> svn: E175009: The XML response contains invalid XML > >> >> svn: E130003: Malformed XML: no element found at line 1 > >> >> > >> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > >> >> svn: E170013: Unable to connect to a repository at URL > >> >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > >> >> svn: E210005: No repository found in 'svn+ssh:// > asom...@repo.freebsd.org/csrg' > >> > > >> > > >> > Can't answer this question directly about svn > >> > > >> > But I have been using > https://github.com/dspinellis/unix-history-repo.git to look at historical > sources. https://github.com/csrg has a number of additional repos of > historical interest, though they are all forks from somewhere else. > >> > > >> > Warner > >> > >> Thanks for that Github link; it's pretty useful. Also, I found this > >> site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just > >> wish I had a better understanding of the relationship between CSRG and > >> the various releases. It seems like some stuff got committed to CSRG > >> yet didn't make it into an official release for years, if ever. > > > > > > TUHS is awesome. I use it too, bit the historical github tree is more > convenient. > > > > CSRG's 4.x series was pretty linear. What didn't make it? > > > > Warner > > I'm looking at bmap. When I wrote that email, the earliest released > reference I could find was in 4.3-Reno. However, I just spotted it in > 4.2, which is a much more reasonable time frame (it moved to a > different file which is why I missed it before). However, the files > in question don't even exist in the git branches from dspinellis's > repository. I had to find them on tuhs.org. Am I doing something > wrong, or are dspinellis's release branches not fully populated? > Compare > https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys > to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys I'm guessing the SCCS -> SVN -> Git process broke files that were renamed or copied... I've not dug deeper though... This tells me that we need to send dspinellis some corrections :) Warner ___ 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: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 8:41 PM Warner Losh wrote: > > > > On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: >> >> On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: >> > >> > >> > >> > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: >> >> >> >> Does anybody know how to check out a local copy of the CSRG >> >> repository? I can view it with ViewVC, but I would really like local >> >> access. It doesn't seem to be available on the usual repo.FreeBSD.org >> >> or svn.FreeBSD.org. >> >> >> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg >> >> svn: E170013: Unable to connect to a repository at URL >> >> 'https://svn.freebsd.org/csrg' >> >> svn: E175009: The XML response contains invalid XML >> >> svn: E130003: Malformed XML: no element found at line 1 >> >> >> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg >> >> svn: E170013: Unable to connect to a repository at URL >> >> 'svn+ssh://asom...@repo.freebsd.org/csrg' >> >> svn: E210005: No repository found in >> >> 'svn+ssh://asom...@repo.freebsd.org/csrg' >> > >> > >> > Can't answer this question directly about svn >> > >> > But I have been using https://github.com/dspinellis/unix-history-repo.git >> > to look at historical sources. https://github.com/csrg has a number of >> > additional repos of historical interest, though they are all forks from >> > somewhere else. >> > >> > Warner >> >> Thanks for that Github link; it's pretty useful. Also, I found this >> site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just >> wish I had a better understanding of the relationship between CSRG and >> the various releases. It seems like some stuff got committed to CSRG >> yet didn't make it into an official release for years, if ever. > > > TUHS is awesome. I use it too, bit the historical github tree is more > convenient. > > CSRG's 4.x series was pretty linear. What didn't make it? > > Warner I'm looking at bmap. When I wrote that email, the earliest released reference I could find was in 4.3-Reno. However, I just spotted it in 4.2, which is a much more reasonable time frame (it moved to a different file which is why I missed it before). However, the files in question don't even exist in the git branches from dspinellis's repository. I had to find them on tuhs.org. Am I doing something wrong, or are dspinellis's release branches not fully populated? Compare https://github.com/dspinellis/unix-history-repo/tree/BSD-4_3_Reno-Snapshot-Development/usr/src/sys/sys to https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/sys/sys . -Alan ___ 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: Checking out the CSRG repository?
On Wed, Jun 19, 2019, 7:09 PM Alan Somers wrote: > On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > > > > > > > > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: > >> > >> Does anybody know how to check out a local copy of the CSRG > >> repository? I can view it with ViewVC, but I would really like local > >> access. It doesn't seem to be available on the usual repo.FreeBSD.org > >> or svn.FreeBSD.org. > >> > >> $ svn checkout https://svn.FreeBSD.org/csrg csrg > >> svn: E170013: Unable to connect to a repository at URL > >> 'https://svn.freebsd.org/csrg' > >> svn: E175009: The XML response contains invalid XML > >> svn: E130003: Malformed XML: no element found at line 1 > >> > >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > >> svn: E170013: Unable to connect to a repository at URL > >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > >> svn: E210005: No repository found in 'svn+ssh:// > asom...@repo.freebsd.org/csrg' > > > > > > Can't answer this question directly about svn > > > > But I have been using > https://github.com/dspinellis/unix-history-repo.git to look at historical > sources. https://github.com/csrg has a number of additional repos of > historical interest, though they are all forks from somewhere else. > > > > Warner > > Thanks for that Github link; it's pretty useful. Also, I found this > site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just > wish I had a better understanding of the relationship between CSRG and > the various releases. It seems like some stuff got committed to CSRG > yet didn't make it into an official release for years, if ever. > TUHS is awesome. I use it too, bit the historical github tree is more convenient. CSRG's 4.x series was pretty linear. What didn't make it? Warner > ___ 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: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 5:38 PM Warner Losh wrote: > > > > On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: >> >> Does anybody know how to check out a local copy of the CSRG >> repository? I can view it with ViewVC, but I would really like local >> access. It doesn't seem to be available on the usual repo.FreeBSD.org >> or svn.FreeBSD.org. >> >> $ svn checkout https://svn.FreeBSD.org/csrg csrg >> svn: E170013: Unable to connect to a repository at URL >> 'https://svn.freebsd.org/csrg' >> svn: E175009: The XML response contains invalid XML >> svn: E130003: Malformed XML: no element found at line 1 >> >> $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg >> svn: E170013: Unable to connect to a repository at URL >> 'svn+ssh://asom...@repo.freebsd.org/csrg' >> svn: E210005: No repository found in >> 'svn+ssh://asom...@repo.freebsd.org/csrg' > > > Can't answer this question directly about svn > > But I have been using https://github.com/dspinellis/unix-history-repo.git to > look at historical sources. https://github.com/csrg has a number of > additional repos of historical interest, though they are all forks from > somewhere else. > > Warner Thanks for that Github link; it's pretty useful. Also, I found this site to be helpful: https://www.tuhs.org/cgi-bin/utree.pl . I just wish I had a better understanding of the relationship between CSRG and the various releases. It seems like some stuff got committed to CSRG yet didn't make it into an official release for years, if ever. -Alan ___ 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: Checking out the CSRG repository?
> > From: Alan Somers > > Date: Wed, 19 Jun 2019 14:12:21 -0600 > > Subject: Checking out the CSRG repository? > > To: FreeBSD CURRENT > > > > Does anybody know how to check out a local copy of the CSRG > > repository? I can view it with ViewVC, but I would really like local > > access. It doesn't seem to be available on the usual repo.FreeBSD.org > > or svn.FreeBSD.org. > > > > $ svn checkout https://svn.FreeBSD.org/csrg csrg > > svn: E170013: Unable to connect to a repository at URL > > 'https://svn.freebsd.org/csrg' > > svn: E175009: The XML response contains invalid XML > > svn: E130003: Malformed XML: no element found at line 1 > > > > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > > svn: E170013: Unable to connect to a repository at URL > > 'svn+ssh://asom...@repo.freebsd.org/csrg' > > svn: E210005: No repository found in > > 'svn+ssh://asom...@repo.freebsd.org/csrg' > > > > -Alan > > ___ > > 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" > > You can browse the history at http://svnweb.freebsd.org/csrg/ Since svnweb seems to be able to get to it there should be a near 0 cost of making this work with a straight svn checkout as Alan originally asked for. It is probably something missing, or not configured so that the checkout "can just work". > The repository is also available via FTP: > > ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz > > Hope this helps, Thank you, mirroring locally to my repo server so I can infact use svn directly on it. > Kirk McKusick -- Rod Grimes rgri...@freebsd.org ___ 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: Checking out the CSRG repository?
> From: Alan Somers > Date: Wed, 19 Jun 2019 14:12:21 -0600 > Subject: Checking out the CSRG repository? > To: FreeBSD CURRENT > > Does anybody know how to check out a local copy of the CSRG > repository? I can view it with ViewVC, but I would really like local > access. It doesn't seem to be available on the usual repo.FreeBSD.org > or svn.FreeBSD.org. > > $ svn checkout https://svn.FreeBSD.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'https://svn.freebsd.org/csrg' > svn: E175009: The XML response contains invalid XML > svn: E130003: Malformed XML: no element found at line 1 > > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'svn+ssh://asom...@repo.freebsd.org/csrg' > svn: E210005: No repository found in 'svn+ssh://asom...@repo.freebsd.org/csrg' > > -Alan > ___ > 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" You can browse the history at http://svnweb.freebsd.org/csrg/ The repository is also available via FTP: ftp://ftp.freebsd.org/pub/FreeBSD/development/CSRG/csrg_svn.tbz Hope this helps, Kirk McKusick ___ 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: Checking out the CSRG repository?
On Wed, Jun 19, 2019 at 1:14 PM Alan Somers wrote: > Does anybody know how to check out a local copy of the CSRG > repository? I can view it with ViewVC, but I would really like local > access. It doesn't seem to be available on the usual repo.FreeBSD.org > or svn.FreeBSD.org. > > $ svn checkout https://svn.FreeBSD.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'https://svn.freebsd.org/csrg' > svn: E175009: The XML response contains invalid XML > svn: E130003: Malformed XML: no element found at line 1 > > $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg > svn: E170013: Unable to connect to a repository at URL > 'svn+ssh://asom...@repo.freebsd.org/csrg' > svn: E210005: No repository found in 'svn+ssh:// > asom...@repo.freebsd.org/csrg' > Can't answer this question directly about svn But I have been using https://github.com/dspinellis/unix-history-repo.git to look at historical sources. https://github.com/csrg has a number of additional repos of historical interest, though they are all forks from somewhere else. Warner ___ 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"
Checking out the CSRG repository?
Does anybody know how to check out a local copy of the CSRG repository? I can view it with ViewVC, but I would really like local access. It doesn't seem to be available on the usual repo.FreeBSD.org or svn.FreeBSD.org. $ svn checkout https://svn.FreeBSD.org/csrg csrg svn: E170013: Unable to connect to a repository at URL 'https://svn.freebsd.org/csrg' svn: E175009: The XML response contains invalid XML svn: E130003: Malformed XML: no element found at line 1 $ svn co svn+ssh://asom...@repo.freebsd.org/csrg csrg svn: E170013: Unable to connect to a repository at URL 'svn+ssh://asom...@repo.freebsd.org/csrg' svn: E210005: No repository found in 'svn+ssh://asom...@repo.freebsd.org/csrg' -Alan ___ 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: sys/modules/sdio broken in .svn_revision 348842 'opt_cam.h' not found
On 6/17/19 6:46 PM, Julian H. Stacey wrote: > Hi, Reference: >> From:Ian Lepore >> Date:Mon, 17 Jun 2019 18:56:35 -0600 > > Ian Lepore wrote: >> On Tue, 2019-06-18 at 02:21 +0200, Julian H. Stacey wrote: >>> "Julian H. Stacey" wrote: "Bjoern A. Zeeb" wrote: > On 17 Jun 2019, at 10:37, Mark Linimon wrote: > >> On Mon, Jun 17, 2019 at 11:41:03AM +0200, Julian H. Stacey >> wrote: >>> svn_revision 348842 >> >> [ ...] >>> /usr/src/sys/modules/sdio/../../dev/sdio/sdiob.c:68:10: fatal >>> error: >>> 'opt_cam.h' file not found >>> #include "opt_cam.h" >>> ^~~ >>> 1 error generated. >> >> This is extremely unlikely to be r348842. I would investigate >> r349025 >> instead. (Committer Cc:ed.) > > Almost, more likely me. I just had a look. I am not exactly > sure how > to reproduce this? > > /bz If I can help let me know. My buildworld broke with 13.0-CURRENT /usr/src .ctm_status src-cur 14077 .svn_revision 348842 I'm now running make install, & can then compare my root include & libs with with a set installed using DESTDIR= >>> >>> I compiled, installed, compared. >>> BTW cd /usr/src; make delete - only cleans libs & bins but does >>> not >>> clean other junk listed in ObsoleteFiles.inc not even with >>> -DBATCH_DELETE_OLD_FILES or -DBATCH_DELETE_OLD_FILES=YES so >>> manually purged, >>> I believe I have a clean system built from .ctm_status src-cur 14077 >>> .svn_revision 348842 but /usr/src/sys/modules/sdio still fails, >>> so there was a commit of unbuildable code. >>> >>> cd /usr/src ; find . -name opt_cam.h# tools/tools/vhba/opt_cam.h >>> cd /usr/include ; find . -name opt_cam.h# nothing >>> >>> I have a 2nd slower current box also building to 14077, I will then take that on up to latest .ctm_status src-cur 14087 .svn_revision 349129 to see if problem clears. >>> >>> make buildworld blew on newer current, with a different bug: >>> >>> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static >>> -I/usr/src/usr.bin/mkesdb_static/../mkesdb - >>> I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -MD - >>> MF.depend.lex.o -MTlex.o -std=gnu99 -Qunused-arguments - >>> I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c lex.c -o >>> lex.o >>> /usr/src/usr.bin/mkesdb/lex.l:46:10: fatal error: 'yacc.h' file not >>> found >>> #include "yacc.h" >>> ^~~~ >>> 1 error generated. >>> *** Error code 1 >>> >>> Stop. >>> make[3]: stopped in /usr/src/usr.bin/mkesdb_static >>> >>> A double waste of CPU & human time & power in a hot office. >>> Commit bits used to be suspended for un-buildable code. I'll boot >>> stable. >> >> Since you seem to be so focused on mean-spirited criticism of others, >> I'm sure you'll understand when I ask... >> >> Have you *seriosly* been using and building freebsd this long and you >> don't know that an opt_*.h file is generated as part of the build and >> exists only in the object directory, so that searching for it under >> /usr/src or /usr/include would be... let's see, how did you put it?... >> Oh yeah: A double waste of CPU & human time. > > Personal noise is irrelevant. > > Facts: > Unchecked commits broken make buildworld twice, > Time was wasted by bad commits. > My time ran out. > Current does not benefit from commits that break buildworld. > I (like a friend before) must switch to stable to avoid breakage. > > Time was, ~25 years back, when FreeBSD commiters who screwed > the build were awarded a conical hat & took a one week holiday. A > mild rebuke for wasting people's time, & a short refreshing > break to go smell fresh air. No not coffee, but fresh air. > > Cheers, > Julian > As the committer who broke yacc.h I'm sorry. I understand the frustration. I too get frustrated by build breakage from others and even myself. I appreciate the cc's here. I did test this particular change with 1. clean build 2. -DNO_CLEAN 3. CLEANDIR=clean + -DNO_CLEAN (to really rebuild everything but reuse the .depend files). And similar pattern with META_MODE. And a cross-build of powerpc.powerpc64 to capture some gcc deps and ensure cross-build was running the right binaries. I missed not using -j though, that's a really odd case I'll never test frankly. Worse my build environment had MK_TESTS=no in it so I missed some other bugs. What I didn't test: buildkernel, install*, universe, ports (the last 2 will likely bite me still). It's pretty common for all of us to forget to test installworld and ports. Again this brings up the need for a real build test suite that can be used pre-commit. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Compiling issues
On 18 Jun 2019, at 23:26, Aaron Farias wrote: > > Hello good evening can someone help me out with this issue > [ 7%] Building CXX object src/CMakeFiles/services.dir/access.o > In file included from /home/Dark/Downloads/anope-2.0.6/src/access.cpp:12: > In file included from /home/Dark/Downloads/anope-2.0.6/include/service.h:15: > In file included from /home/Dark/Downloads/anope-2.0.6/include/services.h:22: > In file included from /usr/include/c++/v1/stdexcept:46: > In file included from /usr/include/c++/v1/exception:81: > In file included from /usr/include/c++/v1/cstddef:38: > /home/Dark/Downloads/anope-2.0.6/include/version:1:1: error: expected > unqualified-id > ELF ... > ^ > /home/Dark/Downloads/anope-2.0.6/include/version:2:208: error: source file is > not valid UTF-8 Yes, you seem to have a file called "version" in your include path, and you need to either rename it, or remove the directory containing the file from your include path. Unfortunately recent versions of libc++ include the standards-mandated header [1], which will now by default conflict with any file named as such in your project. See also https://bugs.freebsd.org/236192. -Dimitry [1] https://en.cppreference.com/w/cpp/header/version signature.asc Description: Message signed with OpenPGP
Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
On 6/19/19 11:05 AM, Bryan Drewery wrote:
> On 6/19/19 11:02 AM, Bryan Drewery wrote:
>> On 6/16/19 9:33 AM, Warner Losh wrote:
>>> On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling wrote:
>>>
If I try to build world almost recent sources (r349100) on HEAD amd64
(r348775), it stops with the following error:
[..snip..]
(cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.libkern_crc32
NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
PROG=libkern_crc32 )
echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
.depend.libkern_crc32
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe
-DUSERSPACE_TESTING -MD -MF.depend.libkern_crc32.libkern_crc32.o
-MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Qunused-arguments -c
/usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-Wno-unused-local-typedef -Wno-address-of-packed-member
-Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
libkern_crc32.o /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
/usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
ld: error: duplicate symbol: sse42_crc32c
>>> defined at crc32_sse42.c
>>>/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
>>> defined at crc32_sse42.c
>>>/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [libkern_crc32] Error code 1
make[6]: stopped in /usr/src/tests/sys/kern
1 error
make[6]: stopped in /usr/src/tests/sys/kern
*** [libkern_crc32] Error code 2
This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
II X6 1090T).
Am I the only one, who observes this breakage? Thanks for any hint.
>>>
>>> Try adding -DWITHOUT_TESTS to buildworld...
>>>
>>> Warner
>>>
>>
>> ~/git/freebsd2/tests/sys/kern # env|grep TEST
>> MK_TESTS=no
>>
>>
>> Doh. Turns out I've had TESTS disabled in some of my recent build tests
>> / commits. This is likely my fault.
>>
>
> Yup it is from my r349065.
>
> It's an ambiguity between LDADD. and my newly added
> LDADD..
>
> LDADD.libkern_crc32+= ${SRCTOP}/sys/libkern/x86/crc32_sse42.c
>
> So it's added in twice.
>
>
This should be fixed in r349202. Sorry for the trouble.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
On 6/19/19 11:02 AM, Bryan Drewery wrote:
> On 6/16/19 9:33 AM, Warner Losh wrote:
>> On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling wrote:
>>
>>> If I try to build world almost recent sources (r349100) on HEAD amd64
>>> (r348775), it stops with the following error:
>>>
>>>
>>> [..snip..]
>>> (cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.libkern_crc32
>>> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
>>> PROG=libkern_crc32 )
>>> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
>>> .depend.libkern_crc32
>>> cc -target x86_64-unknown-freebsd13.0
>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe
>>> -DUSERSPACE_TESTING -MD -MF.depend.libkern_crc32.libkern_crc32.o
>>> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
>>> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
>>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>>> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
>>> -Wno-string-plus-int -Wno-unused-const-variable
>>> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
>>> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
>>> -Wno-address-of-packed-member -Qunused-arguments -c
>>> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
>>> cc -target x86_64-unknown-freebsd13.0
>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
>>> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
>>> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
>>> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
>>> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
>>> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
>>> -Wno-unused-local-typedef -Wno-address-of-packed-member
>>> -Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
>>> libkern_crc32.o /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
>>> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
>>> ld: error: duplicate symbol: sse42_crc32c
>> defined at crc32_sse42.c
>>/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
>> defined at crc32_sse42.c
>>/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
>>> cc: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>> *** [libkern_crc32] Error code 1
>>> make[6]: stopped in /usr/src/tests/sys/kern
>>> 1 error
>>> make[6]: stopped in /usr/src/tests/sys/kern
>>> *** [libkern_crc32] Error code 2
>>>
>>>
>>> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
>>> II X6 1090T).
>>>
>>> Am I the only one, who observes this breakage? Thanks for any hint.
>>>
>>
>> Try adding -DWITHOUT_TESTS to buildworld...
>>
>> Warner
>>
>
> ~/git/freebsd2/tests/sys/kern # env|grep TEST
> MK_TESTS=no
>
>
> Doh. Turns out I've had TESTS disabled in some of my recent build tests
> / commits. This is likely my fault.
>
Yup it is from my r349065.
It's an ambiguity between LDADD. and my newly added
LDADD..
LDADD.libkern_crc32+= ${SRCTOP}/sys/libkern/x86/crc32_sse42.c
So it's added in twice.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
On 6/16/19 9:33 AM, Warner Losh wrote: > On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling wrote: > >> If I try to build world almost recent sources (r349100) on HEAD amd64 >> (r348775), it stops with the following error: >> >> >> [..snip..] >> (cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.libkern_crc32 >> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t >> PROG=libkern_crc32 ) >> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a >> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >> >> .depend.libkern_crc32 >> cc -target x86_64-unknown-freebsd13.0 >> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp >> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe >> -DUSERSPACE_TESTING -MD -MF.depend.libkern_crc32.libkern_crc32.o >> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers >> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith >> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body >> -Wno-string-plus-int -Wno-unused-const-variable >> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality >> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef >> -Wno-address-of-packed-member -Qunused-arguments -c >> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o >> cc -target x86_64-unknown-freebsd13.0 >> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp >> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING >> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall >> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized >> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion >> -Wno-unused-local-typedef -Wno-address-of-packed-member >> -Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32 >> libkern_crc32.o /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c >> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c >> ld: error: duplicate symbol: sse42_crc32c > defined at crc32_sse42.c >/tmp/crc32_sse42-2988bd.o:(sse42_crc32c) > defined at crc32_sse42.c >/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0) >> cc: error: linker command failed with exit code 1 (use -v to see >> invocation) >> *** [libkern_crc32] Error code 1 >> make[6]: stopped in /usr/src/tests/sys/kern >> 1 error >> make[6]: stopped in /usr/src/tests/sys/kern >> *** [libkern_crc32] Error code 2 >> >> >> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom >> II X6 1090T). >> >> Am I the only one, who observes this breakage? Thanks for any hint. >> > > Try adding -DWITHOUT_TESTS to buildworld... > > Warner > ~/git/freebsd2/tests/sys/kern # env|grep TEST MK_TESTS=no Doh. Turns out I've had TESTS disabled in some of my recent build tests / commits. This is likely my fault. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)
On 6/16/19 8:49 AM, Rainer Hurling wrote: > If I try to build world almost recent sources (r349100) on HEAD amd64 > (r348775), it stops with the following error: > > > [..snip..] > (cd /usr/src/tests/sys/kern && DEPENDFILE=.depend.libkern_crc32 > NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t > PROG=libkern_crc32 ) > echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >> > .depend.libkern_crc32 > cc -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > -DUSERSPACE_TESTING -MD -MF.depend.libkern_crc32.libkern_crc32.o > -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers > -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-address-of-packed-member -Qunused-arguments -c > /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o > cc -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Wno-address-of-packed-member > -Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32 > libkern_crc32.o /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c > /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c Hmm /usr/src/sys/libkern/x86/crc32_sse42.c is listed twice unless I'm reading it wrong. It's from an LDADD. I'm looking into it a bit more... > ld: error: duplicate symbol: sse42_crc32c defined at crc32_sse42.c /tmp/crc32_sse42-2988bd.o:(sse42_crc32c) defined at crc32_sse42.c /tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0) > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [libkern_crc32] Error code 1 > make[6]: stopped in /usr/src/tests/sys/kern > 1 error > make[6]: stopped in /usr/src/tests/sys/kern > *** [libkern_crc32] Error code 2 > > > This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom > II X6 1090T). > > Am I the only one, who observes this breakage? Thanks for any hint. > > Regards, > Rainer Hurling > ___ > 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" > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: error: yacc.h: No such file or directory
On June 19, 2019 9:53:12 AM PDT, Ian Lepore wrote: >On Wed, 2019-06-19 at 09:30 -0700, Rodney W. Grimes wrote: >> > In message < >> > fffbe5d47e3515c960429ab416bf2ba234f9671d.ca...@freebsd.org> >> > , Ian Le >> > pore writes: >> > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: >> > > > > On Jun 18, 2019, at 06:59, Enji Cooper > > > > > > >> > > > > wrote: >> > > > > >> > > > > >> > > > > > On Jun 18, 2019, at 06:53, Ian Lepore >> > > > > > wrote: >> > > > > >> > > > > ... >> > > > > >> > > > > > Last Saturday, Bryan (cc'd) made a series of commits >> > > > > > (r349061-69) >> > > > > > that >> > > > > > were all somehow related to dependency processing in the >> > > > > > build. I >> > > > > > don't know the details, just remember seeing some commits >> > > > > > about >> > > > > > that. >> > > > > >> > > > > I remember that as well. This might have changed the >> > > > > dependency >> > > > > order subtly, introducing a race. >> > > > > >> > > > > The headers might not be built in all cases in time now. >> > > > > >> > > > > Thanks, >> > > > > -Enji >> > > > > >> > > > > PS This is one of the reasons why I wasn???t quick to >> > > > > discount Peter >> > > > > Jeremy???s reported build issue. >> > > > >> > > > Correction: I meant Julian Stacey. >> > > >> > > Julian Stacey has 3 problems: >> > > >> > > 1. Missing opt_cam.h >> > > 2. Missing yacc.h >> > > 3. A years-long inability to report a problem without hurling >> > > personal >> > > insults at the project and everyone associated with it. >> > > >> > > Because of #3, I don't much care about 1 and 2. >> > >> > Bingo! My point exactly! >> >> You can't understand the frustration of 25 years of >> having system build breakage on a pretty regular basis >> as a trigger point for anger? >> > >I understand how inappropriate it is for a project member to condone or >excuse the verbal abuse of other project members. > >Somone with anger management problems likely shouldn't be running >current, where a certain amount of short-term breakage is normal and >expected. > >-- Ian I do not think what you said was abusive. As a matter of fact you said what I had said in a previous email, just more directly than I chose to say it. Having to deal with a difficult person or two in real life personally, sometimes the only answer is "do it yourself." A little respect goes a long way. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: error: yacc.h: No such file or directory
On June 19, 2019 9:30:19 AM PDT, "Rodney W. Grimes" wrote: >> In message > >> , Ian Le >> pore writes: >> > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: >> > > > On Jun 18, 2019, at 06:59, Enji Cooper >> > > > wrote: >> > > > >> > > > >> > > > > On Jun 18, 2019, at 06:53, Ian Lepore >wrote: >> > > > >> > > > ... >> > > > >> > > > > Last Saturday, Bryan (cc'd) made a series of commits >(r349061-69) >> > > > > that >> > > > > were all somehow related to dependency processing in the >> > > > > build. I >> > > > > don't know the details, just remember seeing some commits >about >> > > > > that. >> > > > >> > > > I remember that as well. This might have changed the dependency >> > > > order subtly, introducing a race. >> > > > >> > > > The headers might not be built in all cases in time now. >> > > > >> > > > Thanks, >> > > > -Enji >> > > > >> > > > PS This is one of the reasons why I wasn???t quick to discount >Peter >> > > > Jeremy???s reported build issue. >> > > >> > > Correction: I meant Julian Stacey. >> > >> > Julian Stacey has 3 problems: >> > >> > 1. Missing opt_cam.h >> > 2. Missing yacc.h >> > 3. A years-long inability to report a problem without hurling >personal >> > insults at the project and everyone associated with it. >> > >> > Because of #3, I don't much care about 1 and 2. >> >> Bingo! My point exactly! > >You can't understand the frustration of 25 years of >having system build breakage on a pretty regular basis >as a trigger point for anger? But it doesn't break on a regular basis. Sure, people occasionally do boneheaded things but that doesn't give anyone the right to go on the attack. Calling for the revocation of commit bits is going over the line. We all get frustrated but frustration doesn't give anyone the right to go postal in a virtual way. The fact is a person can attract more good will by objectively addressing the problem rather than subjectively attacking the person, or in this case attacking the group of people. It's like being bitten by a dog. You want nothing to do with the animal. I see Ian's point and feel the same, and wouldn't be surprised if others did too. I can think of many other real life examples which result in, "well then do it yourself." People can't consistently treat others in a certain manner and expect different results time and time again. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: error: yacc.h: No such file or directory
On Wed, 2019-06-19 at 09:30 -0700, Rodney W. Grimes wrote: > > In message < > > fffbe5d47e3515c960429ab416bf2ba234f9671d.ca...@freebsd.org> > > , Ian Le > > pore writes: > > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: > > > > > On Jun 18, 2019, at 06:59, Enji Cooper > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > On Jun 18, 2019, at 06:53, Ian Lepore > > > > > > wrote: > > > > > > > > > > ... > > > > > > > > > > > Last Saturday, Bryan (cc'd) made a series of commits > > > > > > (r349061-69) > > > > > > that > > > > > > were all somehow related to dependency processing in the > > > > > > build. I > > > > > > don't know the details, just remember seeing some commits > > > > > > about > > > > > > that. > > > > > > > > > > I remember that as well. This might have changed the > > > > > dependency > > > > > order subtly, introducing a race. > > > > > > > > > > The headers might not be built in all cases in time now. > > > > > > > > > > Thanks, > > > > > -Enji > > > > > > > > > > PS This is one of the reasons why I wasn???t quick to > > > > > discount Peter > > > > > Jeremy???s reported build issue. > > > > > > > > Correction: I meant Julian Stacey. > > > > > > Julian Stacey has 3 problems: > > > > > > 1. Missing opt_cam.h > > > 2. Missing yacc.h > > > 3. A years-long inability to report a problem without hurling > > > personal > > > insults at the project and everyone associated with it. > > > > > > Because of #3, I don't much care about 1 and 2. > > > > Bingo! My point exactly! > > You can't understand the frustration of 25 years of > having system build breakage on a pretty regular basis > as a trigger point for anger? > I understand how inappropriate it is for a project member to condone or excuse the verbal abuse of other project members. Somone with anger management problems likely shouldn't be running current, where a certain amount of short-term breakage is normal and expected. -- Ian ___ 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: error: yacc.h: No such file or directory
On Wed, Jun 19, 2019 at 9:31 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > In message > > , Ian Le > > pore writes: > > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: > > > > > On Jun 18, 2019, at 06:59, Enji Cooper > > > > > wrote: > > > > > > > > > > > > > > > > On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > > > > > > > > > ... > > > > > > > > > > > Last Saturday, Bryan (cc'd) made a series of commits > (r349061-69) > > > > > > that > > > > > > were all somehow related to dependency processing in the > > > > > > build. I > > > > > > don't know the details, just remember seeing some commits about > > > > > > that. > > > > > > > > > > I remember that as well. This might have changed the dependency > > > > > order subtly, introducing a race. > > > > > > > > > > The headers might not be built in all cases in time now. > > > > > > > > > > Thanks, > > > > > -Enji > > > > > > > > > > PS This is one of the reasons why I wasn???t quick to discount > Peter > > > > > Jeremy???s reported build issue. > > > > > > > > Correction: I meant Julian Stacey. > > > > > > Julian Stacey has 3 problems: > > > > > > 1. Missing opt_cam.h > > > 2. Missing yacc.h > > > 3. A years-long inability to report a problem without hurling personal > > > insults at the project and everyone associated with it. > > > > > > Because of #3, I don't much care about 1 and 2. > > > > Bingo! My point exactly! > > You can't understand the frustration of 25 years of > having system build breakage on a pretty regular basis > as a trigger point for anger? > If there really were 25 years of constant build breakages, then maybe. But this overstates the number of times it happens. In the past 10 years the number of tree breakages is 10x or more fewer than in the early days of the project when it was all the time. In the interim, we've grown a bunch of new ways to build, and the combinatorics make it impossible to exhaustively test. No matter what we do, things will break, despite people's best efforts. Getting table flipping mad is an over-reaction and frankly not actionable. If you look at the breakage lately, in general it's been in weird edge cases that not too many people do on a regular basis. Missing opt_cam.h was only for the not-with-the-kernel build path. It's supposed to work, but it breaks more often than other paths because it's significantly less used. This specific issue was actually fixed before Julian complained as well, so we caught it fairly quickly (I fixed it 5 days after it went in). We should take this as a signal that this feature isn't used much used, not as an opportunity to vent one's spleen. It's not even in the CI path today. Had it been, we'd have caught it faster. We hit this from time to time, so having it be in CI likely makes some sense. The yacc.h was an unforeseen side effect of improvements in other dependency parsing that sped up the build. And it was only for the non -j X / -B case. Since clang takes forever to build, nobody builds w/o -j #, so it went unnoticed for a few days. Since it takes a fairly beefy machine to build FreeBSD, this is an understandable oops. This one I'm not sure we should put into CI very often since it's a tricky bug to catch and it's quite rare that we have ordering issues that get tripped up by -j vs no -j. There's only so many CI resources, and given the problems in the area, I think it's a poor ROI. Warner ___ 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: error: yacc.h: No such file or directory
> In message > , Ian Le > pore writes: > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote: > > > > On Jun 18, 2019, at 06:59, Enji Cooper > > > > wrote: > > > > > > > > > > > > > On Jun 18, 2019, at 06:53, Ian Lepore wrote: > > > > > > > > ... > > > > > > > > > Last Saturday, Bryan (cc'd) made a series of commits (r349061-69) > > > > > that > > > > > were all somehow related to dependency processing in the > > > > > build. I > > > > > don't know the details, just remember seeing some commits about > > > > > that. > > > > > > > > I remember that as well. This might have changed the dependency > > > > order subtly, introducing a race. > > > > > > > > The headers might not be built in all cases in time now. > > > > > > > > Thanks, > > > > -Enji > > > > > > > > PS This is one of the reasons why I wasn???t quick to discount Peter > > > > Jeremy???s reported build issue. > > > > > > Correction: I meant Julian Stacey. > > > > Julian Stacey has 3 problems: > > > > 1. Missing opt_cam.h > > 2. Missing yacc.h > > 3. A years-long inability to report a problem without hurling personal > > insults at the project and everyone associated with it. > > > > Because of #3, I don't much care about 1 and 2. > > Bingo! My point exactly! You can't understand the frustration of 25 years of having system build breakage on a pretty regular basis as a trigger point for anger? -- Rod Grimes rgri...@freebsd.org ___ 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"
