Re: Kernel build error rev.328485
On Saturday, January 27, 2018 06:54:03 PM Per Gunnarsson wrote: > I am back with new build errors. If I post too frequently, please inform me. These all look like you have stale sources in your tree somehow (e.g. sys/compat/freebsd/freebsd32_misc.c doesn't seem to match sys/compat/freebsd/freebsd32.h) -- 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: Kernel build error
[ Charset UTF-8 unsupported, converting... ] > Hello! > > I am trying to build the kernel with revision 328463. > > It halts with this error: > > /usr/src/sys/cam/scsi/scsi_da.c:1514:9: error: 'CAM_PERIPH_PRINT' macro > redefined [-Werror,-Wmacro-redefined] > #define CAM_PERIPH_PRINT(p, msg, args...) > ??? ^ > /usr/src/sys/cam/cam_periph.h:263:9: note: previous definition is here > #define CAM_PERIPH_PRINT(p, msg, args...)?? \ > ??? ^ > 1 error generated. > *** Error code 1 > > Stop. > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > Regards, > > Per Gunnarsson Fixed in https://svnweb.freebsd.org/changeset/base/328464 -- 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: Kernel build error in hwpmc with system GNU cc
On Thu, May 02, 2013 at 04:12:36PM +0200, Davide Italiano wrote: > On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov wrote: > > On 02.05.2013 14:06, Davide Italiano wrote: > >>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: > >>> 'map' may be used uninitialized in this function > >>> *** [hwpmc_core.o] Error code 1 > > > >> You can find a patch attached at the end of this mail that should fix > >> the problem. > > > > Thanks, it fix this warning. > > > >> More generally speaking, why are you building -CURRENT using GCC while > >> the default compiler has been clang since November 2012? > > > > 1) clang is not ready for production, it is too buggy. See its fixes > > rate for very common things 'must work' in every compiler. It is > > included into -current not because of its quality, but to involve > > developers into clang bugfixes to make its progress faster, and > > personally me don't want to find clang bugs. > > > > 2) Its build time is too long. > > > > 3) It generates bigger code. > > > >> Putting the additional burden of > >> testing on the committer because two compilers are supported at the > >> same time doesn't scale really well, at least according to me. > > > > You'll hit this error later in any case, attempting to MFC your changes > > to -stable with GNU cc. > > > > -- > > bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N > > > I won't object about your 2) and 3), but if you fear to hit bugs you > shouldn't probably run -CURRENT. > About the backport, I faced the problem of adapting code in the past > when merging to stable releases, so this is actually a different > problem. If I'd blindly merged the incrimined change to 9-STABLE > without building and notifying the GCC warning, then I would expect > you ranting at me because of build failure. > There's a notion of "default compiler" in 9 and in 10 and they're > different. My opinion is that people should live with it, and unless > someone will introduce some mechanism a-la redports.org to overcome > the issue, I will take my risks committing changes and fixing failures > if they occur. It's already really difficult to have tinderbox not > ranting these days, adding another compiler just result in another > dimension of complexity in the whole scenario. I experienced the same issues e.g. with the TTM commit, on somewhat bigger scale. There were 3 or 4 problems compiling the code with gcc, which were silently accepted by clang. Most ridiculous was clang silence on the double-declaration of the functions. For myself, I decided after the episode that I am morally unblended if default build is fine after the commit. For any compile issues reported by users with non-default compilers, I obviously take a look and do fix if possible, but I certainly do not intend to even try to test with non-default compiler on my own. pgpgM0TT1cB8I.pgp Description: PGP signature
Re: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov wrote: > On 02.05.2013 14:06, Davide Italiano wrote: >>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: >>> 'map' may be used uninitialized in this function >>> *** [hwpmc_core.o] Error code 1 > >> You can find a patch attached at the end of this mail that should fix >> the problem. > > Thanks, it fix this warning. > >> More generally speaking, why are you building -CURRENT using GCC while >> the default compiler has been clang since November 2012? > > 1) clang is not ready for production, it is too buggy. See its fixes > rate for very common things 'must work' in every compiler. It is > included into -current not because of its quality, but to involve > developers into clang bugfixes to make its progress faster, and > personally me don't want to find clang bugs. > > 2) Its build time is too long. > > 3) It generates bigger code. > >> Putting the additional burden of >> testing on the committer because two compilers are supported at the >> same time doesn't scale really well, at least according to me. > > You'll hit this error later in any case, attempting to MFC your changes > to -stable with GNU cc. > > -- > bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N I won't object about your 2) and 3), but if you fear to hit bugs you shouldn't probably run -CURRENT. About the backport, I faced the problem of adapting code in the past when merging to stable releases, so this is actually a different problem. If I'd blindly merged the incrimined change to 9-STABLE without building and notifying the GCC warning, then I would expect you ranting at me because of build failure. There's a notion of "default compiler" in 9 and in 10 and they're different. My opinion is that people should live with it, and unless someone will introduce some mechanism a-la redports.org to overcome the issue, I will take my risks committing changes and fixing failures if they occur. It's already really difficult to have tinderbox not ranting these days, adding another compiler just result in another dimension of complexity in the whole scenario. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build error in hwpmc with system GNU cc
On 02.05.2013 14:06, Davide Italiano wrote: >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' >> may be used uninitialized in this function >> *** [hwpmc_core.o] Error code 1 > You can find a patch attached at the end of this mail that should fix > the problem. Thanks, it fix this warning. > More generally speaking, why are you building -CURRENT using GCC while > the default compiler has been clang since November 2012? 1) clang is not ready for production, it is too buggy. See its fixes rate for very common things 'must work' in every compiler. It is included into -current not because of its quality, but to involve developers into clang bugfixes to make its progress faster, and personally me don't want to find clang bugs. 2) Its build time is too long. 3) It generates bigger code. > Putting the additional burden of > testing on the committer because two compilers are supported at the > same time doesn't scale really well, at least according to me. You'll hit this error later in any case, attempting to MFC your changes to -stable with GNU cc. -- bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 3:10 PM, Dimitry Andric wrote: > On 2013-05-02 12:06, Davide Italiano wrote: >> >> On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov wrote: >>> >>> cc1: warnings being treated as errors >>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function >>> 'iap_allocate_pmc': >>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: >>> 'map' may be used uninitialized in this function > > ... > >> You can find a patch attached at the end of this mail that should fix >> the problem. > > > Hm, the warning seems to be bogus. Newer versions of gcc (I tried 4.7.3 > and 4.8.1) do not warn about 'map' (though they both warn about another > variable, which is set, but not used.) > > > >> More generally speaking, why are you building -CURRENT using GCC while >> the default compiler has been clang since November 2012? >> I understand we cannot completely get rid of GCC as long as >> Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I >> see clang default on amd64 so I guess at some point we should declare >> GCC not officially supported anymore. Putting the additional burden of >> testing on the committer because two compilers are supported at the >> same time doesn't scale really well, at least according to me. > > > Some people still prefer gcc, and while this warning is a bit annoying, > I see no problem in putting in a workaround. Using gcc for arches which Yes, for sure it's not a problem. I try to run 'make universe' when I commit change, but it's already slow on relatively recent hardware, and I just found annoying the need of rebuilding the system using two different compilers (in particular if one of them generates warning that are bogus, as happened in this case). Other than being time-expensive, the switch at runtime from clang to GCC was not so easy for me. In fact, if I try to change from clang to gcc46 and run 'make buildkernel' I get some errors like: cc1: error: unrecognized command line option '-fformat-extensions' cc1: warning: unrecognized command line option "-Wno-error-parentheses-equality" [enabled by default] cc1: warning: unrecognized command line option "-Wno-error-empty-body" [enabled by default] cc1: warning: unrecognized command line option "-Wno-error-tautological-compare" [enabled by default] *** [genassym.o] Error code 1 which disappear actually if I re-run buildworld. Maybe I'm missing something or I'm doing something wrong. But, at the end of the day, I preferred to have my lazyness winning. Actually, I don't think it worth the effort. If there's an easier way to do this, feel free to point me to it. > default to clang will most likely have to be supported for quite some > time. > > Also, if the external toolchain support ever comes off the ground, it > will probably become necessary to suppress certain warnings on an > individual basis; for example, with recent gcc versions, there are quite > a large number of "variable x set but not used" warnings, which are not > very useful, most of the time. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build error in hwpmc with system GNU cc
On 2013-05-02 12:06, Davide Italiano wrote: On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov wrote: cc1: warnings being treated as errors /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function 'iap_allocate_pmc': /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' may be used uninitialized in this function ... You can find a patch attached at the end of this mail that should fix the problem. Hm, the warning seems to be bogus. Newer versions of gcc (I tried 4.7.3 and 4.8.1) do not warn about 'map' (though they both warn about another variable, which is set, but not used.) More generally speaking, why are you building -CURRENT using GCC while the default compiler has been clang since November 2012? I understand we cannot completely get rid of GCC as long as Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I see clang default on amd64 so I guess at some point we should declare GCC not officially supported anymore. Putting the additional burden of testing on the committer because two compilers are supported at the same time doesn't scale really well, at least according to me. Some people still prefer gcc, and while this warning is a bit annoying, I see no problem in putting in a workaround. Using gcc for arches which default to clang will most likely have to be supported for quite some time. Also, if the external toolchain support ever comes off the ground, it will probably become necessary to suppress certain warnings on an individual basis; for example, with recent gcc versions, there are quite a large number of "variable x set but not used" warnings, which are not very useful, most of the time. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build error in hwpmc with system GNU cc
On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov wrote: > cc1: warnings being treated as errors > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c: In function > 'iap_allocate_pmc': > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' > may be used uninitialized in this function > *** [hwpmc_core.o] Error code 1 > > -- > bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N You can find a patch attached at the end of this mail that should fix the problem. More generally speaking, why are you building -CURRENT using GCC while the default compiler has been clang since November 2012? I understand we cannot completely get rid of GCC as long as Tier-2/Tier-3 arch haven't full support for clang and friends, OTOH, I see clang default on amd64 so I guess at some point we should declare GCC not officially supported anymore. Putting the additional burden of testing on the committer because two compilers are supported at the same time doesn't scale really well, at least according to me. Index: sys/dev/hwpmc/hwpmc_core.c === --- sys/dev/hwpmc/hwpmc_core.c (revision 250174) +++ sys/dev/hwpmc/hwpmc_core.c (working copy) @@ -1945,7 +1945,7 @@ caps = a->pm_caps; if ((IAP_PMC_CAPS & caps) != caps) return (EPERM); - + map = 0;/* XXX: silent GCC warning */ arch = iap_is_event_architectural(pm->pm_event, &map); if (arch == EV_IS_ARCH_NOTSUPP) return (EOPNOTSUPP); -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel build error
Beech Rintoul <[EMAIL PROTECTED]> writes: > Today's -current build fails on my box with the following: I think it's safe to say, as a general rule, that whenever you hit a build error (as opposed to a run-time bug) you should wait a couple of hours, re-cvsup, rebuild, and check that the problem is still there before you ask the lists about it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: kernel build error
On 26-Oct-01 Beech Rintoul wrote: > Today's -current build fails on my box with the following: > > linking kernel > vm_fault.o: In function `vm_fault1': > vm_fault.o(.text+0x941): undefined reference to > `vm_object_set_writeable_dirty' > vm_page.o In function `vm_page_insert': > vm_page.o(.text+0x4c2): undefined reference to > `vm_object_set_writeable_dirty' > *** Error code 1 > Stop in /usr/obj/usr/src/sys/GALAXY. > *** Error code 1 It's already fixed. re-cvsup. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build error due to dependency on /usr/include?
On Sat, 27 May 2000, Jake Burkholder wrote: > > I got following kernel build error. > > When I run 'make includes', the error has gone away. `make includes' tends to cause errors like this. It updates /usr/include to match the sources. This may make /usr/include inconsistent with /usr/lib. > > Why does kernel build process depend on installed system files, > > such as /usr/include? > > It shouldn't. Most parts of it shouldn't, but utilities should be compiled with the installed headers that match the installed libraries. > This seems to be primarily aic7xxx, although judging from the output aicasm seems to be buill correctly, but it would be better for its Makefile to not add -I/usr/include to CFLAGS, so that the default is used. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build error due to dependency on /usr/include?
> Hi all, > > I got following kernel build error. > When I run 'make includes', the error has gone away. > > Why does kernel build process depend on installed system files, > such as /usr/include? It shouldn't. This seems to be primarily aic7xxx, although judging from the output of 'find /usr/include -amin 20 -print' after building LINT, there are more things that reach into /usr/include. This fixes it for including things from /usr/include/sys at least: cvs diff: Diffing . Index: Makefile === RCS file: /home/ncvs/src/sys/dev/aic7xxx/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- Makefile1999/08/28 00:41:22 1.6 +++ Makefile2000/05/27 09:21:05 @@ -19,7 +19,7 @@ DEPENDFILE= .endif -CFLAGS+= -I/usr/include -I. +CFLAGS+= -I${MAKESRCPATH}/../.. -I. NOMAN= noman .ifdef DEBUG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message