Hi,
Looks like one of the commits by Bryan (r326549-r326553) has broken the
kernel build for me (using -j32, but serial build did fail as well) --
checking out r326547 make it work again.
I can't pinpoint the exact error in the build log, as it seems to be
some make weirdness, so here's a gu
On 12/5/2017 9:03 AM, Yuri Pankov wrote:
> Hi,
>
> Looks like one of the commits by Bryan (r326549-r326553) has broken the
> kernel build for me (using -j32, but serial build did fail as well) --
> checking out r326547 make it work again.
>
> I can't pinpoint the exact error in the build log, as
On 12/5/2017 9:10 AM, Bryan Drewery wrote:
> On 12/5/2017 9:03 AM, Yuri Pankov wrote:
>> Hi,
>>
>> Looks like one of the commits by Bryan (r326549-r326553) has broken the
>> kernel build for me (using -j32, but serial build did fail as well) --
>> checking out r326547 make it work again.
>>
>> I ca
On Tue, Dec 5, 2017 at 09:24:28AM -0800, Bryan Drewery wrote:
On 12/5/2017 9:10 AM, Bryan Drewery wrote:
On 12/5/2017 9:03 AM, Yuri Pankov wrote:
Hi,
Looks like one of the commits by Bryan (r326549-r326553) has broken the
kernel build for me (using -j32, but serial build did fail as well) --
I'm looking for where the u_int, u_long headers are defined?
for instance MOD_LOAD, UNLOAD, ENOTSUP along with u_int and u_long aren't
being picked up by libclang
module_t isn't being found either but I located that header file in
/usr/include/sys/module.h
snd_modevent(module_t mod, int type, vo
Hello:
I am trying to update a system from:
FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64
to:
huff@> svn info
Path: .
Working Copy Root Path: /usr/src
URL: http://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: http://svn.freebsd.org/base
Repos
On Wed, Dec 06, 2017 at 02:18:29AM +0800, blubee blubeeme wrote:
> I'm looking for where the u_int, u_long headers are defined?
Although it seems to be out-of-date, for something fundamental like this
you should be able to use the FXR instance:
http://fxr.watson.org/fxr/search
mcl
So I don't fully understand why this build failure happened, but I did
manage to find root cause. It turns out that there was a bug in make
that caused our build infrastructure to write objects and other build
output to the srcdir rather than the objdir in certain cases when
using make -C. I have
On Tue, Dec 5, 2017 at 2:03 PM, Ryan Stone wrote:
> So I don't fully understand why this build failure happened, but I did
> manage to find root cause. It turns out that there was a bug in make
> that caused our build infrastructure to write objects and other build
> output to the srcdir rather