Re: Kernel build error rev.328485

2018-01-29 Thread John Baldwin
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

2018-01-27 Thread Rodney W. Grimes
[ 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"


Kernel build error rev.328485

2018-01-27 Thread Per Gunnarsson
I am back with new build errors. If I post too frequently, please inform me.

/usr/src/sys/compat/freebsd32/freebsd32_misc.c:122:1: error:
static_assert failed "compile-time assertion failed"
CTASSERT(sizeof(struct kevent32) == 20);
^    ~
/usr/src/sys/sys/systm.h:107:21: note: expanded from macro 'CTASSERT'
#define CTASSERT(x) _Static_assert(x, "compile-time assertion failed")
    ^  ~
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:126:1: error:
static_assert failed "compile-time assertion failed"
CTASSERT(sizeof(struct stat32) == 96);
^    ~~~
/usr/src/sys/sys/systm.h:107:21: note: expanded from macro 'CTASSERT'
#define CTASSERT(x) _Static_assert(x, "compile-time assertion failed")
    ^  ~
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:612:24: error: no member
named 'data' in 'struct kevent32'
    CP(kevp[i], ks32[i], data);
    ~^
/usr/src/sys/compat/freebsd32/freebsd32.h:41:36: note: expanded from
macro 'CP'
#define CP(src,dst,fld) do { (dst).fld = (src).fld; } while (0)
 ~ ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:644:24: error: no member
named 'data' in 'struct kevent32'
    CP(ks32[i], kevp[i], data);
    ~^
/usr/src/sys/compat/freebsd32/freebsd32.h:41:48: note: expanded from
macro 'CP'
#define CP(src,dst,fld) do { (dst).fld = (src).fld; } while (0)
 ~ ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1738:42: error:
declaration of 'struct freebsd32_stat_args' will not be visible outside
of this function [-Werror,-Wvisibility]
freebsd32_stat(struct thread *td, struct freebsd32_stat_args *uap)
 ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1744:42: error:
incomplete definition of type 'struct freebsd32_stat_args'
    error = kern_statat(td, 0, AT_FDCWD, uap->path, UIO_USERSPACE,
 ~~~^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1738:42: note: forward
declaration of 'struct freebsd32_stat_args'
freebsd32_stat(struct thread *td, struct freebsd32_stat_args *uap)
 ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1749:28: error:
incomplete definition of type 'struct freebsd32_stat_args'
    error = copyout(, uap->ub, sizeof (sb32));
   ~~~^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1738:42: note: forward
declaration of 'struct freebsd32_stat_args'
freebsd32_stat(struct thread *td, struct freebsd32_stat_args *uap)
 ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1738:1: error: no
previous prototype for function 'freebsd32_stat'
[-Werror,-Wmissing-prototypes]
freebsd32_stat(struct thread *td, struct freebsd32_stat_args *uap)
^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1820:43: error:
declaration of 'struct freebsd32_lstat_args' will not be visible outside
of this function [-Werror,-Wvisibility]
freebsd32_lstat(struct thread *td, struct freebsd32_lstat_args *uap)
  ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1826:60: error:
incomplete definition of type 'struct freebsd32_lstat_args'
    error = kern_statat(td, AT_SYMLINK_NOFOLLOW, AT_FDCWD, uap->path,
   ~~~^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1820:43: note: forward
declaration of 'struct freebsd32_lstat_args'
freebsd32_lstat(struct thread *td, struct freebsd32_lstat_args *uap)
  ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1831:28: error:
incomplete definition of type 'struct freebsd32_lstat_args'
    error = copyout(, uap->ub, sizeof (sb32));
   ~~~^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1820:43: note: forward
declaration of 'struct freebsd32_lstat_args'
freebsd32_lstat(struct thread *td, struct freebsd32_lstat_args *uap)
  ^
/usr/src/sys/compat/freebsd32/freebsd32_misc.c:1820:1: error: no
previous prototype for function 'freebsd32_lstat'
[-Werror,-Wmissing-prototypes]
freebsd32_lstat(struct thread *td, struct freebsd32_lstat_args *uap)
^
12 errors 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

___
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"


Kernel build error

2018-01-27 Thread Per Gunnarsson
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

___
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"


Kernel build error in hwpmc with system GNU cc

2013-05-02 Thread Andrey Chernov
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
___
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

2013-05-02 Thread Davide Italiano
On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov a...@freebsd.org 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 in hwpmc with system GNU cc

2013-05-02 Thread Dimitry Andric

On 2013-05-02 12:06, Davide Italiano wrote:

On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov a...@freebsd.org 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

2013-05-02 Thread Davide Italiano
On Thu, May 2, 2013 at 3:10 PM, Dimitry Andric d...@freebsd.org wrote:
 On 2013-05-02 12:06, Davide Italiano wrote:

 On Thu, May 2, 2013 at 8:43 AM, Andrey Chernov a...@freebsd.org 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

2013-05-02 Thread Andrey Chernov
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

2013-05-02 Thread Davide Italiano
On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov a...@freebsd.org 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

2013-05-02 Thread Konstantin Belousov
On Thu, May 02, 2013 at 04:12:36PM +0200, Davide Italiano wrote:
 On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov a...@freebsd.org 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


kernel build error

2001-10-26 Thread Beech Rintoul

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

Beech



-- 
Micro$oft: Where can we make you go today?
---
 Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED]
/\   ASCII Ribbon Campaign  | Anchorage Gospel Rescue Mission
\ / - NO HTML/RTF in e-mail  | P.O. Box 230510
 X  - NO Word docs in e-mail | Anchorage, AK 99523-0510
/ \ -












To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



RE: kernel build error

2001-10-26 Thread John Baldwin


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

2001-10-26 Thread Dag-Erling Smorgrav

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



kernel build error (Was: cvs commit: src/sys/kern kern_idle.c)

2000-10-18 Thread Munehiro Matsuda

After the following commit, my kernel fail to build with following errors:

cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi 
-g -nostdinc -I- -I. -I../.. -I../../../include 
-I../../contrib/dev/acpica/Subsystem/Include  -D_KERNEL -include opt_global.h -elf  
-mpreferred-stack-boundary=2  ../../kern/kern_idle.c
../../kern/kern_idle.c: In function `idle_proc':
../../kern/kern_idle.c:106: `count' undeclared (first use in this function)
../../kern/kern_idle.c:106: (Each undeclared identifier is reported only once
../../kern/kern_idle.c:106: for each function it appears in.)
*** Error code 1


::  Modified files:
::sys/kern kern_idle.c 
::  Log:
::  - Wrap the sanity checks for staying in the idle loop for absurdly long
::amounts of time in #ifdef DIAGNOSTIC
::  - Call vm_page_zero_idle() during the idle loop.
::  
::  Revision  ChangesPath
::  1.7   +13 -7 src/sys/kern/kern_idle.c

  Thank you,
   Haro
=--
   _ _Munehiro (haro) Matsuda
 -|- /_\  |_|_|   Business Incubation Dept., Kubota Corp.
 /|\ |_|  |_|_|   1-3 Nihonbashi-Muromachi 3-Chome
  Chuo-ku Tokyo 103-8310, Japan
  Tel: +81-3-3245-3318  Fax: +81-3-3245-3315
  Email: [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Kernel build error

2000-09-11 Thread Blaz Zupan

...
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions
-ansi -g -nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include
opt_global.h -elf  -mpreferred-stack-boundary=2  ../../i4b/driver/i4b_ctl.c
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions
-ansi -g -nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include
opt_global.h -elf  -mpreferred-stack-boundary=2  ../../i4b/driver/i4b_isppp.c
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions
-ansi -g -nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include
opt_global.h -elf  -mpreferred-stack-boundary=2  ../../net/if_spppsubr.c
../../net/if_spppsubr.c: In function `sppp_output':
../../net/if_spppsubr.c:755: warning: label `nosupport' defined but not used
../../net/if_spppsubr.c: In function `sppp_chap_scr':
../../net/if_spppsubr.c:3326: warning: passing arg 1 of `read_random' from
incompatible pointer type
../../net/if_spppsubr.c:3326: warning: passing arg 2 of `read_random' makes
pointer from integer without a cast
../../net/if_spppsubr.c:3326: too few arguments to function `read_random'
*** Error code 1

Stop in /home/blaz/FreeBSD/src/sys/compile/GOLD.


Seems to be related to randomdev. I have "device sppp" in my kernel config
file for i4b. -current as of a couple of minutes ago.

Blaz Zupan,  Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia
E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325



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?

2000-05-27 Thread Jake Burkholder

 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



Re: kernel build error due to dependency on /usr/include?

2000-05-27 Thread Bruce Evans

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



kernel build error due to dependency on /usr/include?

2000-05-26 Thread Munehiro Matsuda

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?

 Thank you,
   Haro

---
jkpc15-haro[43]cd ../../compile/JKPC15 
jkpc15-haro[44]make depend 
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi 
-g -nostdinc -I- -I. -I../.. -I../../../include  -D_KERNEL -include opt_global.h -elf  
-mpreferred-stack-boundary=2 ../../i386/i386/genassym.c
genassym genassym.o assym.s
make -f ../../dev/aic7xxx/Makefile MAKESRCPATH=../../dev/aic7xxx
Warning: Object directory not changed from original /usr/src/sys/compile/JKPC15
lex -t  ../../dev/aic7xxx/aicasm_scan.l  aicasm_scan.c
cc -O -pipe -I/usr/include -I.   -c aicasm_scan.c
^^^
In file included from ../../dev/aic7xxx/aicasm_scan.l:40:
../../dev/aic7xxx/aicasm.h:44: syntax error before `path_entry'
../../dev/aic7xxx/aicasm.h:53: syntax error before `path_entry'
In file included from ../../dev/aic7xxx/aicasm_scan.l:41:
../../dev/aic7xxx/aicasm_symbol.h:61: syntax error before `symbol_node'
../../dev/aic7xxx/aicasm_symbol.h:109: syntax error before `symbol_node'
../../dev/aic7xxx/aicasm_symbol.h:126: syntax error before `scope'
../../dev/aic7xxx/aicasm_symbol.h:127: syntax error before `scope'
../../dev/aic7xxx/aicasm_symbol.h:128: syntax error before `scope'
../../dev/aic7xxx/aicasm_symbol.h:137: syntax error before `scope'
../../dev/aic7xxx/aicasm_symbol.h:138: syntax error before `scope'
../../dev/aic7xxx/aicasm_scan.l:203: syntax error before `include'
../../dev/aic7xxx/aicasm_scan.l:206: syntax error before `include'
../../dev/aic7xxx/aicasm_scan.l: In function `include_file':
../../dev/aic7xxx/aicasm_scan.l:223: structure has no member named `slh_first'
../../dev/aic7xxx/aicasm_scan.l:225: structure has no member named `sle_next'
../../dev/aic7xxx/aicasm_scan.l:256: structure has no member named `sle_next'
../../dev/aic7xxx/aicasm_scan.l:256: structure has no member named `slh_first'
../../dev/aic7xxx/aicasm_scan.l:256: structure has no member named `slh_first'
../../dev/aic7xxx/aicasm_scan.l: In function `yywrap':
../../dev/aic7xxx/aicasm_scan.l:273: structure has no member named `slh_first'
../../dev/aic7xxx/aicasm_scan.l:278: structure has no member named `slh_first'
../../dev/aic7xxx/aicasm_scan.l:278: structure has no member named `slh_first'
*** Error code 1

Stop in /usr/src/sys/compile/JKPC15.
*** Error code 1

Stop in /usr/src/sys/compile/JKPC15.
jkpc15-haro[45]

=--
   _ _Munehiro (haro) Matsuda
 -|- /_\  |_|_|   Office of Business Planning  Development, Kubota Corp.
 /|\ |_|  |_|_|   1-3 Nihonbashi-Muromachi 3-Chome
  Chuo-ku Tokyo 103, Japan
  Tel: +81-3-3245-3318  Fax: +81-3-3245-3315
  Email: [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message