In article ,
Greg A. Woods wrote:
>
>They are still there on the real i386 build:
>
> $ nm usr/lib/librump.so | fgrep rumpns_lockdebug_
>U rumpns_lockdebug_alloc
>U rumpns_lockdebug_barrier
>U rumpns_lockdebug_free
>U
On Thu, May 28, 2020 at 01:48:49PM -0700, Greg A. Woods wrote:
> So, I thought I'd try to find out where these symbols might have come
> from, but I came up completely empty with no matches:
>
> $ cd /usr/src
> $ find . -type f -print0 | xargs -0 fgrep rumpns_lockebug_
> $
>
>
> $ nm usr/lib/librump.so | fgrep rumpns_lockdebug_
>U rumpns_lockdebug_alloc
> [...]
> $ cd /usr/src
> $ find . -type f -print0 | xargs -0 fgrep rumpns_lockebug_
> $
> So, now what? Where else should I look to debug this mess?
Well, based on later
At Fri, 29 May 2020 04:35:43 +0700, Robert Elz wrote:
Subject: Re: odd missing symbols like rumpns_lockdebug_* in an i386 build
>
> Compare mk.conf (or some other place in your build setup) on the system
> that built OK, and the one that didn't - I'm guessing that the latter has
> L
Date:Thu, 28 May 2020 13:48:49 -0700
From:"Greg A. Woods"
Message-ID:
| So, now what? Where else should I look to debug this mess?
Compare mk.conf (or some other place in your build setup) on the system
that built OK, and the one that didn't - I'm guessing that
So, in my somewhat not very current source tree I've been building
amd64, i386, and evbarm on a regular basis for the past few months with
no problem.
The other day, on a real i386 NetBSD-9 machine, the build failed, just
like this:
$ cd /usr/src/tests/rump
$ mynbmake dependall
dependall ===>
