Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

odd missing symbols like rumpns_lockdebug_* in an i386 build

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 ===> kernspace
dependall ===> rumpkern
dependall ===> rumpkern/h_client
dependall ===> rumpkern/h_server
       link  h_server/h_simpleserver
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_wantlock'
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_unlocked'
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_free'
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_barrier'
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_mem_check'
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_alloc'
/rest/build/woods/once/current-i386-i386-tools/bin/../lib/gcc/i486--netbsdelf/6.5.0/../../../../i486--netbsdelf/bin/ld: /build/woods/once/current-i386-ppro-destdir/usr/lib/ undefined reference to `rumpns_lockdebug_locked'
collect2: error: ld returned 1 exit status

*** Failed target:  h_simpleserver
*** Failed command: /build/woods/once/current-i386-i386-tools/bin/i486--netbsdelf-gcc --sysroot=/build/woods/once/current-i386-ppro-destdir -pie -shared-libgcc -Wl,--warn-shared-textrel -Wl,-z,relro -o h_simpleserver h_simpleserver.o -lrumpkern_sysproxy -lrump -lrumpuser -lrump -lpthread -L/build/woods/once/current-i386-i386-ppro-obj/more/work/woods/m-NetBSD-current/tests/rump/kernspace -lkernspace -latf-c
*** Error code 1

nbmake[3]: stopped in /more/work/woods/m-NetBSD-current/tests/rump/rumpkern/h_server

I've only hacked bout in install image building since the last
successful build, so nothing related to rump, or tests, should have

I then tried the same i386 build, with the exact same NFS-mounted source
tree, on my faster build machine (an amd64 NetBSD-8.99 system).

It worked.   A-OK.  Complete with iso-image.  No errors.  Rebuilding in
src/tests/rump/h_server works A-OK:

	$ pwd
	$ mynbmake clean
	$ mynbmake dependall
	    compile  h_server/h_simpleserver.o
	       link  h_server/h_simpleserver
	     create  h_server/h_simpleserver.debug

This seems to be because for some reason on the amd64->i386 build there
is no reference to any of these symbols in usr/lib/

	$ cddest
	$ pwd
	$ nm usr/lib/ | fgrep rumpns_lockdebug_

They are still there on the real i386 build:

	$ nm usr/lib/ | fgrep rumpns_lockdebug_
	         U rumpns_lockdebug_alloc
	         U rumpns_lockdebug_barrier
	         U rumpns_lockdebug_free
	         U rumpns_lockdebug_locked
	         U rumpns_lockdebug_mem_check
	         U rumpns_lockdebug_unlocked
	         U rumpns_lockdebug_wantlock

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_

So, now what?  Where else should I look to debug this mess?

I'm guessing they are formed either with merging operator (##) in a
macro somewhere, but where, and how do I find it without carefully
reading everything related?

					Greg A. Woods <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpR1WsxbIwbY.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index