Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[Ed Maste]

> > > This could be a dependency issue; would you check if removing the
> > > following $OBJTOP subdirs addresses the issue:
> > >
> > > secure/lib/libcrypto
> > > secure/lib/libssl
> > > obj-lib32/secure/lib/libcrypto
> > > obj-lib32/secure/lib/libssl
> > >
> The build was successful; after the reboot, we see:
>
> g1-48(14.0-C)[1] uname -aUK
> FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #469 
> main-n263782-59833b089e78: Sat Jun 24 16:28:56 UTC 2023 
> r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
> 1400092 1400092
>
>
> So: I believe we have a winner! :-)

Excellent, thanks for checking. I've opened review D40750[1] to have
this cleanup happen automatically.

[1] https://reviews.freebsd.org/D40750

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[David Wolfskill]

On Sat, Jun 24, 2023 at 09:09:00AM -0700, David Wolfskill wrote:
> On Sat, Jun 24, 2023 at 10:39:57AM -0400, Ed Maste wrote:
> > ...
> > > : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> > > #  error "OPENSSL_API_COMPAT expresses an impossible API compatibility 
> > > level"
> > >^
> > 
> > This could be a dependency issue; would you check if removing the
> > following $OBJTOP subdirs addresses the issue:
> > 
> > secure/lib/libcrypto
> > secure/lib/libssl
> > obj-lib32/secure/lib/libcrypto
> > obj-lib32/secure/lib/libssl
> > 
> > If so I'll see if we can add a rule to tools/build/depend-cleanup.sh
> 
> After:
> ... 
> rm -fr /usr/obj/usr/src/amd64.amd64/{,obj-lib32/}secure/lib/lib{crypto,ssl}
> 
> then re-starting the "make buildworld", that process has completed the
> 
> >>> stage 4.2: building libraries
> 
> phase (and is now "building lib32 shim libraries").
> 

The build was successful; after the reboot, we see:

g1-48(14.0-C)[1] uname -aUK
FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #469 
main-n263782-59833b089e78: Sat Jun 24 16:28:56 UTC 2023 
r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 
1400092 1400092


So: I believe we have a winner! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[David Wolfskill]

On Sat, Jun 24, 2023 at 10:39:57AM -0400, Ed Maste wrote:
> ...
> > : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> > #  error "OPENSSL_API_COMPAT expresses an impossible API compatibility 
> > level"
> >^
> 
> This could be a dependency issue; would you check if removing the
> following $OBJTOP subdirs addresses the issue:
> 
> secure/lib/libcrypto
> secure/lib/libssl
> obj-lib32/secure/lib/libcrypto
> obj-lib32/secure/lib/libssl
> 
> If so I'll see if we can add a rule to tools/build/depend-cleanup.sh

After:

g1-48(14.0-C)[1] ls -lTd 
/usr/obj/usr/src/amd64.amd64/^G{,obj-lib32/}secure/lib/lib{crypto,ssl}
drwxrwxr-x  4 root  wheel   62464 Jun 23 06:08:19 2023 
/usr/obj/usr/src/amd64.amd64/obj-lib32/secure/lib/libcrypto
drwxrwxr-x  2 root  wheel5120 Jun 23 06:08:38 2023 
/usr/obj/usr/src/amd64.amd64/obj-lib32/secure/lib/libssl
drwxrwxr-x  5 root  wheel  132608 Jun 24 04:11:55 2023 
/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto
drwxrwxr-x  2 root  wheel5632 Jun 24 04:11:56 2023 
/usr/obj/usr/src/amd64.amd64/secure/lib/libssl
g1-48(14.0-C)[2] rm -fr !$
rm -fr /usr/obj/usr/src/amd64.amd64/{,obj-lib32/}secure/lib/lib{crypto,ssl}

then re-starting the "make buildworld", that process has completed the

>>> stage 4.2: building libraries

phase (and is now "building lib32 shim libraries").

So: definite progress.  (Build machine is busy with other stuff, so the
above was on a laptop; it will be a bit slow).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[Ed Maste]

On Sat, 24 Jun 2023 at 07:11, David Wolfskill  wrote:
>
> Running:
> FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405 
> main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
> amd64 1400091 1400091
>
> after updating sources to main-n263782-59833b089e78, then starting
> make -j 64 buildworld (in META mode)
>
> ...
> >>> stage 4.2: building libraries
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/cddl/lib/libzfs/os/freebsd/nfs.o
> In file included from 
> /usr/src/sys/contrib/openzfs/lib/libzfs/libzfs_crypto.c:28
> :
> In file included from 
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl
> /evp.h:14:
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/macros.h:155:4: 
> error
> : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> #  error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
>^

This could be a dependency issue; would you check if removing the
following $OBJTOP subdirs addresses the issue:

secure/lib/libcrypto
secure/lib/libssl
obj-lib32/secure/lib/libcrypto
obj-lib32/secure/lib/libssl

If so I'll see if we can add a rule to tools/build/depend-cleanup.sh

Build failure for radlib.o during main-n263767-764464af4968 -> main-n263782-59833b089e78 src update

[David Wolfskill]

Running:
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405 
main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1400091 1400091

after updating sources to main-n263782-59833b089e78, then starting
make -j 64 buildworld (in META mode)

...
>>> stage 4.2: building libraries
...
Building /common/S4/obj/usr/src/amd64.amd64/cddl/lib/libzfs/os/freebsd/nfs.o
In file included from /usr/src/sys/contrib/openzfs/lib/libzfs/libzfs_crypto.c:28
:
In file included from /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl
/evp.h:14:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/macros.h:155:4: error
: "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
#  error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
   ^
*** [radlib.o] Error code 1

make[4]: stopped in /usr/src/lib/libradius
.ERROR_TARGET='radlib.o'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/lib/libradius/radlib.o.meta'
.MAKE.LEVEL='4'


The cited meta file pretty much re-states the above, but I have
attached a copy anyway.

Subsequently, one of my laptops has reproduced the failure (though with
only -j 16).

As of this writing, I see no more rec ent commits to head.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file /common/S4/obj/usr/src/amd64.amd64/lib/libradius/radlib.o.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/common/S4/obj/usr/src/amd64.amd64/tmp 
-B/common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   -Wall 
-DOPENSSL_API_COMPAT=0x1010L -DWITH_SSL -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/lib/libradius/radlib.c -o radlib.o
CMD 
CWD /common/S4/obj/usr/src/amd64.amd64/lib/libradius
TARGET radlib.o
-- command output --
In file included from /usr/src/lib/libradius/radlib.c:38:
In file included from 
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/hmac.h:14:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/openssl/macros.h:139:4: 
error: "The requested API level higher than the configured API compatibility 
level"
#  error "The requested API level higher than the configured API compatibility 
level"
   ^
1 error generated.

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 20051
# Start 1687604049.922333
V 5
E 20054 /bin/sh
R 20054 /etc/libmap.conf
R 20054 /var/run/ld-elf.so.hints
R 20054 /lib/libedit.so.8
R 20054 /lib/libc.so.7
R 20054 /lib/libtinfow.so.9
R 20054 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 20054 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 20054 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 20054 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 20054 /usr/share/locale/en_US.UTF-8/LC_TIME
R 20054 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 20054 20056
E 20056 /usr/bin/cc
R 20056 /etc/libmap.conf
R 20056 /var/run/ld-elf.so.hints
R 20056 /lib/libz.so.6
R 20056 /usr/lib/libprivatezstd.so.5
R 20056 /usr/lib/libexecinfo.so.1
R 20056 /lib/libncursesw.so.9
R 20056 /lib/libtinfow.so.9
R 20056 /lib/libthr.so.3
R 20056 /lib/libc++.so.1
R 20056 /lib/libcxxrt.so.1
R 20056 /lib/libm.so.5
R 20056 /lib/libc.so.7
R 20056 /lib/libelf.so.2
R 20056 /lib/libgcc_s.so.1
R 20056 /usr/src/lib/libradius/radlib.c
R 20056 radlib-51f1ada4.o.tmp
W 20056 radlib-51f1ada4.o.tmp
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/cdefs.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/endian.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/endian.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_types.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/machine/_limits.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/x86/_limits.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_endian.h
R 20056 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/sys/_pthreadtypes.h
R 20056 

Re: Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

[Mark Johnston]

On Wed, May 24, 2023 at 01:39:26PM +0200, Dimitry Andric wrote:
> On 24 May 2023, at 13:25, David Wolfskill  wrote:
> > 
> > This is from an in-place source update from main-n263073-634a770a5e16 to
> > main-n263112-ad513b4dba3e:
> > 
> > ...
> > Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
> > Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
> > Building 
> > /common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-1x1-4096-mbr.vhdx
> > Building /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zfsd/zfsd.full
> > /usr/src/usr.sbin/bhyvectl/bhyvectl.c:2389:24: error: incompatible pointer 
> > types passing 'struct vm_exit *' to parameter of type 'struct vm_run *' 
> > [-Werror,-Wincompatible-pointer-types]
> >error = vm_run(vcpu, );
> > ^~~
> > /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/vmmapi.h:158:46: note: 
> > passing argument to parameter 'vmrun' here
> > int vm_run(struct vcpu *vcpu, struct vm_run *vmrun);
> > ^
> > 1 error generated.
> > 
> > 
> > Given that yesterday's update was uneventful, and that
> > src/usr.sbin/bhyvectl/bhyvectl.c has not changed in several days,
> > I'm guessing that perhaps a recent change to a header, possibly
> > involving vmexit, may be at issue here.
> 
> It appears to be broken since "vmm: Avoid embedding cpuset_t ioctl ABIs":
> https://cgit.freebsd.org/src/commit/?id=e17eca327633efc511450310afb5e4a662724e3d
> 
> See also https://ci.freebsd.org/job/FreeBSD-main-amd64-build/, where it shows 
> an error since https://ci.freebsd.org/job/FreeBSD-main-amd64-build/26653/

This should be fixed now.  My apologies, I had no idea bhyvectl provided
a way to run a VM...

Re: Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

[Dimitry Andric]

On 24 May 2023, at 13:25, David Wolfskill  wrote:
> 
> This is from an in-place source update from main-n263073-634a770a5e16 to
> main-n263112-ad513b4dba3e:
> 
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
> Building 
> /common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-1x1-4096-mbr.vhdx
> Building /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zfsd/zfsd.full
> /usr/src/usr.sbin/bhyvectl/bhyvectl.c:2389:24: error: incompatible pointer 
> types passing 'struct vm_exit *' to parameter of type 'struct vm_run *' 
> [-Werror,-Wincompatible-pointer-types]
>error = vm_run(vcpu, );
> ^~~
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/vmmapi.h:158:46: note: 
> passing argument to parameter 'vmrun' here
> int vm_run(struct vcpu *vcpu, struct vm_run *vmrun);
> ^
> 1 error generated.
> 
> 
> Given that yesterday's update was uneventful, and that
> src/usr.sbin/bhyvectl/bhyvectl.c has not changed in several days,
> I'm guessing that perhaps a recent change to a header, possibly
> involving vmexit, may be at issue here.

It appears to be broken since "vmm: Avoid embedding cpuset_t ioctl ABIs":
https://cgit.freebsd.org/src/commit/?id=e17eca327633efc511450310afb5e4a662724e3d

See also https://ci.freebsd.org/job/FreeBSD-main-amd64-build/, where it shows 
an error since https://ci.freebsd.org/job/FreeBSD-main-amd64-build/26653/

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

[Yuri]

David Wolfskill wrote:
> This is from an in-place source update from main-n263073-634a770a5e16 to
> main-n263112-ad513b4dba3e:
> 
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
> Building 
> /common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-1x1-4096-mbr.vhdx
> Building /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zfsd/zfsd.full
> /usr/src/usr.sbin/bhyvectl/bhyvectl.c:2389:24: error: incompatible pointer 
> types passing 'struct vm_exit *' to parameter of type 'struct vm_run *' 
> [-Werror,-Wincompatible-pointer-types]
> error = vm_run(vcpu, );
>  ^~~
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/vmmapi.h:158:46: note: 
> passing argument to parameter 'vmrun' here
> int vm_run(struct vcpu *vcpu, struct vm_run *vmrun);
>  ^
> 1 error generated.
> 
> 
> Given that yesterday's update was uneventful, and that
> src/usr.sbin/bhyvectl/bhyvectl.c has not changed in several days,
> I'm guessing that perhaps a recent change to a header, possibly
> involving vmexit, may be at issue here.

https://lists.freebsd.org/archives/dev-commits-src-all/2023-May/026954.html

Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

[David Wolfskill]

This is from an in-place source update from main-n263073-634a770a5e16 to
main-n263112-ad513b4dba3e:

...
Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
Building 
/common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-1x1-4096-mbr.vhdx
Building /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zfsd/zfsd.full
/usr/src/usr.sbin/bhyvectl/bhyvectl.c:2389:24: error: incompatible pointer 
types passing 'struct vm_exit *' to parameter of type 'struct vm_run *' 
[-Werror,-Wincompatible-pointer-types]
error = vm_run(vcpu, );
 ^~~
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/vmmapi.h:158:46: note: 
passing argument to parameter 'vmrun' here
int vm_run(struct vcpu *vcpu, struct vm_run *vmrun);
 ^
1 error generated.


Given that yesterday's update was uneventful, and that
src/usr.sbin/bhyvectl/bhyvectl.c has not changed in several days,
I'm guessing that perhaps a recent change to a header, possibly
involving vmexit, may be at issue here.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Folks who wish to control what others do with their bodies are often
called "conservative," when they are actually "authoritarian."

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: py-libzfs build failure on current, zpool_search_import() missing

[Alexander Leidinger]

Quoting Ryan Moeller  (from Fri, 3 Feb 2023  
10:48:35 -0500):



The build still fails on -current as of end of Jan with "too few
argument to function call, expected 4, have 3" for zfs_iter_filesystems.

Is a patch for openzfs in -current missing? I haven't seen a commit to
-current in openzfs in the last 2 days.


The openzfs changes aren't that recent, but the py-libzfs port has
been out of date for a while. I'll spin up a new snapshot VM and fix
whatever is still broken.


I can confirm that the 20230207 version of py-libzfs builds (and  
works) on -current. Thanks!


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpMIsS8likHB.pgp
Description: Digitale PGP-Signatur

Re: py-libzfs build failure on current, zpool_search_import() missing

[Alexander Leidinger]

Quoting Ryan Moeller  (from Thu, 2 Feb 2023  
10:43:53 -0500):



I've updated the py-libzfs port to fix the build.


The build still fails on -current as of end of Jan with "too few  
argument to function call, expected 4, have 3" for zfs_iter_filesystems.


Is a patch for openzfs in -current missing? I haven't seen a commit to  
-current in openzfs in the last 2 days.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpXHOYNsPe15.pgp
Description: Digitale PGP-Signatur

Re: py-libzfs build failure on current, zpool_search_import() missing

[Alan Somers]

Thanks!  But for the record, what was the actual required change?
Could you like to the PR?

On Thu, Feb 2, 2023 at 8:44 AM Ryan Moeller  wrote:
>
> I've updated the py-libzfs port to fix the build.
>
> --
> Ryan Moeller
> iXsystems, Inc.
> OS Developer
> Email: r...@ixsystems.com

Re: py-libzfs build failure on current, zpool_search_import() missing

[Alexander Leidinger]

Quoting Alan Somers  (from Thu, 2 Feb 2023  
06:58:35 -0700):



Unfortunately libzfs doesn't have a stable API, so this kind of
breakage is to be expected.  libzfs_core does, but libzfs_core is
incomplete.  You should report this problem upstream at
https://github.com/truenas/py-libzfs .


I did already.

https://github.com/truenas/py-libzfs/issues/224

There is no libzfs_core.h in /usr/include, can it be that we need to  
install this there?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpqkRgAqlhhN.pgp
Description: Digitale PGP-Signatur

Re: py-libzfs build failure on current, zpool_search_import() missing

[Alan Somers]

Unfortunately libzfs doesn't have a stable API, so this kind of
breakage is to be expected.  libzfs_core does, but libzfs_core is
incomplete.  You should report this problem upstream at
https://github.com/truenas/py-libzfs .

On Thu, Feb 2, 2023 at 2:37 AM Alexander Leidinger
 wrote:
>
> Hi,
>
> the build of py-libzfs fails on -current due to a missing
> zpool_search_import(), and as such iocage can not be build (and the
> old iocage segfaults, so the ABI seems to have changed too). The
> symbol is available in libzutil, but I can not find
> zpool_search_import() in /usr/include.
>
> Anyone with an idea if there is something missing (maybe something to
> be installed into /usr/include), or what needs to be done to py-libzfs?
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

py-libzfs build failure on current, zpool_search_import() missing

[Alexander Leidinger]

Hi,

the build of py-libzfs fails on -current due to a missing  
zpool_search_import(), and as such iocage can not be build (and the  
old iocage segfaults, so the ABI seems to have changed too). The  
symbol is available in libzutil, but I can not find  
zpool_search_import() in /usr/include.


Anyone with an idea if there is something missing (maybe something to  
be installed into /usr/include), or what needs to be done to py-libzfs?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpT2LpLYHf04.pgp
Description: Digitale PGP-Signatur

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Gary Jennejohn]

On Thu, 12 Jan 2023 10:37:34 -0700
Warner Losh  wrote:

> On Thu, Jan 12, 2023 at 4:44 AM David Wolfskill 
> wrote:
>
> > > I had this problem also.  After deleting obj/usr the buildworld
> succeeded.
> > >
> > 
>
> > > 
> >
> > Empirically:
> > rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic
> >
> > got through the issue on my build machine.  (I expect that it will also
> > do so on the others where I track head, but they are presently building
> > lang/rust.)
> >
> > Perhaps an UPDATING entry would suffice?
> >
>
> NO_CLEAN is the new default, so we need to fix this. There's a place that
> we can add this workaround, which is why I cc'd emaste (who wrote the
> framework) and des (who made the commit).
>

I actually initially ran:

pushd /usr/src;make clean;time make -s -j14 buildworld;popd

which didn't fix the problem because the .meta files were apparently not
removed.  That's why I ended up deleting obj/usr, since it guaranteed that
the buildworld would really run in a clean environment.

--
Gary Jennejohn

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Warner Losh]

On Thu, Jan 12, 2023 at 4:44 AM David Wolfskill 
wrote:

> On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> > looks like we may need another 'unclean' workaround for this?
> >
> > Warner
> >
> > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn  wrote:
> > ...
> > > I had this problem also.  After deleting obj/usr the buildworld
> succeeded.
> > >
> > 
>
> Empirically:
> rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic
>
> got through the issue on my build machine.  (I expect that it will also
> do so on the others where I track head, but they are presently building
> lang/rust.)
>
> Perhaps an UPDATING entry would suffice?
>

NO_CLEAN is the new default, so we need to fix this. There's a place that
we can add this workaround, which is why I cc'd emaste (who wrote the
framework) and des (who made the commit).

Warner



> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Putin seems to use the word "peace" in the way that Neville Chamberlain
> did.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Gary Jennejohn]

On Fri, 13 Jan 2023 01:31:59 +0900
Tomoaki AOKI  wrote:

> On Thu, 12 Jan 2023 14:41:19 +
> Gary Jennejohn  wrote:
>
[SNIP]
> >
> > I installed the new world on my tower this morning.  Now I see a new
> > problem.
> >
> > I don't know whether this new problem is related to the new tzcode, but
> > apps like gkrellm2 and xclock now display the time one hour earlier
> > than the actual time output by date(1), e.g. 10AM rather than 11AM.
> >
> > I had to set my /etc/localtime to GMT+0 to get the correct time output
> > even though I live in Germany and the correct value would be either
> > Europe/Berlin or CET.
> >
> > My laptop, which still has the old tzcode installed, did not exhibit
> > that weird error.
> >
>
> Do you have /etc/wall_cmos_clock?
> Otherwise, FreeBSD base system thinks that the CMOS clock is set to UTC.
> A blank file (just `touch`ed to create) is enough.
>
> IIUC, your laptop has it, but your tower has none.
>

Both the tower and the laptop have /etc/wall_cmos_clock, so that's not
the cause of my problem.

--
Gary Jennejohn

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Tomoaki AOKI]

On Thu, 12 Jan 2023 14:41:19 +
Gary Jennejohn  wrote:

> On Thu, 12 Jan 2023 03:44:03 -0800
> David Wolfskill  wrote:
> 
> > On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> > > looks like we may need another 'unclean' workaround for this?
> > >
> > > Warner
> > >
> > > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn  wrote:
> > > ...
> > > > I had this problem also.  After deleting obj/usr the buildworld 
> > > > succeeded.
> > > >
> > > 
> >
> > Empirically:
> > rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic
> >
> > got through the issue on my build machine.  (I expect that it will also
> > do so on the others where I track head, but they are presently building
> > lang/rust.)
> >
> > Perhaps an UPDATING entry would suffice?
> >
> 
> Didn't work for me when I decided to update my laptop, which had rather
> old /usr/src contents.  I ended up deleting obj/usr again.
> 
> I installed the new world on my tower this morning.  Now I see a new
> problem.
> 
> I don't know whether this new problem is related to the new tzcode, but
> apps like gkrellm2 and xclock now display the time one hour earlier
> than the actual time output by date(1), e.g. 10AM rather than 11AM.
> 
> I had to set my /etc/localtime to GMT+0 to get the correct time output
> even though I live in Germany and the correct value would be either
> Europe/Berlin or CET.
> 
> My laptop, which still has the old tzcode installed, did not exhibit
> that weird error.
> 
> --
> Gary Jennejohn

Do you have /etc/wall_cmos_clock?
Otherwise, FreeBSD base system thinks that the CMOS clock is set to UTC.
A blank file (just `touch`ed to create) is enough.

IIUC, your laptop has it, but your tower has none.


-- 
Tomoaki AOKI

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Gary Jennejohn]

On Thu, 12 Jan 2023 03:44:03 -0800
David Wolfskill  wrote:

> On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> > looks like we may need another 'unclean' workaround for this?
> >
> > Warner
> >
> > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn  wrote:
> > ...
> > > I had this problem also.  After deleting obj/usr the buildworld succeeded.
> > >
> > 
>
> Empirically:
>   rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic
>
> got through the issue on my build machine.  (I expect that it will also
> do so on the others where I track head, but they are presently building
> lang/rust.)
>
> Perhaps an UPDATING entry would suffice?
>

Didn't work for me when I decided to update my laptop, which had rather
old /usr/src contents.  I ended up deleting obj/usr again.

I installed the new world on my tower this morning.  Now I see a new
problem.

I don't know whether this new problem is related to the new tzcode, but
apps like gkrellm2 and xclock now display the time one hour earlier
than the actual time output by date(1), e.g. 10AM rather than 11AM.

I had to set my /etc/localtime to GMT+0 to get the correct time output
even though I live in Germany and the correct value would be either
Europe/Berlin or CET.

My laptop, which still has the old tzcode installed, did not exhibit
that weird error.

--
Gary Jennejohn

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[David Wolfskill]

On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> looks like we may need another 'unclean' workaround for this?
> 
> Warner
> 
> On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn  wrote:
> ... 
> > I had this problem also.  After deleting obj/usr the buildworld succeeded.
> >
> 

Empirically:
rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic

got through the issue on my build machine.  (I expect that it will also
do so on the others where I track head, but they are presently building
lang/rust.)

Perhaps an UPDATING entry would suffice?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Warner Losh]

looks like we may need another 'unclean' workaround for this?

Warner

On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn  wrote:

> On Wed, 11 Jan 2023 04:05:43 -0800
> David Wolfskill  wrote:
>
> > Running:
> > FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275
> main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> >
> > and performing an in-place source update to main-n260011-40bb52c89b87
> > using META mode, I encountered:
> >
> > Building
> /common/S4/obj/usr/src/amd64.amd64/usr.bin/tar/tests/test_option_k.o
> > Building
> /common/S4/obj/usr/src/amd64.amd64/usr.bin/calendar/tests/legacy_test
> > Building /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic
> > objcopy: open zic failed: Is a directory
> > *** [zic] Error code 1
> >
> > make[4]: stopped in /usr/src/usr.sbin/zic
> > .ERROR_TARGET='zic'
> >
> .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta'
> > .MAKE.LEVEL='4'
> > MAKEFILE=''
> > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> > _ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=zic.debug
> zic.full zic;'
> > .CURDIR='/usr/src/usr.sbin/zic'
> > .MAKE='make'
> > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic'
> > .TARGETS='all'
> > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> > LD_LIBRARY_PATH=''
> > MACHINE='amd64'
> > MACHINE_ARCH='amd64'
> > MAKEOBJDIRPREFIX=''
> > MAKESYSPATH='/usr/src/share/mk'
> > MAKE_VERSION='20220726'
> >
>
> I had this problem also.  After deleting obj/usr the buildworld succeeded.
>
> > Contents of the META_FILE:
> > # Meta data file /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta
> > CMD objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full zic
> > CWD /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic
> > TARGET zic
> > OODATE zic.full zic.debug
> > -- command output --
> > objcopy: open zic failed: Is a directory
> >
> > *** Error code 1
> >
> > -- filemon acquired metadata --
> > # filemon version 5
> > # Target pid 76995
> > # Start 1673437990.835926
> > V 5
> > E 84537 /bin/sh
> > R 84537 /etc/libmap.conf
> > R 84537 /var/run/ld-elf.so.hints
> > R 84537 /lib/libedit.so.8
> > R 84537 /lib/libc.so.7
> > R 84537 /lib/libtinfow.so.9
> > R 84537 /usr/share/locale/en_US.UTF-8/LC_COLLATE
> > R 84537 /usr/share/locale/en_US.UTF-8/LC_CTYPE
> > R 84537 /usr/share/locale/en_US.UTF-8/LC_MONETARY
> > R 84537 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
> > R 84537 /usr/share/locale/en_US.UTF-8/LC_TIME
> > R 84537 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
> > F 84537 84538
> > E 84538 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin/objcopy
> > R 84538 zic.full
> > X 84538 1 0
> > X 84537 1 0
> > # Stop 1673437990.838926
> > # Bye bye
> >
> > This is on a 32-core amd64 machine with 256GiB RAM (in case that's
> > relevant).
> >
> > Peace,
> > david
> > --
> > David H. Wolfskill  da...@catwhisker.org
> > Putin seems to use the word "peace" in the way that Neville Chamberlain
> did.
> >
> > See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
>
> --
> Gary Jennejohn
>
>

Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[Gary Jennejohn]

On Wed, 11 Jan 2023 04:05:43 -0800
David Wolfskill  wrote:

> Running:
> FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275 
> main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
> amd64
>
> and performing an in-place source update to main-n260011-40bb52c89b87
> using META mode, I encountered:
>
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/tar/tests/test_option_k.o
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/calendar/tests/legacy_test
> Building /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic
> objcopy: open zic failed: Is a directory
> *** [zic] Error code 1
>
> make[4]: stopped in /usr/src/usr.sbin/zic
> .ERROR_TARGET='zic'
> .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta'
> .MAKE.LEVEL='4'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full 
> zic;'
> .CURDIR='/usr/src/usr.sbin/zic'
> .MAKE='make'
> .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic'
> .TARGETS='all'
> DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX=''
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20220726'
>

I had this problem also.  After deleting obj/usr the buildworld succeeded.

> Contents of the META_FILE:
> # Meta data file /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta
> CMD objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full zic
> CWD /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic
> TARGET zic
> OODATE zic.full zic.debug
> -- command output --
> objcopy: open zic failed: Is a directory
>
> *** Error code 1
>
> -- filemon acquired metadata --
> # filemon version 5
> # Target pid 76995
> # Start 1673437990.835926
> V 5
> E 84537 /bin/sh
> R 84537 /etc/libmap.conf
> R 84537 /var/run/ld-elf.so.hints
> R 84537 /lib/libedit.so.8
> R 84537 /lib/libc.so.7
> R 84537 /lib/libtinfow.so.9
> R 84537 /usr/share/locale/en_US.UTF-8/LC_COLLATE
> R 84537 /usr/share/locale/en_US.UTF-8/LC_CTYPE
> R 84537 /usr/share/locale/en_US.UTF-8/LC_MONETARY
> R 84537 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
> R 84537 /usr/share/locale/en_US.UTF-8/LC_TIME
> R 84537 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
> F 84537 84538
> E 84538 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin/objcopy
> R 84538 zic.full
> X 84538 1 0
> X 84537 1 0
> # Stop 1673437990.838926
> # Bye bye
>
> This is on a 32-core amd64 machine with 256GiB RAM (in case that's
> relevant).
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Putin seems to use the word "peace" in the way that Neville Chamberlain did.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.


--
Gary Jennejohn

Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87

[David Wolfskill]

Running:
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275 
main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

and performing an in-place source update to main-n260011-40bb52c89b87
using META mode, I encountered:

Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/tar/tests/test_option_k.o
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/calendar/tests/legacy_test
Building /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic
objcopy: open zic failed: Is a directory
*** [zic] Error code 1

make[4]: stopped in /usr/src/usr.sbin/zic
.ERROR_TARGET='zic'
.ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full zic;'
.CURDIR='/usr/src/usr.sbin/zic'
.MAKE='make'
.OBJDIR='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic'
.TARGETS='all'
DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20220726'

Contents of the META_FILE:
# Meta data file /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta
CMD objcopy --strip-debug --add-gnu-debuglink=zic.debug  zic.full zic
CWD /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic
TARGET zic
OODATE zic.full zic.debug
-- command output --
objcopy: open zic failed: Is a directory

*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 76995
# Start 1673437990.835926
V 5
E 84537 /bin/sh
R 84537 /etc/libmap.conf
R 84537 /var/run/ld-elf.so.hints
R 84537 /lib/libedit.so.8
R 84537 /lib/libc.so.7
R 84537 /lib/libtinfow.so.9
R 84537 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 84537 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 84537 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 84537 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 84537 /usr/share/locale/en_US.UTF-8/LC_TIME
R 84537 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 84537 84538
E 84538 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin/objcopy
R 84538 zic.full
X 84538 1 0
X 84537 1 0
# Stop 1673437990.838926
# Bye bye

This is on a 32-core amd64 machine with 256GiB RAM (in case that's
relevant).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: all_subdir_lib/libclang_rt build failure (libc++ ld error)

[Alain Zscheile]

Hello,

On 21.12.22 01:24, Mark Millard wrote:

Alain Zscheile  wrote on
Date: Tue, 20 Dec 2022 23:12:40 UTC :


I encountered a build failure while trying to build fbsd'
src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701


That commit is from main:

 • git: ae521fda895f - main - stress2: Added link to problem found Peter 
Holm


with `make -j4 buildworld` on an FreeBSD 13.1 system.


So this was some 13.1 variant building at ae521fda895f of
main [so: 14]. That was not obvious on a first read of the
report. Sort of a self-hosted version upgrade cross-build.

For reference (example local installs):

# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep -v 
lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/lib/libc++.so.1

Note that only main has main-amd64-poud-bulk_a/lib/libc++.so.1
and it does not have a main-amd64-poud-bulk_a/usr/lib/libc++.so.1 .

As for lib32:

# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/usr/lib32/libc++.so.1

So all 3 have *-amd64-poud-bulk_a/usr/lib32/libc++.so.1 and none
have a *-amd64-poud-bulk_a/lib32/libc++.so.1 .

tmp/lib/libc++.so.1 would be a main [so: 14] style path.
tmp/usr/lib/libc++.so.1 would be a 13.1 style path.

The build appears to have which type of context applies
confused.

It is not clang that is the issue, it is that FreeBSD changed
the path used for libc++.so.1 . (main avoids needing more
mounts already being actie place when libc++.so.1 is used in
some common configurations, usr/lib/ not being available yet.


thanks for the explanation.


Looks to me like whatever vintage/variant of 13.1 it was did


"vintage" I upgraded to the latest stable/13 commit before
attempting the jump to main.


not yet(?) have logic for making sure that it provides for
builds of main [so: 14] that have the new libc++.so.1 style
path. Nor did the main materials have logic to make it work
when built from an older context, such as a 13.1 context.
At least one of the two must happen to allow 13.1 to build
a 14. Having main [so: 14] deal with it, if possible, could
possibly also deal with 13.0 vintages/variants without
adjusting 13.0 materials.


To somewhat fix it I ran: `make cleanworld`,
then reran `make -j4 buildworld`, while that was in progress
I created a symlink from .../tmp/usr/lib/libc++.so.1 to
`../../lib/libc++.so.` which resulted in a successfully finishing
build.

Regards,
Alain Zscheile

RE: all_subdir_lib/libclang_rt build failure (libc++ ld error)

[Mark Millard]

Alain Zscheile  wrote on
Date: Tue, 20 Dec 2022 23:12:40 UTC :

> I encountered a build failure while trying to build fbsd'
> src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701

That commit is from main:

• git: ae521fda895f - main - stress2: Added link to problem found Peter Holm

> with `make -j4 buildworld` on an FreeBSD 13.1 system.

So this was some 13.1 variant building at ae521fda895f of
main [so: 14]. That was not obvious on a first read of the
report. Sort of a self-hosted version upgrade cross-build.

For reference (example local installs):

# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep -v 
lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/lib/libc++.so.1

Note that only main has main-amd64-poud-bulk_a/lib/libc++.so.1
and it does not have a main-amd64-poud-bulk_a/usr/lib/libc++.so.1 .

As for lib32:

# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/usr/lib32/libc++.so.1

So all 3 have *-amd64-poud-bulk_a/usr/lib32/libc++.so.1 and none
have a *-amd64-poud-bulk_a/lib32/libc++.so.1 .

> 
> --- all_subdir_lib/libclang_rt ---
> ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside
> /usr/obj/usr/src/amd64.amd64/tmp
> >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
> >>> ^
> c++: error: linker command failed with exit code 1
> (use -v to see invocation)
> 
> make[2]: stopped in /usr/src
> 
> 
> The stated file is indeed not present, and resides in .../tmp/lib
> instead of .../tmp/usr/lib.

tmp/lib/libc++.so.1 would be a main [so: 14] style path.
tmp/usr/lib/libc++.so.1 would be a 13.1 style path.

The build appears to have which type of context applies
confused.

> It appears that the .so linker script
> should either be patched (to point to /lib instead of /usr/lib) or
> a symlink for the .so.1 file should be created.
> (at least the corresponding c++ command line doesn't indicate
> anything to the contrary of that afaik)
> 
> I don't know when this problem was introduced and it might be the
> case that this bootstrapping problem only occurs when the "outside
> system" (in this case FreeBSD 13.1) has an older version of clang.

It is not clang that is the issue, it is that FreeBSD changed
the path used for libc++.so.1 . (main avoids needing more
mounts already being actie place when libc++.so.1 is used in
some common configurations, usr/lib/ not being available yet.

> (as I'm not really sure when the bootstrapping process actually
> kicks in, as it appears to have omitted building a linker when it
> detected that the current one is recent enough/matches)
> It might also be that case that this is just the result of a
> missing dependency, which messes with parallel building, idk...

Looks to me like whatever vintage/variant of 13.1 it was did
not yet(?) have logic for making sure that it provides for
builds of main [so: 14] that have the new libc++.so.1 style
path. Nor did the main materials have logic to make it work
when built from an older context, such as a 13.1 context.
At least one of the two must happen to allow 13.1 to build
a 14. Having main [so: 14] deal with it, if possible, could
possibly also deal with 13.0 vintages/variants without
adjusting 13.0 materials.

===
Mark Millard
marklmi at yahoo.com

all_subdir_lib/libclang_rt build failure (libc++ ld error)

[Alain Zscheile]

Hello,

I encountered a build failure while trying to build fbsd'
src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
with `make -j4 buildworld` on an FreeBSD 13.1 system.


--- all_subdir_lib/libclang_rt ---
ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc++.so:2:
  cannot find /usr/lib/libc++.so.1 inside
  /usr/obj/usr/src/amd64.amd64/tmp

GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
^

c++: error: linker command failed with exit code 1
  (use -v to see invocation)

make[2]: stopped in /usr/src


The stated file is indeed not present, and resides in .../tmp/lib
instead of .../tmp/usr/lib. It appears that the .so linker script
should either be patched (to point to /lib instead of /usr/lib) or
a symlink for the .so.1 file should be created.
(at least the corresponding c++ command line doesn't indicate
 anything to the contrary of that afaik)

I don't know when this problem was introduced and it might be the
case that this bootstrapping problem only occurs when the "outside
system" (in this case FreeBSD 13.1) has an older version of clang.
(as I'm not really sure when the bootstrapping process actually
 kicks in, as it appears to have omitted building a linker when it
 detected that the current one is recent enough/matches)
It might also be that case that this is just the result of a
missing dependency, which messes with parallel building, idk...

Regards,
Alain Zscheile

dpaa2_mc_acpi.o build failure with ACPI_DEBUG option? (sources are back as of 2022-11-06, unfortunately)

[Mark Millard]

--- dpaa2_mc_acpi.o ---
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: implicit declaration 
of function 'AcpiUtTrace' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:5: note: expanded 
from macro 'ACPI_FUNCTION_TRACE'
AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
^
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: use of undeclared 
identifier '_AcpiModuleName'
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:18: note: expanded 
from macro 'ACPI_FUNCTION_TRACE'
AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
 ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:402:39: note: expanded 
from macro 'ACPI_DEBUG_PARAMETERS'
__LINE__, ACPI_GET_FUNCTION_NAME, _AcpiModuleName, _COMPONENT
  ^
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: use of undeclared 
identifier '_COMPONENT'
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:18: note: expanded 
from macro 'ACPI_FUNCTION_TRACE'
AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
 ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:402:56: note: expanded 
from macro 'ACPI_DEBUG_PARAMETERS'
__LINE__, ACPI_GET_FUNCTION_NAME, _AcpiModuleName, _COMPONENT
   ^

But this is for source that is somewhat over a month old:

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
f83db6441a2f (HEAD -> main, freebsd/main, freebsd/HEAD) sctp: minor changes due 
to upstreaming of Glebs recent changes
branch: main
merge-base: f83db6441a2f4f925a169c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +
n259064 (--first-parent --count for merge-base)


===
Mark Millard
marklmi at yahoo.com

build failure WITH_ASAN

[Chuck Tuffli]

make buildworld -DWITH_UBSAN -DWITH_ASAN is failing for me with the error:

building shared library libc.so.7
ld: error: cannot open
/usr/home/ctuffli/dev/freebsd/obj/usr/home/ctuffli/dev/freebsd/src.git/amd64.amd64/tmp/usr/lib/clang/14.0.5/lib/freebsd/libclang_rt.asan_static-x86_64.a:
No such file or directory
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

This does use meta mode but still occurs after running cleanworld.
greping through the sources, I see a references to
libclang_rt.asan_static-x86_64.a in
tools/build/mk/OptionalObsoleteFiles.inc in the MK_CLANG == no
section. What other information can I provide to help figure this out?
Thanks!

--chuck

Re: build failure on -current

[Gary Jennejohn]

On Fri, 17 Dec 2021 09:44:20 -0800
Chuck Tuffli  wrote:

> When building current from git, I keep hitting the error below. This
> is with meta-mode, but I've also tried deleting the object directory.
> The system also has a couple of tweaks to src-env.conf that were an
> attempt to avoid building any (most?) of clang. Relevant system
> information:
> 
> $ uname -mrsv
> FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT main-22c4ab6cb0 GENERIC  amd64
> $ cat /etc/src-env.conf
> WITH_META_MODE=YES
> WITHOUT_CLANG=YES
> WITHOUT_CLANG_BOOTSTRAP=YES
> $ env MAKEOBJDIRPREFIX=$(realpath ../obj) make buildworld -j$(sysctl -n 
> hw.ncpu)
> 
> --- Core/ModuleList.o ---
> In file included from
> /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/lldb/source/Core/ModuleList.cpp:34:
> In file included from
> /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Driver/Driver.h:12:
> In file included from
> /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/Diagnostic.h:17:
> /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/DiagnosticIDs.h:71:10:
> fatal error: 'clang/Basic/DiagnosticCommonKinds.inc' file not found
> #include "clang/Basic/DiagnosticCommonKinds.inc"
>  ^~~
> 1 error generated.
> *** [Core/ModuleList.o] Error code 1
> 
> Where did I goof? TIA
> 

Do you need lldb?  If not you could try adding WITHOUT_LLDB to
src-env.conf and see what happens.

-- 
Gary Jennejohn

build failure on -current

[Chuck Tuffli]

When building current from git, I keep hitting the error below. This
is with meta-mode, but I've also tried deleting the object directory.
The system also has a couple of tweaks to src-env.conf that were an
attempt to avoid building any (most?) of clang. Relevant system
information:

$ uname -mrsv
FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT main-22c4ab6cb0 GENERIC  amd64
$ cat /etc/src-env.conf
WITH_META_MODE=YES
WITHOUT_CLANG=YES
WITHOUT_CLANG_BOOTSTRAP=YES
$ env MAKEOBJDIRPREFIX=$(realpath ../obj) make buildworld -j$(sysctl -n hw.ncpu)

--- Core/ModuleList.o ---
In file included from
/usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/lldb/source/Core/ModuleList.cpp:34:
In file included from
/usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Driver/Driver.h:12:
In file included from
/usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/Diagnostic.h:17:
/usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/DiagnosticIDs.h:71:10:
fatal error: 'clang/Basic/DiagnosticCommonKinds.inc' file not found
#include "clang/Basic/DiagnosticCommonKinds.inc"
 ^~~
1 error generated.
*** [Core/ModuleList.o] Error code 1

Where did I goof? TIA

--chuck

Re: Build failure

[marco]

On Tue, Oct 20, 2020 at 07:15:16AM +, you (marco) sent the following to 
[freebsd-current] :
> > 
> 
> I checked out 05b104834ae7 (r366780) from
> https://cgit-beta.freebsd.org/src.git and ran a 'make -j4 builworld and make 
> -j4 buildkernel'
> for GENERIC-NODEBUG which also failed (buildworld was successfull).
> I did update the ports tree (portsnap fetch update) right before
> buildkernel and also have
> drm-current-kmod installed.
> 
> My normal procedure of updating current using BEs (using
> WITH_MALLOC_PRODUCTION= in /etc/src.conf):
> 
> make -j4 buildworld
> make -j4 buildkernel
> bectl create x
> bectl mount x /mnt
> make -j4 installkernel DESTDIR=/mnt
> mergemaster -Fp -D /mnt
> make -j4 installworld DESTDIR=/mnt
> mergemaster -Fi -D /mnt
> make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=/mnt
> make -DBATCH_DELETE_OLD_FILES delete-old-libs DESTDIR=/mnt (optional)
> bectl umount x
> bectl activate x
> shutdown -r +1
> 
> I do see there's an update to drm-current-kmod (g20201003) and I'm currently
> on g20200914 but I don't want to
> update in place in my current BE (not sure if this could solve the
> errors that are thrown).
> 
> --- linux_backlight.o ---
> In file included from 
> /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
> In file included from 
> /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
> In file included from 
> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
> In file included from 
> /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12:
> In file included from 
> /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:10:

Managed to get this all sorted.
I created a new BE based on r366252, mounted it and
updated and upgraded pkg and all my packages (including drm-current-kmod) into 
that new BE.
Booted to that BE and from there I did another buildkernel which
succeeded.
I hadn't run make cleanworld prior to the make buildkernel so still had that 
world built and proceeed from there.
I'm now booted into my latest BE 

 [~] uname -apKU
 FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #1
 05b104834ae7-c253833(HE
 C-NODEBUG  amd64 amd64 1300121 1300121

-- 
Marco van Lienen -- FreeBSD enthusiast
https://keybase.io/scarcry , GnuPG id: 8580E6CB
"The Tuck Pendleton machine...zero defects."
___
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: Build failure

[marco]

On Sat, Oct 03, 2020 at 10:36:30AM +0200, you (Emmanuel Vadot) sent the 
following to [freebsd-current] :
> On Fri, 2 Oct 2020 19:53:44 -0500
> Patrick McMunn  wrote:
> 
> > I update the sources today and ran "make -j24 buildworld buildkernel
> > KERNCONF=GENERIC-NODEBUG", and the build failed. I made sure to "make
> > clean" and "make cleanworld" and try again, and I got the same result.
> > 
> > -- 
> > Patrick McMunn
> > 
> > - Learn more about the Catholic Faith: http://www.catholic.com/
> > - Pray with the Church: http://www.universalis.com/
> 
>  Hi,
>  You need to update your ports tree.
>  the drm-current-kmod ports install it's sources so the module will be
> rebuilt when you build a kernel.
>  This works as long as no changes in base need changes in those sources
> too. If there is needed changes in drm-kmod sources this unfortunatelly
> fails to compile, not much we can do here.

I checked out 05b104834ae7 (r366780) from
https://cgit-beta.freebsd.org/src.git and ran a 'make -j4 builworld and make 
-j4 buildkernel'
for GENERIC-NODEBUG which also failed (buildworld was successfull).
I did update the ports tree (portsnap fetch update) right before
buildkernel and also have
drm-current-kmod installed.

My normal procedure of updating current using BEs (using
WITH_MALLOC_PRODUCTION= in /etc/src.conf):

make -j4 buildworld
make -j4 buildkernel
bectl create x
bectl mount x /mnt
make -j4 installkernel DESTDIR=/mnt
mergemaster -Fp -D /mnt
make -j4 installworld DESTDIR=/mnt
mergemaster -Fi -D /mnt
make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=/mnt
make -DBATCH_DELETE_OLD_FILES delete-old-libs DESTDIR=/mnt (optional)
bectl umount x
bectl activate x
shutdown -r +1

I do see there's an update to drm-current-kmod (g20201003) and I'm currently
on g20200914 but I don't want to
update in place in my current BE (not sure if this could solve the
errors that are thrown).

--- linux_backlight.o ---
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:10:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/pci.h:10:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:52:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/dma-mapping.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/dma-mapping.h:116:10: error: 
incomplete definition of type 'struct device'
if (!dev->dma_priv || !dma_supported(dev, dma_mask))
 ~~~^
/usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device'
typedef struct device   *device_t;
   ^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:10:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/pci.h:10:
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:203:24: error: field 
has incomplete type 'struct device_driver'
struct device_driverdriver;
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:201:9:
 note: forward declaration of 'struct device_driver'
struct device_driver driver;
   ^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:10:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/pci.h:10:
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:233:17: error: field 
has incomplete type 'struct device'
struct device   dev;
^
/usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device'
typedef struct device   *device_t;
   ^

Re: Build failure

[Emmanuel Vadot]

On Fri, 2 Oct 2020 19:53:44 -0500
Patrick McMunn  wrote:

> I update the sources today and ran "make -j24 buildworld buildkernel
> KERNCONF=GENERIC-NODEBUG", and the build failed. I made sure to "make
> clean" and "make cleanworld" and try again, and I got the same result.
> 
> -- 
> Patrick McMunn
> 
> - Learn more about the Catholic Faith: http://www.catholic.com/
> - Pray with the Church: http://www.universalis.com/

 Hi,
 You need to update your ports tree.
 the drm-current-kmod ports install it's sources so the module will be
rebuilt when you build a kernel.
 This works as long as no changes in base need changes in those sources
too. If there is needed changes in drm-kmod sources this unfortunatelly
fails to compile, not much we can do here.

 Cheers,

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

Build failure

[Patrick McMunn]

I update the sources today and ran "make -j24 buildworld buildkernel
KERNCONF=GENERIC-NODEBUG", and the build failed. I made sure to "make
clean" and "make cleanworld" and try again, and I got the same result.

-- 
Patrick McMunn

- Learn more about the Catholic Faith: http://www.catholic.com/
- Pray with the Church: http://www.universalis.com/
   ^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_i2c.c:92:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:4:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/uapi/linux/fb.h:5:
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:166:16:
 error: field has incomplete type 'struct device'
struct device dev;  /* the device structure */
  ^
/usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device'
typedef struct device   *device_t;
   ^
--- linux_notifier.o ---
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_notifier.c:15:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: static 
declaration of 'dev_get_drvdata' follows non-static declaration
dev_get_drvdata(const struct device *dev)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:243:9:
 note: previous implicit declaration is here
return dev_get_drvdata(>dev);
   ^
--- linux_i2c.o ---
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_i2c.c:92:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:4:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/uapi/linux/fb.h:5:
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:201:23:
 error: field has incomplete type 'struct device_driver'
struct device_driver driver;
 ^
--- linux_notifier.o ---
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_notifier.c:15:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: static 
declaration of 'dev_set_drvdata' follows non-static declaration
--- linux_i2c.o ---
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:201:9:
 note: forward declaration of 'struct device_driver'
struct device_driver driver;
   ^
--- linux_notifier.o ---
dev_set_drvdata(struct device *dev, void *data)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:249:2:
 note: previous implicit declaration is here
dev_set_drvdata(>dev, data);
^
--- linux_i2c.o ---
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:237:2:
 error: implicit declaration of function 'device_unregister' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
device_unregister(>dev);
^
--- linux_notifier.o ---
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_notifier.c:15:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: static 
declaration of 'device_unregister' follows non-static declaration
device_unregister(struct device *dev)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:237:2:
 note: previous implicit declaration is here
device_unregister(>dev);
^
--- linux_compat.o ---
12 errors 

Re: objcopy "text file busy" build failure with populated /usr/obj

[Frederic Chardon]

Le dim. 20 sept. 2020 à 16:59, Mark Murray  a écrit :
>
> Hi *
>
> I've been getting these build failures for a while (weeks/months). The 
> machine is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and 
> zfs filesystem. If I empty out /usr/obj, then the build works, but takes a 
> few hours. If I do a no-clean build with /obj/obj populated with he contents 
> of a previous build, and /usr/src with updated ("svn update") sources, then 
> the below nearly always happens early in the rebuild. It is in "stage 4.4: 
> building everything" that this happens. The build is parallel (-j8), and I 
> have manually de-threaded the output.
>
> The generated command-line from the logfile is:
>
> cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64  MACHINE=arm64  
> CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target 
> aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
> -target aarch64-unknown-freebsd13.0 
> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target 
> aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" 
> LLVM_LINK=""  NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" 
> STRIPBIN="strip"  INSTALL="install -U"  
> PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
>   SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  -f Makefile.inc1  
> BWPHASE=everything  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all
>
> Anyone else seeing this?
>
> objcopy --strip-debug --add-gnu-debuglink=objcopy.debug  objcopy.full objcopy
> objcopy: open objcopy failed: Text file busy
> --- all_subdir_usr.bin/objcopy ---
> *** [objcopy] Error code 1
>
> make[4]: stopped in /usr/src/usr.bin/objcopy
>
> M
> --

Hi

I got the same on amd64 with a meta mode build, on zfs as well. Oddly
(or not), it happens only if I make buildworld as a normal user, but
not as root. A second make buildworld always succeed.
___
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: objcopy "text file busy" build failure with populated /usr/obj

[Michael Butler]

On 9/20/20 10:58 AM, Mark Murray wrote:

Hi *

I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin 
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then 
the build works, but takes a few hours. If I do a no-clean build with /obj/obj populated with he 
contents of a previous build, and /usr/src with updated ("svn update") sources, then the 
below nearly always happens early in the rebuild. It is in "stage 4.4: building 
everything" that this happens. The build is parallel (-j8), and I have manually de-threaded 
the output.

The generated command-line from the logfile is:

cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64  MACHINE=arm64  CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm 
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/

legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  
SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  -f Makefile.inc1  
BWPHASE=everything  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all


Anyone else seeing this?

objcopy --strip-debug --add-gnu-debuglink=objcopy.debug  objcopy.full objcopy
objcopy: open objcopy failed: Text file busy
--- all_subdir_usr.bin/objcopy ---
*** [objcopy] Error code 1

make[4]: stopped in /usr/src/usr.bin/objcopy


Yes, although simply restarting the build seems to avoid the problem on 
the second attempt.


However, I'm building on a dual quad-core amd64 platform (8 cores total) 
so it's not just ARM being affected,


imb


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

objcopy "text file busy" build failure with populated /usr/obj

[Mark Murray]

Hi *

I've been getting these build failures for a while (weeks/months). The machine 
is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and zfs 
filesystem. If I empty out /usr/obj, then the build works, but takes a few 
hours. If I do a no-clean build with /obj/obj populated with he contents of a 
previous build, and /usr/src with updated ("svn update") sources, then the 
below nearly always happens early in the rebuild. It is in "stage 4.4: building 
everything" that this happens. The build is parallel (-j8), and I have manually 
de-threaded the output.

The generated command-line from the logfile is:

cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64  MACHINE=arm64  
CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target 
aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
-target aarch64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target 
aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" 
LLVM_LINK=""  NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" 
STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
  SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  -f Makefile.inc1  
BWPHASE=everything  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all

Anyone else seeing this?

objcopy --strip-debug --add-gnu-debuglink=objcopy.debug  objcopy.full objcopy
objcopy: open objcopy failed: Text file busy
--- all_subdir_usr.bin/objcopy ---
*** [objcopy] Error code 1

make[4]: stopped in /usr/src/usr.bin/objcopy

M
--




signature.asc
Description: Message signed with OpenPGP

cross-build failure on objcopy

[Michael Butler]

When cross-compiling for i386 on amd64 (which has 2 by 4 cores), I get
the error below after a previously successful build.

Running the build again (a 3rd time) completes successfully :-(

This is the output from

cd /usr/src/release; ./release.sh -c release-i386.conf

 [ .. ]

===> usr.bin/cxxfilt (all)
===> usr.bin/objcopy (all)
===> usr.sbin/bsnmpd/tools/bsnmptools (all)
===> usr.bin/file2c (all)
===> usr.bin/gprof (all)
===> usr.bin/indent (all)
===> usr.bin/lex (all)
===> usr.bin/mkstr (all)
===> usr.bin/nm (all)
objcopy: open objcopy failed: Text file busy
--- objcopy ---
*** [objcopy] Error code 1
make[4]: *** objcopy removed

make[4]: stopped in /usr/local/release-builds/i386/usr/src/usr.bin/objcopy
.ERROR_TARGET='objcopy'
.ERROR_META_FILE='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.bin/objcopy/objcopy.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes'
_ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=objcopy.debug
objcopy.full objcopy;'
.CURDIR='/usr/local/release-builds/i386/usr/src/usr.bin/objcopy'
.MAKE='make'
.OBJDIR='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.bin/objcopy'
.TARGETS='all'
DESTDIR='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/local/release-builds/i386/usr/src/share/mk'

imb

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Jilles Tjoelker]

On Fri, Jan 04, 2019 at 07:56:42AM +0100, Michal Meloun wrote:
> On 29.12.2018 18:47, Dennis Clarke wrote:
> > On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
> >>
> >> On 2018-Dec-28, at 12:12, Mark Millard  wrote:
> >>
> >>> On 2018-Dec-28, at 05:13, Michal Meloun 
> >>> wrote:
> >>>
>  Mark,
>  this is known problem with qemu-user-static.
>  Emulation of every single interruptible syscall is broken by design (it
>  have signal related races). Theses races cannot be solved without major
>  rewrite of syscall emulation code.
>  Unfortunately, nobody actively works on this, I think.
> 

> > Following along here quietly and I had to blink at this a few times.
> > Is there a bug report somewhere within the qemu world related to this
> >  'broken by design' qemu feature?

> Firstly, I apologize for late answer. Writing a technically accurate but
> still comprehensible report is extremely difficult for me.

> Major design issue with qemu-user is the fact that guest (blocking /
> interruptible) syscalls must be emulated atomically, including
> delivering of asynchronous signals (including signals originated by
> other thread).
> This is something that cannot be emulated precisely by user mode
> program, without specific kernel support. Let me explain this in a
> little more details.

> [snip]

> This look a much better. The code blocks all signals first, then checks
> if any signal is pending. If yes, then does not-blocking select()
> (because timeout is zero) and correctly returns EINTR immediately.
> Otherwise, it uses other variant of select(), pselect() which adjusts
> right signal mask itself.
> That's mean that syscall is called with blocked signal delivery, but
> kernel adjusts right sigmask before it waits for event. While this looks
> like perfect solution and this code closes all races from first version,
> then it doesn't. pselect() uses different semantic that select(), it
> doesn't update timeout argument. So this solution is also inappropriate.

FreeBSD select() never updates the passed timeout. When emulating Linux
syscalls, this will have to be done manually.

> Moreover, I think, we don't have p equivalents for all blocking
> syscalls.

We definitely do not. For example, open() has no equivalent with a
signal mask.

> Mark, I hope that this is also the answer to your question posted to
> hackers@ and also the exploitation why you see hang.

> Linux uses different approach to overcome this issue, safe_syscall ->
> https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4
> It looks like workable workaround, but I'm not sure about ERESTART
> versus EINTR return values. Imho, this can be problem.

This looks like a reasonable solution. Musl libc uses the same approach
to implement pthread cancellation (where with the default "deferred"
cancellation type, cancellation takes effect at cancellation points
only, which include most blocking system calls; if a cancellation
request comes in at the same time as a blocking cancellation point
system call starts, the same race condition needs to be avoided).

As for ERESTART vs EINTR, EINTR can be treated like any other error. On
the other hand, ERESTART (or variants like ERESTARTSYS) is never
returned by the kernel, but instead causes the kernel to rewind the
program counter (so the system call instruction will be executed again)
just before invoking the signal handler. Therefore, when the host kernel
does this to qemu, qemu must do the same to the guest.

If a signal is delivered just before qemu makes a system call on behalf
of the guest, this may look like ERESTART. This is fine since it looks
the same as if the signal was delivered just before the guest's system
call instruction.

The approach as used by FreeBSD libc to implement pthread cancellation
(thr_wake(2) on self in the signal handler) will not let you distinguish
between ERESTART and EINTR, so you would have to replicate that
determination (which typically but not always depends on the signal's
SA_RESTART flag and which system call it is). Therefore, I would not
recommend that approach.

> I have list of other qemu-user problems (I mean mainly a bsd-user part
> of qemu code here), not counting normal coding bugs:
> - code is not thread safety but is used in threaded environment (rw
> locks for example),
> - emulate  some sysctl's and resource limits / usage behavior is very
> hard  (mainly if we emulate 32-bits guest on 64-bits host)

In many such cases, the proper behaviour can be found in the kernel code
(when a 64-bit kernel needs to handle a system call from a 32-bit
process).

I expect problems with getdirentries() and struct dirent.d_off with
filesystems that return hashed filenames as positions.

> - if host syscall returns ERESTART, we should do full unroll and pass it
> to guest.

Yes (with the above mentioned caveats about how ERESTART is returned).

> - the syscalls emulation should not use the libc functions, but 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

On 2019-Jan-3, at 22:56, Michal Meloun  wrote:

> On 29.12.2018 18:47, Dennis Clarke wrote:
>> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>> 
>>> On 2018-Dec-28, at 12:12, Mark Millard  wrote:
>>> 
 On 2018-Dec-28, at 05:13, Michal Meloun 
 wrote:
 
> Mark,
> this is known problem with qemu-user-static.
> Emulation of every single interruptible syscall is broken by design (it
> have signal related races). Theses races cannot be solved without major
> rewrite of syscall emulation code.
> Unfortunately, nobody actively works on this, I think.
> 
>> 
>> Following along here quietly and I had to blink at this a few times.
>> Is there a bug report somewhere within the qemu world related to this
>>  'broken by design' qemu feature?
> 
> Firstly, I apologize for late answer. Writing a technically accurate but
> still comprehensible report is extremely difficult for me.

Thanks for doing so.

> . . .
> Mark, I hope that this is also the answer to your question posted to
> hackers@ and also the exploitation why you see hang.

Again thanks: it was helpful for my gaining some understanding of
the code structure.

But it turns out that another of your list of problems is involved
in the hang-up:

> . . .
> - and last major one. At this time, all guest structures are maintained
> by hand. Due to huge amount of these structures, this is the extreme
> error prone approach.  We should convert this to script generated code,
> including guest syscalls definition.

It turns out that "struct target_cmsghdr" has the wrong overall size,
the wrong first field size, and the wrong offsets for later fields
for amd64->aarch64 use (or likely any 64-bit->64-bit host-target
pair, even amd64->x86_64). In fact the code reports via:

  gemu_log("Unsupported ancillary data: %d/%d\n",
  cmsg->cmsg_level, cmsg->cmsg_type);


because of msg->cmsg_level and cmsg->cmsg_type ending up with
messed up values. It hangs after that message shows up. The
more complete code containing that qemu_log call is:

  if ((cmsg->cmsg_level == TARGET_SOL_SOCKET) &&
  (cmsg->cmsg_type == SCM_RIGHTS)) {
  int *fd = (int *)data;
  int *target_fd = (int *)target_data;
  int i, numfds = len / sizeof(int);

  for (i = 0; i < numfds; i++) {
  fd[i] = tswap32(target_fd[i]);
  }
  } else if ((cmsg->cmsg_level == TARGET_SOL_SOCKET) &&
  (cmsg->cmsg_type == SCM_TIMESTAMP) &&
  (len == sizeof(struct timeval)))  {
  /* copy struct timeval to host */
  struct timeval *tv = (struct timeval *)data;
  struct target_freebsd_timeval *target_tv =
  (struct target_freebsd_timeval *)target_data;
  __get_user(tv->tv_sec, _tv->tv_sec);
  __get_user(tv->tv_usec, _tv->tv_usec);
  } else {
  gemu_log("Unsupported ancillary data: %d/%d\n",
  cmsg->cmsg_level, cmsg->cmsg_type);
  memcpy(data, target_data, len);
  }

Of 3 types of hangups that I've run into recently, one was from a
missing statement, one was from struct target_kevent having the
wrong overall size and wrong field offsets after the first field
(amd64->armv7 was an example), and the one involving struct
target_cmsghdr above. (There may be more to the target_cmsghdr
one.)

> Again, my apology for slightly (or much) chaotic report, but this is the
> best what's I capable.

Not chaotic in my view.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Michal Meloun]

On 29.12.2018 18:47, Dennis Clarke wrote:
> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>
>> On 2018-Dec-28, at 12:12, Mark Millard  wrote:
>>
>>> On 2018-Dec-28, at 05:13, Michal Meloun 
>>> wrote:
>>>
 Mark,
 this is known problem with qemu-user-static.
 Emulation of every single interruptible syscall is broken by design (it
 have signal related races). Theses races cannot be solved without major
 rewrite of syscall emulation code.
 Unfortunately, nobody actively works on this, I think.

> 
> Following along here quietly and I had to blink at this a few times.
> Is there a bug report somewhere within the qemu world related to this
>  'broken by design' qemu feature?

Firstly, I apologize for late answer. Writing a technically accurate but
still comprehensible report is extremely difficult for me.

Major design issue with qemu-user is the fact that guest (blocking /
interruptible) syscalls must be emulated atomically, including
delivering of asynchronous signals (including signals originated by
other thread).
This is something that cannot be emulated precisely by user mode
program, without specific kernel support. Let me explain this in a
little more details.

Assume that we have following trivial code:
void sig_alarm_handler(…)
{
  if (!done) {
do some work;
alarm(10);
  }
}

void foo(void)
{
  install_signal_handler(SIGALARM, sig_alarm_handler);
  alarm(10);
  do some work;
  while (true) {
rv = select(…, NULL);
if (rv == 0)
  do some work;
else if (rv != EINTR)
  Report error end exit;
  }
}

In native environment, this code works well. It calls alarm signal
handler every 10s, irrespective if signal is fired in the program code
or in libc implementation of select() or if program is waiting in kernel
part of select() syscall.

In qemu-user environment, things get significantly harder. Qemu can
deliver signals to guest only on instruction boundary, the guest signal
handler should see emulated CPU context in consistent state. But kernel
can deliver signal to qemu in any time. Due to this, qemu must store
delivered signals into queue and emit these later, when emulator steps
over next instruction boundary.
Assume that qemu just emulates 'syscall' instruction from guest select()
call. Also assume that no other signals (but SIGALARM) are generated,
and socket used in select() never received or transmits any data.

The first version of qemu-user code emulating select() was:
abi_long do_freebsd_select(..)
{
 convert input guest arguments to host;
 rv = select(…);
 convert output host arguments to guest;
 return(rv);
}

But this is very racy. If alarm signal is fired before select(…) enters
kernel, qemu queues it (but does not deliver it to guest because it
isn't on instruction boundary) and continues in emulation. And because
(in our case) select() waits indefinitely, alarm signal is never
delivered to guest and whole program hangs.

Actual qemu code emulating select() looks like:
abi_long do_freebsd_select(..)
{
  convert input guest arguments to host;
  sigfillset();
  sigprocmask(SIG_BLOCK, , );
  if (ts->signal_pending) {
sigprocmask(SIG_SETMASK, , NULL);
   /* We have a signal pending so just poll select() and return. */
   tv2.tv_sec = tv2.tv_usec = 0;
   ret = select(…, , ));
 if (ret == 0)
   ret = TARGET_EINTR;
  } else {
ret = pselect(…, ));
sigprocmask(SIG_SETMASK, , NULL);
  }
  convert output host arguments to guest;
  return(rv);
}

This look a much better. The code blocks all signals first, then checks
if any signal is pending. If yes, then does not-blocking select()
(because timeout is zero) and correctly returns EINTR immediately.
Otherwise, it uses other variant of select(), pselect() which adjusts
right signal mask itself.
That's mean that syscall is called with blocked signal delivery, but
kernel adjusts right sigmask before it waits for event. While this looks
like perfect solution and this code closes all races from first version,
then it doesn't. pselect() uses different semantic that select(), it
doesn't update timeout argument. So this solution is also inappropriate.
Moreover, I think, we don't have p equivalents for all blocking
syscalls.
Mark, I hope that this is also the answer to your question posted to
hackers@ and also the exploitation why you see hang.

Linux uses different approach to overcome this issue, safe_syscall ->
https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4
It looks like workable workaround, but I'm not sure about ERESTART
versus EINTR return values. Imho, this can be problem.

I have list of other qemu-user problems (I mean mainly a bsd-user part
of qemu code here), not counting normal coding bugs:
- code is not thread safety but is used in threaded environment (rw
locks for example),
- emulate  some sysctl's and resource limits / usage behavior is very
hard  (mainly if we emulate 32-bits guest on 64-bits host)
- if host syscall returns 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard]

[I listed my /usr/src svn veriosn information instead of /usr/ports .
Correcting. . .]

On 2018-Dec-31, at 12:05, Mark Millard  wrote:

> On 2018-Dec-31, at 10:16, Jonathan Chen  wrote:
> 
>> On Mon, 31 Dec 2018 at 21:05, Mark Millard  wrote:
>> [...]
>>> But if you have a form of hang-up that shows no sign of being tied
>>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>>> change(s) would fix the issue.
>> 
>> With the __packed-modified qemu-user-static, the amd64->armv7
>> crossbuilds does not hang anymore, but I get build failures instead.
>> Interestingly enough, an unmodified qemu-user-static gets further
>> along in a amd64->armv6 crossbuild, with only one reproducible hang.
> 
> I tend to compare cross-build failures to native-build attempts. The
> multimedia-gstreamer1-qt@qt5 hang-up was qemu-arm-static specific,
> not occurring native. That and being reliable about hanging-up is
> what prompted the investigation.
> 
> The lld thread fanout hangup also has only happened under
> qemu-arm-static but I do not have a context with more than 4 cores for
> armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD
> native) that I use for cross-builds.
> 
> I do not know if you care to but it is possible to see if the FreeBSD
> package builders get failures or hangs for the same ports. I use
> head port build examples below:
> 
> http://beefy16.nyi.freebsd.org/jail.html?mastername=head-armv7-default
> 
> http://beefy8.nyi.freebsd.org/jail.html?mastername=head-armv6-default
> 
> The pages displayed show a list of port version (p??) and freebsd
> version (s??) looking like p??_s?? . Those links take you
> to pages for exploring the built, failed, skipped, and ignored
> ports.
> 
> Of course, for race-condition problems in builds, checking is messier
> because of needing to look at possibly many port/system combinations.
> 
> My attempts to build x11/lumina fail for:
> 
> [00:01:02] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2
> [00:02:23] [01] [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 wrkdir 
> to: 
> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx-1.7.0_2.tar
> [00:02:23] [01] [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: 
> Failed: build
> [00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: 
> Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
> [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-libav | 
> gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | libvpx-1.7.0_2 
> failed
> [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-plugins-core | 
> gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | 
> libvpx-1.7.0_2 failed
> [00:02:24] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: Dependent 
> port multimedia/libvpx | libvpx-1.7.0_2 failed
> [00:02:24] [01] [00:01:22] Skipping x11/lumina-core | lumina-core-1.4.1: 
> Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
> . . .
> [00:06:19] Failed ports: multimedia/libvpx:build
> [00:06:19] Skipped ports: multimedia/ffmpeg multimedia/gstreamer1-libav 
> multimedia/gstreamer1-plugins-core x11/lumina x11/lumina-core
> [FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] Queued: 7  
> Built: 1  Failed: 1  Skipped: 5  Ignored: 0  Tobuild: 0   Time: 00:06:16
> 
> Native build attempts on an armv7 get the same.
> 
> But I'm still at:
> 
> . . .

Correcting to have the /usr/ports  information:

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 484783
Last Changed Rev: 484783


> 
> because I froze at that while investigating the reliable hang and
> have not started progressing again yet. Last I looked the
> head-armv7-default package builds were also failing for libvpx if
> I remember right.

Looks like more recently libvpx builds on the package builders. So next time
that I update the ports tree I'll get to see the next problem (if any).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard]

On 2018-Dec-31, at 10:16, Jonathan Chen  wrote:

> On Mon, 31 Dec 2018 at 21:05, Mark Millard  wrote:
> [...]
>> But if you have a form of hang-up that shows no sign of being tied
>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>> change(s) would fix the issue.
> 
> With the __packed-modified qemu-user-static, the amd64->armv7
> crossbuilds does not hang anymore, but I get build failures instead.
> Interestingly enough, an unmodified qemu-user-static gets further
> along in a amd64->armv6 crossbuild, with only one reproducible hang.

I tend to compare cross-build failures to native-build attempts. The
multimedia-gstreamer1-qt@qt5 hang-up was qemu-arm-static specific,
not occurring native. That and being reliable about hanging-up is
what prompted the investigation.

The lld thread fanout hangup also has only happened under
qemu-arm-static but I do not have a context with more than 4 cores for
armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD
native) that I use for cross-builds.

I do not know if you care to but it is possible to see if the FreeBSD
package builders get failures or hangs for the same ports. I use
head port build examples below:

http://beefy16.nyi.freebsd.org/jail.html?mastername=head-armv7-default

http://beefy8.nyi.freebsd.org/jail.html?mastername=head-armv6-default

The pages displayed show a list of port version (p??) and freebsd
version (s??) looking like p??_s?? . Those links take you
to pages for exploring the built, failed, skipped, and ignored
ports.

Of course, for race-condition problems in builds, checking is messier
because of needing to look at possibly many port/system combinations.

My attempts to build x11/lumina fail for:

[00:01:02] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2
[00:02:23] [01] [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx-1.7.0_2.tar
[00:02:23] [01] [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: Failed: 
build
[00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: Dependent 
port multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-libav | 
gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | libvpx-1.7.0_2 
failed
[00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-plugins-core | 
gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | libvpx-1.7.0_2 
failed
[00:02:24] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: Dependent port 
multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24] [01] [00:01:22] Skipping x11/lumina-core | lumina-core-1.4.1: 
Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
. . .
[00:06:19] Failed ports: multimedia/libvpx:build
[00:06:19] Skipped ports: multimedia/ffmpeg multimedia/gstreamer1-libav 
multimedia/gstreamer1-plugins-core x11/lumina x11/lumina-core
[FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] Queued: 7  
Built: 1  Failed: 1  Skipped: 5  Ignored: 0  Tobuild: 0   Time: 00:06:16

Native build attempts on an armv7 get the same.

But I'm still at:

# svnlite info | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 341836
Last Changed Rev: 341836

because I froze at that while investigating the reliable hang and
have not started progressing again yet. Last I looked the
head-armv7-default package builds were also failing for libvpx if
I remember right.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Jonathan Chen]

On Mon, 31 Dec 2018 at 21:05, Mark Millard  wrote:
[...]
> But if you have a form of hang-up that shows no sign of being tied
> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
> change(s) would fix the issue.

With the __packed-modified qemu-user-static, the amd64->armv7
crossbuilds does not hang anymore, but I get build failures instead.
Interestingly enough, an unmodified qemu-user-static gets further
along in a amd64->armv6 crossbuild, with only one reproducible hang.

Cheers.
-- 
Jonathan Chen 
___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Jonathan Chen]

On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports
 wrote:
>
> [Removing __packed did make the size and offsets match armv7
> and the build worked based on the reconstructed qemu-arm-static.]

Thanks for the analysis Mark! I've been suffering quite a few hangups
with my ports crossbuilds on amd64->armv7 on 12-STABLE, and I'll be
trying your suggestions to see whether it resolves the issue.

Cheers.
-- 
Jonathan Chen 
___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard]

On 2018-Dec-30, at 21:01, Jonathan Chen  wrote:

> On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports
>  wrote:
>> 
>> [Removing __packed did make the size and offsets match armv7
>> and the build worked based on the reconstructed qemu-arm-static.]
> 
> Thanks for the analysis Mark! I've been suffering quite a few hangups
> with my ports crossbuilds on amd64->armv7 on 12-STABLE, and I'll be
> trying your suggestions to see whether it resolves the issue.

If you have something like a kqread state for a hang-up consistently
in the same place, then Mikael Urankar 's fix (or any other
way of getting the right sizes and field offsets for kevent) has a
chance of fixing what you have observed.

But if you have a form of hang-up that shows no sign of being tied
to kevent or hangs-up only sometimes, I'd be surprised if the __packed
change(s) would fix the issue.

I've seen such racy hang-ups from lld's creation of (#cpu)+2 threads,
as FreeBSD counts cpus. I've selectively forced -Wl,--no-threads at
times in specific contexts to avoid that. binutils ld does not tolerate
the option. ports does not appear to have an equivalent of:

LDFLAGS.lld+= -Wl,--no-threads

that would be lld specific.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard]

[Removing __packed did make the size and offsets match armv7
and the build worked based on the reconstructed qemu-arm-static.]

On 2018-Dec-30, at 16:38, Mark Millard  wrote:

> On 2018-Dec-28, at 12:12, Mark Millard  wrote:
> 
>> On 2018-Dec-28, at 05:13, Michal Meloun  wrote:
>> 
>>> Mark,
>>> this is known problem with qemu-user-static.
>>> Emulation of every single interruptible syscall is broken by design (it
>>> have signal related races). Theses races cannot be solved without major
>>> rewrite of syscall emulation code.
>>> Unfortunately, nobody actively works on this, I think.
>>> 
>> 
>> Thanks for the note setting some expectations.
>> . . .
> 
> 
> It turns out that I've been through (part of?) this before and
> mikael.uran...@gmail.com had back then provided a qemu-user-static
> patch (that might have been arm specific or 32-bit target specific
> when running on a 64-bit host). (The qemu-user-static code structure
> seems to have changed some afterwards and the patch is no longer
> where he had pointed me to back then.)
> 
> To show size and offsets on armv7 vs. armd64 for struct kevent
> I use:
> 
> # more kevent_size_offsets.c 
> #include "/usr/include/sys/event.h" // kevent
> #include  // offsetof
> #include   // printf
> 
> int
> main()
> {
>printf("%lu\n", (unsigned long) sizeof(struct kevent));
>printf("ident %lu\n", (unsigned long) offsetof(struct kevent, ident));
>printf("filter %lu\n", (unsigned long) offsetof(struct kevent, 
> filter));
>printf("flags %lu\n", (unsigned long) offsetof(struct kevent, flags));
>printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, 
> fflags));
>printf("data %lu\n", (unsigned long) offsetof(struct kevent, data));
>printf("udata %lu\n", (unsigned long) offsetof(struct kevent, udata));
>printf("ext %lu\n", (unsigned long) offsetof(struct kevent, ext));
>return 0;
> }
> 
> It ends up showing on armv7 (under qemu-arm-static insteead of native, not
> that it matters here):
> 
> # ./a.out
> 64
> ident 0
> filter 4
> flags 6
> fflags 8
> data 16
> udata 24
> ext 32
> 
> On amd64 (native) it ends up as:
> 
> # ./a.out
> 64
> ident 0
> filter 8
> flags 10
> fflags 12
> data 16
> udata 24
> ext 32
> 
> Thus a translation of layout is required when hosted. This is for:
> 
> struct kevent {
>__uintptr_t ident;  /* identifier for this event */
>short   filter; /* filter for event */
>unsigned short  flags;  /* action flags for kqueue */
>unsigned intfflags; /* filter flag value */
>__int64_t   data;   /* filter data value */
>void*udata; /* opaque user data identifier */
>__uint64_t  ext[4]; /* extensions */
> };
> 
> But qemu-user-static has for translation purposes:
> 
> struct target_freebsd_kevent {
>abi_ulong  ident;
>int16_tfilter;
>uint16_t   flags;
>uint32_t   fflags;
>int64_t data;
>abi_ulong  udata;
>uint64_t  ext[4];
> } __packed;
> 
> (note the __packed) for which in amd64's qemu_arm_static has
> the size and offsets:
> 
> # gdb qemu-arm-static
> . . .
> (gdb) p/d sizeof(struct target_freebsd_kevent)
> $1 = 56
> (gdb) p/d &((struct target_freebsd_kevent *)0)->ident
> $2 = 0
> (gdb) p/d &((struct target_freebsd_kevent *)0)->filter
> $3 = 4
> (gdb) p/d &((struct target_freebsd_kevent *)0)->flags
> $4 = 6
> (gdb) p/d &((struct target_freebsd_kevent *)0)->fflags
> $5 = 8
> (gdb) p/d &((struct target_freebsd_kevent *)0)->data
> $6 = 12
> (gdb) p/d &((struct target_freebsd_kevent *)0)->udata
> $7 = 20
> (gdb) p/d &((struct target_freebsd_kevent *)0)->ext
> $8 = 24
> 
> which which does not match the armv7 offsets for
> data, udata, or ext and does not have the right size
> for struct target_freebsd_kevent[] indexing to
> match armv7's struct target_freebsd_kevent[] indexing.
> 
> This in turn makes the do_freebsd_kevent code do the wrong
> thing in its:
> 
>struct target_freebsd_kevent *target_changelist, *target_eventlist;
> . . .
>for (i = 0; i < arg3; i++) {
>__get_user(changelist[i].ident, _changelist[i].ident);
>__get_user(changelist[i].filter, _changelist[i].filter);
>__get_user(changelist[i].flags, _changelist[i].flags);
>__get_user(changelist[i].fflags, _changelist[i].fflags);
>__get_user(changelist[i].data, _changelist[i].data);
>/* __get_user(changelist[i].udata, _changelist[i].udata); */
> #if TARGET_ABI_BITS == 32
>changelist[i].udata = (void 
> *)(uintptr_t)target_changelist[i].udata;
>tswap32s((uint32_t *)[i].udata);
> #else
>changelist[i].udata = (void 
> *)(uintptr_t)target_changelist[i].udata;
>tswap64s((uint64_t *)[i].udata);
> #endif
>__get_user(changelist[i].ext[0], _changelist[i].ext[0]);
>__get_user(changelist[i].ext[1], 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard]

On 2018-Dec-28, at 12:12, Mark Millard  wrote:

> On 2018-Dec-28, at 05:13, Michal Meloun  wrote:
> 
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races). Theses races cannot be solved without major
>> rewrite of syscall emulation code.
>> Unfortunately, nobody actively works on this, I think.
>> 
> 
> Thanks for the note setting some expectations.
> . . .


It turns out that I've been through (part of?) this before and
mikael.uran...@gmail.com had back then provided a qemu-user-static
patch (that might have been arm specific or 32-bit target specific
when running on a 64-bit host). (The qemu-user-static code structure
seems to have changed some afterwards and the patch is no longer
where he had pointed me to back then.)

To show size and offsets on armv7 vs. armd64 for struct kevent
I use:

# more kevent_size_offsets.c 
#include "/usr/include/sys/event.h" // kevent
#include  // offsetof
#include   // printf

int
main()
{
printf("%lu\n", (unsigned long) sizeof(struct kevent));
printf("ident %lu\n", (unsigned long) offsetof(struct kevent, ident));
printf("filter %lu\n", (unsigned long) offsetof(struct kevent, filter));
printf("flags %lu\n", (unsigned long) offsetof(struct kevent, flags));
printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, fflags));
printf("data %lu\n", (unsigned long) offsetof(struct kevent, data));
printf("udata %lu\n", (unsigned long) offsetof(struct kevent, udata));
printf("ext %lu\n", (unsigned long) offsetof(struct kevent, ext));
return 0;
}

It ends up showing on armv7 (under qemu-arm-static insteead of native, not
that it matters here):

# ./a.out
64
ident 0
filter 4
flags 6
fflags 8
data 16
udata 24
ext 32

On amd64 (native) it ends up as:

# ./a.out
64
ident 0
filter 8
flags 10
fflags 12
data 16
udata 24
ext 32

Thus a translation of layout is required when hosted. This is for:

struct kevent {
__uintptr_t ident;  /* identifier for this event */
short   filter; /* filter for event */
unsigned short  flags;  /* action flags for kqueue */
unsigned intfflags; /* filter flag value */
__int64_t   data;   /* filter data value */
void*udata; /* opaque user data identifier */
__uint64_t  ext[4]; /* extensions */
};

But qemu-user-static has for translation purposes:

struct target_freebsd_kevent {
abi_ulong  ident;
int16_tfilter;
uint16_t   flags;
uint32_t   fflags;
int64_t data;
abi_ulong  udata;
uint64_t  ext[4];
} __packed;

(note the __packed) for which in amd64's qemu_arm_static has
the size and offsets:

# gdb qemu-arm-static
. . .
(gdb) p/d sizeof(struct target_freebsd_kevent)
$1 = 56
(gdb) p/d &((struct target_freebsd_kevent *)0)->ident
$2 = 0
(gdb) p/d &((struct target_freebsd_kevent *)0)->filter
$3 = 4
(gdb) p/d &((struct target_freebsd_kevent *)0)->flags
$4 = 6
(gdb) p/d &((struct target_freebsd_kevent *)0)->fflags
$5 = 8
(gdb) p/d &((struct target_freebsd_kevent *)0)->data
$6 = 12
(gdb) p/d &((struct target_freebsd_kevent *)0)->udata
$7 = 20
(gdb) p/d &((struct target_freebsd_kevent *)0)->ext
$8 = 24

which which does not match the armv7 offsets for
data, udata, or ext and does not have the right size
for struct target_freebsd_kevent[] indexing to
match armv7's struct target_freebsd_kevent[] indexing.

This in turn makes the do_freebsd_kevent code do the wrong
thing in its:

struct target_freebsd_kevent *target_changelist, *target_eventlist;
. . .
for (i = 0; i < arg3; i++) {
__get_user(changelist[i].ident, _changelist[i].ident);
__get_user(changelist[i].filter, _changelist[i].filter);
__get_user(changelist[i].flags, _changelist[i].flags);
__get_user(changelist[i].fflags, _changelist[i].fflags);
__get_user(changelist[i].data, _changelist[i].data);
/* __get_user(changelist[i].udata, _changelist[i].udata); */
#if TARGET_ABI_BITS == 32
changelist[i].udata = (void *)(uintptr_t)target_changelist[i].udata;
tswap32s((uint32_t *)[i].udata);
#else
changelist[i].udata = (void *)(uintptr_t)target_changelist[i].udata;
tswap64s((uint64_t *)[i].udata);
#endif
__get_user(changelist[i].ext[0], _changelist[i].ext[0]);
__get_user(changelist[i].ext[1], _changelist[i].ext[1]);
__get_user(changelist[i].ext[2], _changelist[i].ext[2]);
__get_user(changelist[i].ext[3], _changelist[i].ext[3]);
}
. . .
for (i = 0; i < arg5; i++) {
__put_user(eventlist[i].ident, _eventlist[i].ident);
__put_user(eventlist[i].filter, _eventlist[i].filter);
__put_user(eventlist[i].flags, _eventlist[i].flags);

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

On 2018-Dec-28, at 12:12, Mark Millard  wrote:

> On 2018-Dec-28, at 05:13, Michal Meloun  wrote:
> 
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races). Theses races cannot be solved without major
>> rewrite of syscall emulation code.
>> Unfortunately, nobody actively works on this, I think.
>> 
> 
> Thanks for the note setting some expectations.
> 
> On the evidence that I have I expect that more is going on than that:
> 
> A) The hang-up always happens and always in the same place. So
> it would appear that no race is involved.
> 
> B) (A) is true even for varying the number of builders in parallel
> (so other builds also happening) and the number of jobs allowed per
> builder. It also fails for only one builder allowed only one process.
> (I get traces from that last kind of context.)
> 
> C) The problem started on the package-building servers for armv7
> and armv6 without qemu-user-static having an update (FreeBSD and
> cmake had updates, for example).
> 
> D) The problem is only observed for targeting armv7 and armv6 as
> far as I can tell. I've never seen it for aarch64, neither my
> own builds nor when I looked at the package-building server
> history.
> 
> At least that is what got me started. (I've since learned that
> qemu-user-static uses fork in place of a requested vfork.)
> 
> My ktrace/kdump experiment yesterday showed something odd for the
> kevent that hangs in cmake:
> 
> 93172 qemu-arm-static CALL  
> kevent(0x3,0x7ffe7d40,0x2,0x7ffd7d40,0x400,0)
> 93172 qemu-arm-static STRU  struct kevent[] = { { ident=6, 
> filter=EVFILT_READ, flags=0x1, fflags=0, data=0, udata=0x0 }
> { ident=0x0, filter=, flags=0, fflags=0x8, 
> data=0x1, udata=0x0 } }
> 
> Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the struct
> kevent[]. The kevent use is from cmake.
> 
> So far I've not identified a signal being delivered at a time that would seem
> to me to be likely to contribute. (But this is not familiar code so my 
> judgment
> is likely not the best.)
> 
> Note: I normally run FreeBSD using a non-debug kernel, even when using
> head. (The kernel does have symbols.)


The detail of the signal usage involved leading up to the hang-up,
starting from just before the "press return" for the "make FLAVOR=qt5"
command that I had entered:

The only "Interrupted system call" prior to my killing the hung cmake
process was (kdump -H -r -S output):

 93172 100717 qemu-arm-static CALL  execve[59](0x10392,0x8605051a0,0x860cf5400)
 93172 101706 qemu-arm-static RET   nanosleep[240] -1 errno 4 Interrupted 
system call
 93172 100717 qemu-arm-static NAMI  "/bin/sh"
 93172 100717 sh   RET   execve[59] JUSTRETURN
 93172 100717 sh   CALL  readlink[58](0x207a65,0x7fffccc0,0x400)

This is where ninja (via qemu-arm-static) execve's the amd64-native /bin/sh (to
in turn later run cmake via qemu-arm-static). (This was after the fork [for the
requested vfork].) So it is for the close-down of the thread that was in
nanosleep.

There were no PSIG's and no sigreturn's prior to the kill according to the
kdump output.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

[Using ktrace/kdump shows an apperent oddity in the kevent use that
hang-up in cmake, not that I know it causes the hang-up.]

On 2018-Dec-28, at 00:16, Mark Millard  wrote:

> [The historical notes are removed and replaced by partial trace
> information from example hang-ups, not that I've figured out
> what contributes yet.]
> 
> I ran into the following while trying to get evidence
> about the hang-up for an amd64->armv7 cross-build of
> multimedia/gstreamer1-qt@qt5 .
> 
> The following from trying to get evidence for the hang-up
> via a manual run of "make multimedia/gstreamer1-qt FLAVOR=qt5”
> in a poudriere bulk -i’s interactive mode for the context
> that has the hang-up in normal poudriere-devel runs.
> 
> 
> From top after the hang-up (to identify some context):
> 
> 14528 root  2  520   100M24M0 kqread  11   0:00   0.00% 
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
> 14527 root  2  52088M13M0 select  22   0:00   0.00% 
> /usr/local/bin/qemu-arm-static ninja -j1 -v all
> 
> from ps -auxd as well (to identify more context):
> 
> root   101140.0  0.0  10328  1756  1  I+J  13:47   0:00.01 |  
>`-- make FLAVOR=qt5
> root   145260.0  0.0  10204  1792  1  I+J  13:50   0:00.00 |  
>  `-- /bin/sh -e -c (cd 
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
> /usr/bin/env QT_SELE
> root   145270.0  0.0  90304 13084  1  I+J  13:50   0:00.09 |  
>`-- /usr/local/bin/qemu-arm-static ninja -j1 -v all
> root   145280.0  0.0 102876 25060  1  IJ   13:50   0:00.12 |  
>  `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
> cmake_autogen /wrkdirs/usr/ports/multimedia/g
> 
> I had made a qemu-user-static that enabled do_strace when
> it is used to run cmake or ninja.
> 
> The only do_strace lines from qemu-arm-static running cmake
> or ninja mentioning process 14528 are included in the sequence:
> 
> (Before the below was a long list of "14527 fstatat” lines.
> I’ll note that "'Unknown syscall 545” is from ppoll use.)
> 
> 82400 sigprocmask(1,-1610620016,-191968524,-186261416,0,24) = 0
> 82400 sigaction(2,-1610620040,-191968596,-186261584,210460,0) = 0
> 82400 sigaction(15,-1610620040,-191968572,-186261584,210460,0) = 0
> 82400 sigaction(1,-1610620040,-191968548,-186261584,210460,0) = 0
> 82400 gettimeofday(-1610619984,0,4,-186261584,-1610619440,-1610619528) = 0
> 82400 gettimeofday(-1610619984,0,4,359949,1545969996,0) = 0
> 82400 gettimeofday(-1610620120,0,4,2,-184666112,-1610619520) = 0
> 82400 fstatat(-100,"elements/gstqtvideosink/CMakeFiles", 0x9fffe200, 0) = 0
> 82400 fstatat(-100,"elements/gstqtvideosink/gstqt5videosink_autogen", 
> 0x9fffe200, 0) = 0
> 82400 pipe2(-1610620176,0,-1610620108,0,-1610620120,167084) = 0
> 82400 fcntl(5,1,-1610620108,-185863932,-192200556,-1610620228) = 0
> 82400 fcntl(5,2,1,-185863932,-192200556,-1610620228) = 0
> 82400 vfork(0,66450,-186876196,-1610620184,-1610620240,0) = 82401
> 82400 close(6) = 0
> = 0
> 82400 Unknown syscall 545
> 82401 setpgid(0,0,-186876196,-1610620184,-1610620240,0) = 0
> 82401 sigprocmask(3,-191586912,0,-1610620184,-1610620240,0) = 0
> 82401 close(5) = 0
> 82401 open("/dev/null",0,0) = 5
> 82401 dup2(5,0,0,-1610620184,-1610620240,0) = 0
> 82401 close(5) = 0
> 82401 fcntl(0,2,0,-1610620184,-1610620240,0) = 0
> 82401 dup2(6,1,0,-1610620184,-1610620240,0) = 1
> 82401 fcntl(1,2,0,-1610620184,-1610620240,0) = 0
> 82401 dup2(6,2,0,-1610620184,-1610620240,0)82400 
> sigpending(-1610620072,1,0,-191968524,0,0) = 0
> 
> The vfork then close(6) sequence for 82400 vs. the later
> use of 6 in dup2 in 82401 may be rather odd. But it looks
> like qemu-*-static uses do_freebsd_fork to implement
> do_freebsd_vfork, despite reporting vfork before
> calling do_freebsd_vfork. (Does the close(6) appear to
> indicate a race for native operation of ninja for the
> period when the address space is shared?)
> 
> Ninja has Subprocess::Start code that has:
> 
> #ifdef POSIX_SPAWN_USEVFORK
>  flags |= POSIX_SPAWN_USEVFORK;
> #endif
> 
> 
>  if (posix_spawnattr_setflags(, flags) != 0)
>Fatal("posix_spawnattr_setflags: %s", strerror(errno));
> 
>  const char* spawned_args[] = { "/bin/sh", "-c", command.c_str(), NULL };
>  if (posix_spawn(_, "/bin/sh", , ,
>  const_cast(spawned_args), environ) != 0)
>Fatal("posix_spawn: %s", strerror(errno));
> 
> that is in use here. I think that this explains the vfork use.
> 
> 
> It turns out that putting the hung-up build in the background
> and then killing 82401 with the likes of kill -6 leads to more
> output that had apparently been buffered. It shows the use of
> the (amd64 native) /bin/sh that in turn leads to
> /usr/local/bin/cmake via qemu-arm-static. /bin/sh, being
> native, gets no do_strace output from qemu-arm-static.
> 
> 82400 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

On 2018-Dec-28, at 05:13, Michal Meloun  wrote:

> Mark,
> this is known problem with qemu-user-static.
> Emulation of every single interruptible syscall is broken by design (it
> have signal related races). Theses races cannot be solved without major
> rewrite of syscall emulation code.
> Unfortunately, nobody actively works on this, I think.
> 

Thanks for the note setting some expectations.

On the evidence that I have I expect that more is going on than that:

A) The hang-up always happens and always in the same place. So
it would appear that no race is involved.

B) (A) is true even for varying the number of builders in parallel
(so other builds also happening) and the number of jobs allowed per
builder. It also fails for only one builder allowed only one process.
(I get traces from that last kind of context.)

C) The problem started on the package-building servers for armv7
and armv6 without qemu-user-static having an update (FreeBSD and
cmake had updates, for example).

D) The problem is only observed for targeting armv7 and armv6 as
far as I can tell. I've never seen it for aarch64, neither my
own builds nor when I looked at the package-building server
history.

At least that is what got me started. (I've since learned that
qemu-user-static uses fork in place of a requested vfork.)

My ktrace/kdump experiment yesterday showed something odd for the
kevent that hangs in cmake:

93172 qemu-arm-static CALL  
kevent(0x3,0x7ffe7d40,0x2,0x7ffd7d40,0x400,0)
93172 qemu-arm-static STRU  struct kevent[] = { { ident=6, filter=EVFILT_READ, 
flags=0x1, fflags=0, data=0, udata=0x0 }
 { ident=0x0, filter=, flags=0, fflags=0x8, 
data=0x1, udata=0x0 } }

Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the struct
kevent[]. The kevent use is from cmake.

So far I've not identified a signal being delivered at a time that would seem
to me to be likely to contribute. (But this is not familiar code so my judgment
is likely not the best.)

Note: I normally run FreeBSD using a non-debug kernel, even when using
head. (The kernel does have symbols.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Michal Meloun]

On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
> 
> On 2018-Dec-22, at 12:55, Mark Millard  wrote:
> 
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head -r484783 under FreeBSD
>> head -r340287.]
>>
>> On 2018-Dec-22, at 00:10, Mark Millard  wrote:
>>
>>> [I messed up the freebsd-emulation email address the first time I sent
>>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>>
>>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} 
>>> port cross
>>> builds in another message sequence. But it turns out that one thing I ran 
>>> into
>>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a 
>>> separate report
>>> with some updated notes.
>>>
>>> A little context: I had built from ports head -r484783 before under FreeBSD 
>>> head
>>> -r340287 (as I remember the version). Back then it did not have this 
>>> problem that it
>>> now has under FreeBSD head -r341836 . One ports-specific change was to 
>>> force perl5.28
>>> as the default instead of perl5.26 originally. In fact this is what drives 
>>> what is
>>> being rebuilt for my experiment that caught this. But I doubt the perl 
>>> version is
>>> important to the problem. The context has a Ryzen Threadripper 1950X and 
>>> has been
>>> tested both for FreeBSD under Hyper-V and for the same media native-booted. 
>>> Both
>>> hang-up at the same point as seen via ps or top. The native tools for 
>>> cross-build
>>> speedup were in use. Cross-builds targeting aarch64 did not get this 
>>> problem but
>>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for 
>>> the first
>>> armv7 try.
>>>
>>> ADDED: The qemu-user-static back with head -r340287 before installing the
>>> updated ports would likely be different than the -r484783 vintage. So both
>>> FreeBSD and qemu-user-static may have changed over the comparison.
>>
>> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
>> based on qemu-user-static from ports head -484783 --all built under FreeBSD
>> head -r340287 . So the use of the perl5.28 as the forced-default and the
>> newer FreeBSD head version -r341836 as the context are the differences here.
>>
>>> The hang-up:
>>>
>>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up 
>>> and timed
>>> out. Looking during the wait in later tries shows something much like (from 
>>> one of the
>>> examples):
>>>
>>> root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |  
>>>  `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |  
>>>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |  
>>>  `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt 
>>> FLAVOR=qt5 build
>>> root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |  
>>>`-- /bin/sh -e -c (cd 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>>> /usr/bin/env QT_SELE
>>> root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |  
>>>  `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |  
>>>|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>> root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |  
>>>`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>>
>>> or as top showed it:
>>>
>>> 41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
>>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>>> 41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
>>> /bin/sh -e -c (cd 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>>> 41567 root  2  52088M13M0 select   4   0:00   0.00% 
>>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> 41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>> 41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>>
>>> So: 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Michal Meloun]

On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
> 
> On 2018-Dec-22, at 12:55, Mark Millard  wrote:
> 
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head -r484783 under FreeBSD
>> head -r340287.]
>>
>> On 2018-Dec-22, at 00:10, Mark Millard  wrote:
>>
>>> [I messed up the freebsd-emulation email address the first time I sent
>>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>>
>>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} 
>>> port cross
>>> builds in another message sequence. But it turns out that one thing I ran 
>>> into
>>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a 
>>> separate report
>>> with some updated notes.
>>>
>>> A little context: I had built from ports head -r484783 before under FreeBSD 
>>> head
>>> -r340287 (as I remember the version). Back then it did not have this 
>>> problem that it
>>> now has under FreeBSD head -r341836 . One ports-specific change was to 
>>> force perl5.28
>>> as the default instead of perl5.26 originally. In fact this is what drives 
>>> what is
>>> being rebuilt for my experiment that caught this. But I doubt the perl 
>>> version is
>>> important to the problem. The context has a Ryzen Threadripper 1950X and 
>>> has been
>>> tested both for FreeBSD under Hyper-V and for the same media native-booted. 
>>> Both
>>> hang-up at the same point as seen via ps or top. The native tools for 
>>> cross-build
>>> speedup were in use. Cross-builds targeting aarch64 did not get this 
>>> problem but
>>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for 
>>> the first
>>> armv7 try.
>>>
>>> ADDED: The qemu-user-static back with head -r340287 before installing the
>>> updated ports would likely be different than the -r484783 vintage. So both
>>> FreeBSD and qemu-user-static may have changed over the comparison.
>>
>> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
>> based on qemu-user-static from ports head -484783 --all built under FreeBSD
>> head -r340287 . So the use of the perl5.28 as the forced-default and the
>> newer FreeBSD head version -r341836 as the context are the differences here.
>>
>>> The hang-up:
>>>
>>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up 
>>> and timed
>>> out. Looking during the wait in later tries shows something much like (from 
>>> one of the
>>> examples):
>>>
>>> root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |  
>>>  `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |  
>>>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |  
>>>  `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt 
>>> FLAVOR=qt5 build
>>> root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |  
>>>`-- /bin/sh -e -c (cd 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>>> /usr/bin/env QT_SELE
>>> root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |  
>>>  `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |  
>>>|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>> root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |  
>>>`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>>
>>> or as top showed it:
>>>
>>> 41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
>>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>>> 41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
>>> /bin/sh -e -c (cd 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>>> 41567 root  2  52088M13M0 select   4   0:00   0.00% 
>>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> 41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>> 41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>>
>>> So: 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

[The historical notes are removed and replaced by partial trace
information from example hang-ups, not that I've figured out
what contributes yet.]

I ran into the following while trying to get evidence
about the hang-up for an amd64->armv7 cross-build of
multimedia/gstreamer1-qt@qt5 .

The following from trying to get evidence for the hang-up
via a manual run of "make multimedia/gstreamer1-qt FLAVOR=qt5”
in a poudriere bulk -i’s interactive mode for the context
that has the hang-up in normal poudriere-devel runs.


From top after the hang-up (to identify some context):

14528 root  2  520   100M24M0 kqread  11   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
14527 root  2  52088M13M0 select  22   0:00   0.00% 
/usr/local/bin/qemu-arm-static ninja -j1 -v all

from ps -auxd as well (to identify more context):

root   101140.0  0.0  10328  1756  1  I+J  13:47   0:00.01 |
 `-- make FLAVOR=qt5
root   145260.0  0.0  10204  1792  1  I+J  13:50   0:00.00 |
   `-- /bin/sh -e -c (cd 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env 
QT_SELE
root   145270.0  0.0  90304 13084  1  I+J  13:50   0:00.09 |
 `-- /usr/local/bin/qemu-arm-static ninja -j1 -v all
root   145280.0  0.0 102876 25060  1  IJ   13:50   0:00.12 |
   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g

I had made a qemu-user-static that enabled do_strace when
it is used to run cmake or ninja.

The only do_strace lines from qemu-arm-static running cmake
or ninja mentioning process 14528 are included in the sequence:

(Before the below was a long list of "14527 fstatat” lines.
I’ll note that "'Unknown syscall 545” is from ppoll use.)

82400 sigprocmask(1,-1610620016,-191968524,-186261416,0,24) = 0
82400 sigaction(2,-1610620040,-191968596,-186261584,210460,0) = 0
82400 sigaction(15,-1610620040,-191968572,-186261584,210460,0) = 0
82400 sigaction(1,-1610620040,-191968548,-186261584,210460,0) = 0
82400 gettimeofday(-1610619984,0,4,-186261584,-1610619440,-1610619528) = 0
82400 gettimeofday(-1610619984,0,4,359949,1545969996,0) = 0
82400 gettimeofday(-1610620120,0,4,2,-184666112,-1610619520) = 0
82400 fstatat(-100,"elements/gstqtvideosink/CMakeFiles", 0x9fffe200, 0) = 0
82400 fstatat(-100,"elements/gstqtvideosink/gstqt5videosink_autogen", 
0x9fffe200, 0) = 0
82400 pipe2(-1610620176,0,-1610620108,0,-1610620120,167084) = 0
82400 fcntl(5,1,-1610620108,-185863932,-192200556,-1610620228) = 0
82400 fcntl(5,2,1,-185863932,-192200556,-1610620228) = 0
82400 vfork(0,66450,-186876196,-1610620184,-1610620240,0) = 82401
82400 close(6) = 0
 = 0
82400 Unknown syscall 545
82401 setpgid(0,0,-186876196,-1610620184,-1610620240,0) = 0
82401 sigprocmask(3,-191586912,0,-1610620184,-1610620240,0) = 0
82401 close(5) = 0
82401 open("/dev/null",0,0) = 5
82401 dup2(5,0,0,-1610620184,-1610620240,0) = 0
82401 close(5) = 0
82401 fcntl(0,2,0,-1610620184,-1610620240,0) = 0
82401 dup2(6,1,0,-1610620184,-1610620240,0) = 1
82401 fcntl(1,2,0,-1610620184,-1610620240,0) = 0
82401 dup2(6,2,0,-1610620184,-1610620240,0)82400 
sigpending(-1610620072,1,0,-191968524,0,0) = 0

The vfork then close(6) sequence for 82400 vs. the later
use of 6 in dup2 in 82401 may be rather odd. But it looks
like qemu-*-static uses do_freebsd_fork to implement
do_freebsd_vfork, despite reporting vfork before
calling do_freebsd_vfork. (Does the close(6) appear to
indicate a race for native operation of ninja for the
period when the address space is shared?)

Ninja has Subprocess::Start code that has:

#ifdef POSIX_SPAWN_USEVFORK
  flags |= POSIX_SPAWN_USEVFORK;
#endif


  if (posix_spawnattr_setflags(, flags) != 0)
Fatal("posix_spawnattr_setflags: %s", strerror(errno));

  const char* spawned_args[] = { "/bin/sh", "-c", command.c_str(), NULL };
  if (posix_spawn(_, "/bin/sh", , ,
  const_cast(spawned_args), environ) != 0)
Fatal("posix_spawn: %s", strerror(errno));

that is in use here. I think that this explains the vfork use.


It turns out that putting the hung-up build in the background
and then killing 82401 with the likes of kill -6 leads to more
output that had apparently been buffered. It shows the use of
the (amd64 native) /bin/sh that in turn leads to
/usr/local/bin/cmake via qemu-arm-static. /bin/sh, being
native, gets no do_strace output from qemu-arm-static.

82400 sigpending(-1610620072,1,0,-191968524,0,0) = 0
82400 read(5,0x9fffd368,4096) = 58
82400 Unknown syscall 545
82400 sigpending(-1610620072,1,0,-191968524,0,0) = 0
82400 read(5,0x9fffd368,4096) = 0
82400 close(5) = 0
82400 wait4(82401,-1610620004,0,0,-191968640,0) = 82401
82400 mmap(0,86016,3,201330690,-1,-1610620169) = 0xf4777000
82400 gettimeofday(-1610620224,0,4,-1610619944,31,16777216) = 0

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

[A native poudreire-devel based build of
multimedia/gstreamer1-qt@qt5 did not hang-up
and worked fine. Official package build history
also provides some evidence.]

On 2018-Dec-22, at 12:55, Mark Millard  wrote:

> [I found my E-mail records reporting successful builds using
> qemu-user-static from ports head -r484783 under FreeBSD
> head -r340287.]
> 
> On 2018-Dec-22, at 00:10, Mark Millard  wrote:
> 
>> [I messed up the freebsd-emulation email address the first time I sent
>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>> 
>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} 
>> port cross
>> builds in another message sequence. But it turns out that one thing I ran 
>> into
>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a 
>> separate report
>> with some updated notes.
>> 
>> A little context: I had built from ports head -r484783 before under FreeBSD 
>> head
>> -r340287 (as I remember the version). Back then it did not have this problem 
>> that it
>> now has under FreeBSD head -r341836 . One ports-specific change was to force 
>> perl5.28
>> as the default instead of perl5.26 originally. In fact this is what drives 
>> what is
>> being rebuilt for my experiment that caught this. But I doubt the perl 
>> version is
>> important to the problem. The context has a Ryzen Threadripper 1950X and has 
>> been
>> tested both for FreeBSD under Hyper-V and for the same media native-booted. 
>> Both
>> hang-up at the same point as seen via ps or top. The native tools for 
>> cross-build
>> speedup were in use. Cross-builds targeting aarch64 did not get this problem 
>> but
>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the 
>> first
>> armv7 try.
>> 
>> ADDED: The qemu-user-static back with head -r340287 before installing the
>> updated ports would likely be different than the -r484783 vintage. So both
>> FreeBSD and qemu-user-static may have changed over the comparison.
> 
> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
> based on qemu-user-static from ports head -484783 --all built under FreeBSD
> head -r340287 . So the use of the perl5.28 as the forced-default and the
> newer FreeBSD head version -r341836 as the context are the differences here.
> 
>> The hang-up:
>> 
>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up 
>> and timed
>> out. Looking during the wait in later tries shows something much like (from 
>> one of the
>> examples):
>> 
>> root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |   
>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>> (gstreamer1-qt5-1.2.0_14) (sh)
>> root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |   
>>   `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>> (gstreamer1-qt5-1.2.0_14) (sh)
>> root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |   
>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt 
>> FLAVOR=qt5 build
>> root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |   
>>   `-- /bin/sh -e -c (cd 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>> /usr/bin/env QT_SELE
>> root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |   
>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>> root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |   
>>   |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
>> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>> root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |   
>>   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
>> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>> 
>> or as top showed it:
>> 
>> 41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>> 41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
>> /bin/sh -e -c (cd 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>> 41567 root  2  52088M13M0 select   4   0:00   0.00% 
>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>> 41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>> 41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>> 
>> So: waiting in kqread trying to run cmake.
>> 
>> Unlike some intermittent 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

[I built a FreeBSD head -r340288 context and tried ports head
-r484783 and the problem repeated.]

On 2018-Dec-22, at 12:55, Mark Millard  wrote:

> [I found my E-mail records reporting successful builds using
> qemu-user-static from ports head -r484783 under FreeBSD
> head -r340287.]
> 
> On 2018-Dec-22, at 00:10, Mark Millard  wrote:
> 
>> [I messed up the freebsd-emulation email address the first time I sent
>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>> 
>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} 
>> port cross
>> builds in another message sequence. But it turns out that one thing I ran 
>> into
>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a 
>> separate report
>> with some updated notes.
>> 
>> A little context: I had built from ports head -r484783 before under FreeBSD 
>> head
>> -r340287 (as I remember the version). Back then it did not have this problem 
>> that it
>> now has under FreeBSD head -r341836 . One ports-specific change was to force 
>> perl5.28
>> as the default instead of perl5.26 originally. In fact this is what drives 
>> what is
>> being rebuilt for my experiment that caught this. But I doubt the perl 
>> version is
>> important to the problem. The context has a Ryzen Threadripper 1950X and has 
>> been
>> tested both for FreeBSD under Hyper-V and for the same media native-booted. 
>> Both
>> hang-up at the same point as seen via ps or top. The native tools for 
>> cross-build
>> speedup were in use. Cross-builds targeting aarch64 did not get this problem 
>> but
>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the 
>> first
>> armv7 try.
>> 
>> ADDED: The qemu-user-static back with head -r340287 before installing the
>> updated ports would likely be different than the -r484783 vintage. So both
>> FreeBSD and qemu-user-static may have changed over the comparison.
> 
> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
> based on qemu-user-static from ports head -484783 --all built under FreeBSD
> head -r340287 . So the use of the perl5.28 as the forced-default and the
> newer FreeBSD head version -r341836 as the context are the differences here.
> 
>> The hang-up:
>> 
>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up 
>> and timed
>> out. Looking during the wait in later tries shows something much like (from 
>> one of the
>> examples):
>> 
>> root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |   
>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>> (gstreamer1-qt5-1.2.0_14) (sh)
>> root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |   
>>   `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
>> (gstreamer1-qt5-1.2.0_14) (sh)
>> root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |   
>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt 
>> FLAVOR=qt5 build
>> root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |   
>>   `-- /bin/sh -e -c (cd 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>> /usr/bin/env QT_SELE
>> root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |   
>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>> root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |   
>>   |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
>> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>> root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |   
>>   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
>> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>> 
>> or as top showed it:
>> 
>> 41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>> 41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
>> /bin/sh -e -c (cd 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>> 41567 root  2  52088M13M0 select   4   0:00   0.00% 
>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>> 41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>> 41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>> 
>> So: waiting in kqread trying to run cmake.
>> 
>> Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not
>> resume the 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

[I found my E-mail records reporting successful builds using
qemu-user-static from ports head -r484783 under FreeBSD
head -r340287.]

On 2018-Dec-22, at 00:10, Mark Millard  wrote:

> [I messed up the freebsd-emulation email address the first time I sent
> this. I also forgot to indicate the qemu-user-static vintage relationship.]
> 
> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port 
> cross
> builds in another message sequence. But it turns out that one thing I ran into
> has hung-up every time, the same way, for amd64->armv7 cross builds:
> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate 
> report
> with some updated notes.
> 
> A little context: I had built from ports head -r484783 before under FreeBSD 
> head
> -r340287 (as I remember the version). Back then it did not have this problem 
> that it
> now has under FreeBSD head -r341836 . One ports-specific change was to force 
> perl5.28
> as the default instead of perl5.26 originally. In fact this is what drives 
> what is
> being rebuilt for my experiment that caught this. But I doubt the perl 
> version is
> important to the problem. The context has a Ryzen Threadripper 1950X and has 
> been
> tested both for FreeBSD under Hyper-V and for the same media native-booted. 
> Both
> hang-up at the same point as seen via ps or top. The native tools for 
> cross-build
> speedup were in use. Cross-builds targeting aarch64 did not get this problem 
> but
> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the 
> first
> armv7 try.
> 
> ADDED: The qemu-user-static back with head -r340287 before installing the
> updated ports would likely be different than the -r484783 vintage. So both
> FreeBSD and qemu-user-static may have changed over the comparison.

CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
based on qemu-user-static from ports head -484783 --all built under FreeBSD
head -r340287 . So the use of the perl5.28 as the forced-default and the
newer FreeBSD head version -r341836 as the context are the differences here.

> The hang-up:
> 
> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up 
> and timed
> out. Looking during the wait in later tries shows something much like (from 
> one of the
> examples):
> 
> root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |
>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
> (gstreamer1-qt5-1.2.0_14) (sh)
> root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |
>  `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
> (gstreamer1-qt5-1.2.0_14) (sh)
> root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |
>`-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt 
> FLAVOR=qt5 build
> root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |
>  `-- /bin/sh -e -c (cd 
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
> /usr/bin/env QT_SELE
> root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |
>`-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
> root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |
>  |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
> cmake_autogen /wrkdirs/usr/ports/multimedia/g
> root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |
>  `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
> cmake_autogen /wrkdirs/usr/ports/multimedia/g
> 
> or as top showed it:
> 
> 41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
> 41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
> /bin/sh -e -c (cd 
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! 
> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
> 41567 root  2  52088M13M0 select   4   0:00   0.00% 
> /usr/local/bin/qemu-arm-static ninja -j28 -v all
> 41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
> 41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
> 
> So: waiting in kqread trying to run cmake.
> 
> Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not
> resume the hung-up processes. Kills of the processes waiting on kqread stop
> the build.
> 
> Given the prior ports have been built already, building just
> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point.
> 
> Building anything that requires 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

[I messed up the freebsd-emulation email address the first time I sent
this. I also forgot to indicate the qemu-user-static vintage relationship.]

I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port 
cross
builds in another message sequence. But it turns out that one thing I ran into
has hung-up every time, the same way, for amd64->armv7 cross builds:
multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate 
report
with some updated notes.

A little context: I had built from ports head -r484783 before under FreeBSD head
-r340287 (as I remember the version). Back then it did not have this problem 
that it
now has under FreeBSD head -r341836 . One ports-specific change was to force 
perl5.28
as the default instead of perl5.26 originally. In fact this is what drives what 
is
being rebuilt for my experiment that caught this. But I doubt the perl version 
is
important to the problem. The context has a Ryzen Threadripper 1950X and has 
been
tested both for FreeBSD under Hyper-V and for the same media native-booted. Both
hang-up at the same point as seen via ps or top. The native tools for 
cross-build
speedup were in use. Cross-builds targeting aarch64 did not get this problem but
targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the 
first
armv7 try.

ADDED: The qemu-user-static back with head -r340287 before installing the
updated ports would likely be different than the -r484783 vintage. So both
FreeBSD and qemu-user-static may have changed over the comparison.


The hang-up:

In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up and 
timed
out. Looking during the wait in later tries shows something much like (from one 
of the
examples):

root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |  
 `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
(gstreamer1-qt5-1.2.0_14) (sh)
root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |  
   `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
(gstreamer1-qt5-1.2.0_14) (sh)
root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |  
 `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 
build
root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |  
   `-- /bin/sh -e -c (cd 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env 
QT_SELE
root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |  
 `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |  
   |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g
root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |  
   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g

or as top showed it:

41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
/usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
/bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; 
if ! /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
41567 root  2  52088M13M0 select   4   0:00   0.00% 
/usr/local/bin/qemu-arm-static ninja -j28 -v all
41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.

So: waiting in kqread trying to run cmake.

Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not
resume the hung-up processes. Kills of the processes waiting on kqread stop
the build.

Given the prior ports have been built already, building just
multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point.

Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be
solidly blocked in my environment.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard]

I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port 
cross
builds in another message sequence. But it turns out that one thing I ran into
has hung-up every time, the same way, for amd64->armv7 cross builds:
multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate 
report
with some updated notes.

A little context: I had built from ports head -r484783 before under FreeBSD head
-r340287 (as I remember the version). Back then it did not have this problem 
that it
now has under FreeBSD head -r341836 . One ports-specific change was to force 
perl5.28
as the default instead of perl5.26 originally. In fact this is what drives what 
is
being rebuilt for my experiment that caught this. But I doubt the perl version 
is
important to the problem. The context has a Ryzen Threadripper 1950X and has 
been
tested both for FreeBSD under Hyper-V and for the same media native-booted. Both
hang-up at the same point as seen via ps or top. The native tools for 
cross-build
speedup were in use. Cross-builds targeting aarch64 did not get this problem but
targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the 
first
armv7 try.


The hang-up:

In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up and 
timed
out. Looking during the wait in later tries shows something much like (from one 
of the
examples):

root   337190.0  0.0  12920  3528  0  I11:40   0:00.03 | |  
 `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
(gstreamer1-qt5-1.2.0_14) (sh)
root   415510.0  0.0  12920  3520  0  I11:43   0:00.00 | |  
   `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg 
(gstreamer1-qt5-1.2.0_14) (sh)
root   415520.0  0.0  10340  1744  0  IJ   11:43   0:00.01 | |  
 `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 
build
root   415660.0  0.0  10236  1796  0  IJ   11:43   0:00.00 | |  
   `-- /bin/sh -e -c (cd 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env 
QT_SELE
root   415670.0  0.0  89976 12896  0  IJ   11:43   0:00.07 | |  
 `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
root   415850.0  0.0 102848 25056  0  IJ   11:43   0:00.10 | |  
   |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g
root   415860.0  0.0 102852 25072  0  IJ   11:43   0:00.11 | |  
   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/multimedia/g

or as top showed it:

41552 root  1  52010M  1744K0 wait15   0:00   0.00% 
/usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
41566 root  1  52010M  1796K0 wait 1   0:00   0.00% 
/bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; 
if ! /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
41567 root  2  52088M13M0 select   4   0:00   0.00% 
/usr/local/bin/qemu-arm-static ninja -j28 -v all
41585 root  2  520   100M24M0 kqread   8   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
41586 root  2  520   100M24M0 kqread  22   0:00   0.00% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.

So: waiting in kqread trying to run cmake.

Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not
resume the hung-up processes. Kills of the processes waiting on kqread stop
the build.

Given the prior ports have been built already, building just
multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point.

Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be
solidly blocked in my environment.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: -current build failure after SVN r340130

[Michael Butler]

Confirmed to be fixed by SVN r340134 - thanks!

On 11/4/18 1:50 PM, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
> error: all paths through this function will call itself
> [-Werror,-Winfinite-recursion]
> {
> ^
> 1 error generated.
> *** [dma-mbox-create.o] Error code 1
> 
> make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
> 
> The broken function seems to call itself .. ??
> 
> static __inline int
> caph_fcntls_limit(int fd, uint32_t fcntlrights)
> {
> 
> if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
> return (-1);
> 
> return (0);
> }
> 
> ___
> 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"
> 

___
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: -current build failure after SVN r340130

[Mariusz Zaborski]

On Sun, Nov 04, 2018 at 01:50:31PM -0500, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
> error: all paths through this function will call itself
> [-Werror,-Winfinite-recursion]
> {
> ^
> 1 error generated.
> *** [dma-mbox-create.o] Error code 1
> 
> make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
> 
> The broken function seems to call itself .. ??
> 
> static __inline int
> caph_fcntls_limit(int fd, uint32_t fcntlrights)
> {
> 
> if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
> return (-1);
> 
> return (0);
> }
Sorry, for that just fixed.

Thanks,
-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD committer   | https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

-current build failure after SVN r340130

[Michael Butler]

===> libexec/dma/dma-mbox-create (all)
Building
/usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
error: all paths through this function will call itself
[-Werror,-Winfinite-recursion]
{
^
1 error generated.
*** [dma-mbox-create.o] Error code 1

make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create

The broken function seems to call itself .. ??

static __inline int
caph_fcntls_limit(int fd, uint32_t fcntlrights)
{

if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
return (-1);

return (0);
}

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

[John Baldwin]

On 8/14/18 1:35 AM, Matthew Macy wrote:
> On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem  wrote:
> 
>> Rodney W. Grimes wrote:
 On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:

> Sorry guys, last time I touched ZFS I tried to push to make it an
>> option to
> statically link and was actually told that it wasn't something anyone
>> else
> wanted. The issue comes from ZFS not being in NOTES and thus not in
>> LINT.

 If consensus is that "options ZFS" is no longer valid, then maybe
 UPDATING should reflect the fact.

 I can live with loading zfs.ko and opensolaris.ko at boot time, but I
 think this is a step backwards.
>>>
>>> Please no, I can think of no sound reason that you should be
>>> forced to use modules.
>> I thought that ZFS was required to be a module because of the licensing
>> terms (they didn't want any CDDL code in the core kernel)?
>>
> 
> It can't be in _GENERIC_ for that reason. There's no reason it can't be in
> LINT or end users can't configure a CDDL tainted kernel.

It should definitely be in sys/conf/NOTES.  That may have just been oversight
of whoever finally fixed 'options ZFS' to work.

-- 
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: non-SMP i386 build failure after SVN r337715

[Mark Johnston]

On Mon, Aug 13, 2018 at 09:53:22PM -0400, Michael Butler wrote:
> non-SMP builds apparently don't define some required structures ..

Thanks, this should be fixed by r337751.
___
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 failure

[Rodney W. Grimes]

[ Charset ISO-8859-1 unsupported, converting... ]
> Rodney W. Grimes wrote:
> >> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> >>
> >> > Sorry guys, last time I touched ZFS I tried to push to make it an option 
> >> > to
> >> > statically link and was actually told that it wasn't something anyone 
> >> > else
> >> > wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
> >>
> >> If consensus is that "options ZFS" is no longer valid, then maybe
> >> UPDATING should reflect the fact.

The consensus here should be that options ZFS is totally valid.

> >> I can live with loading zfs.ko and opensolaris.ko at boot time, but I
> >> think this is a step backwards.
> >
> >Please no, I can think of no sound reason that you should be
> >forced to use modules.
> I thought that ZFS was required to be a module because of the licensing
> terms (they didn't want any CDDL code in the core kernel)?

I am not asking that we distribute a statically linked kernel,
that does create an issue for a GPL kernel, but not for a BSD kernel,
I am asking that we continue to be able to statically link ZFS
into the kernel as we have been able to for some time.

For a very short period of time due to mmacy commit this was
broken, he quickly fixed it, so this is a moot issue again.


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

non-SMP i386 build failure after SVN r337715

[Michael Butler]

non-SMP builds apparently don't define some required structures ..

--- kernel ---
linking kernel
ld: error: undefined symbol: cpu_info
>>> referenced by ucode.c
>>>   ucode.o:(ucode_load_ap)
ld: error: undefined symbol: cpu_apic_ids
>>> referenced by ucode.c
>>>   ucode.o:(ucode_load_ap)
ld: error: undefined symbol: cpu_info
>>> referenced by ucode.c
>>>   ucode.o:(ucode_reload)
ld: error: undefined symbol: cpu_apic_ids
>>> referenced by ucode.c
>>>   ucode.o:(ucode_reload)
*** [kernel] Error code 1

imb
___
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 failure

[Matthew Macy]

On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem  wrote:

> Rodney W. Grimes wrote:
> >> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> >>
> >> > Sorry guys, last time I touched ZFS I tried to push to make it an
> option to
> >> > statically link and was actually told that it wasn't something anyone
> else
> >> > wanted. The issue comes from ZFS not being in NOTES and thus not in
> LINT.
> >>
> >> If consensus is that "options ZFS" is no longer valid, then maybe
> >> UPDATING should reflect the fact.
> >>
> >> I can live with loading zfs.ko and opensolaris.ko at boot time, but I
> >> think this is a step backwards.
> >
> >Please no, I can think of no sound reason that you should be
> >forced to use modules.
> I thought that ZFS was required to be a module because of the licensing
> terms (they didn't want any CDDL code in the core kernel)?
>

It can't be in _GENERIC_ for that reason. There's no reason it can't be in
LINT or end users can't configure a CDDL tainted kernel.
-M




> rick
>
>
___
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 failure

[Rick Macklem]

Rodney W. Grimes wrote:
>> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
>>
>> > Sorry guys, last time I touched ZFS I tried to push to make it an option to
>> > statically link and was actually told that it wasn't something anyone else
>> > wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
>>
>> If consensus is that "options ZFS" is no longer valid, then maybe
>> UPDATING should reflect the fact.
>>
>> I can live with loading zfs.ko and opensolaris.ko at boot time, but I
>> think this is a step backwards.
>
>Please no, I can think of no sound reason that you should be
>forced to use modules.
I thought that ZFS was required to be a module because of the licensing
terms (they didn't want any CDDL code in the core kernel)?

rick

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

[Yuri Pankov]

Rodney W. Grimes wrote:

On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:


Sorry guys, last time I touched ZFS I tried to push to make it an option to
statically link and was actually told that it wasn't something anyone else
wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.


If consensus is that "options ZFS" is no longer valid, then maybe
UPDATING should reflect the fact.

I can live with loading zfs.ko and opensolaris.ko at boot time, but I
think this is a step backwards.


Please no, I can think of no sound reason that you should be
forced to use modules.


Isn't it already fixed in r337690?
___
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 failure

[Rodney W. Grimes]

> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> 
> > Sorry guys, last time I touched ZFS I tried to push to make it an option to
> > statically link and was actually told that it wasn't something anyone else
> > wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
> 
> If consensus is that "options ZFS" is no longer valid, then maybe 
> UPDATING should reflect the fact.
> 
> I can live with loading zfs.ko and opensolaris.ko at boot time, but I 
> think this is a step backwards.

Please no, I can think of no sound reason that you should be
forced to use modules.  

-- 
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 failure

[Trond Endrestøl]

On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:

> Sorry guys, last time I touched ZFS I tried to push to make it an option to
> statically link and was actually told that it wasn't something anyone else
> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.

If consensus is that "options ZFS" is no longer valid, then maybe 
UPDATING should reflect the fact.

I can live with loading zfs.ko and opensolaris.ko at boot time, but I 
think this is a step backwards.

-- 
Trond.
___
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 failure

[Warner Losh]

On Sun, Aug 12, 2018, 4:27 PM Matthew Macy  wrote:

>
>
> On Sun, Aug 12, 2018 at 3:25 PM Warner Losh  wrote:
>
>>
>>
>> On Sun, Aug 12, 2018, 3:40 PM Matthew Macy  wrote:
>>
>>> Sorry guys, last time I touched ZFS I tried to push to make it an option
>>> to
>>> statically link and was actually told that it wasn't something anyone
>>> else
>>> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
>>>
>>
>> LINT is generated from NOTES automatically...
>>
>
> Yes, hence the "and thus not in LINT"
>

I missed one of the nots :(

Warner


>
>> Warner
>>
>> -M
>>>
>>> On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl <
>>> trond.endres...@fagskolen.gjovik.no> wrote:
>>>
>>> > On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
>>> >
>>> > > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
>>> > >
>>> > > > Is anyone else seeing this when building a new kernel with ZFS
>>> > compiled in?
>>> > > >
>>> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
>>> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
>>> > > > --- kernel ---
>>> > > > linking kernel
>>> > > > ld: error: undefined symbol: dbuf_stats_init
>>> > > > >>> referenced by dbuf.c
>>> > > > >>>   dbuf.o:(dbuf_init)
>>> > > >
>>> > > > ld: error: undefined symbol: dbuf_stats_destroy
>>> > > > >>> referenced by dbuf.c
>>> > > > >>>   dbuf.o:(dbuf_fini)
>>> > > > *** [kernel] Error code 1
>>> > >
>>> > > I was just about to create a thread of my own.
>>> > >
>>> > > I suspect r337670 didn't add everything
>>> > > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See
>>> > > lines 652 and 697.
>>> > >
>>> > > Meanwhile, I'll attempt to revert to r337669.
>>> >
>>> > r337669 builds and runs.
>>> >
>>> > Looking further into r337670, it seems
>>> > cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes
>>> > for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation
>>> > can be found in any of the files affected by r337670.
>>> >
>>> > --
>>> > Trond.
>>> ___
>>> 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"
>>>
>>
___
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 failure

[Matthew Macy]

On Sun, Aug 12, 2018 at 3:25 PM Warner Losh  wrote:

>
>
> On Sun, Aug 12, 2018, 3:40 PM Matthew Macy  wrote:
>
>> Sorry guys, last time I touched ZFS I tried to push to make it an option
>> to
>> statically link and was actually told that it wasn't something anyone else
>> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
>>
>
> LINT is generated from NOTES automatically...
>

Yes, hence the "and thus not in LINT"




> Warner
>
> -M
>>
>> On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl <
>> trond.endres...@fagskolen.gjovik.no> wrote:
>>
>> > On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
>> >
>> > > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
>> > >
>> > > > Is anyone else seeing this when building a new kernel with ZFS
>> > compiled in?
>> > > >
>> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
>> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
>> > > > --- kernel ---
>> > > > linking kernel
>> > > > ld: error: undefined symbol: dbuf_stats_init
>> > > > >>> referenced by dbuf.c
>> > > > >>>   dbuf.o:(dbuf_init)
>> > > >
>> > > > ld: error: undefined symbol: dbuf_stats_destroy
>> > > > >>> referenced by dbuf.c
>> > > > >>>   dbuf.o:(dbuf_fini)
>> > > > *** [kernel] Error code 1
>> > >
>> > > I was just about to create a thread of my own.
>> > >
>> > > I suspect r337670 didn't add everything
>> > > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See
>> > > lines 652 and 697.
>> > >
>> > > Meanwhile, I'll attempt to revert to r337669.
>> >
>> > r337669 builds and runs.
>> >
>> > Looking further into r337670, it seems
>> > cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes
>> > for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation
>> > can be found in any of the files affected by r337670.
>> >
>> > --
>> > Trond.
>> ___
>> 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
>> "
>>
>
___
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 failure

[Warner Losh]

On Sun, Aug 12, 2018, 3:40 PM Matthew Macy  wrote:

> Sorry guys, last time I touched ZFS I tried to push to make it an option to
> statically link and was actually told that it wasn't something anyone else
> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
>

LINT is generated from NOTES automatically...

Warner

-M
>
> On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl <
> trond.endres...@fagskolen.gjovik.no> wrote:
>
> > On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
> >
> > > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
> > >
> > > > Is anyone else seeing this when building a new kernel with ZFS
> > compiled in?
> > > >
> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
> > > > --- kernel ---
> > > > linking kernel
> > > > ld: error: undefined symbol: dbuf_stats_init
> > > > >>> referenced by dbuf.c
> > > > >>>   dbuf.o:(dbuf_init)
> > > >
> > > > ld: error: undefined symbol: dbuf_stats_destroy
> > > > >>> referenced by dbuf.c
> > > > >>>   dbuf.o:(dbuf_fini)
> > > > *** [kernel] Error code 1
> > >
> > > I was just about to create a thread of my own.
> > >
> > > I suspect r337670 didn't add everything
> > > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See
> > > lines 652 and 697.
> > >
> > > Meanwhile, I'll attempt to revert to r337669.
> >
> > r337669 builds and runs.
> >
> > Looking further into r337670, it seems
> > cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes
> > for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation
> > can be found in any of the files affected by r337670.
> >
> > --
> > Trond.
> ___
> 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"
>
___
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 failure

[Matthew Macy]

Sorry guys, last time I touched ZFS I tried to push to make it an option to
statically link and was actually told that it wasn't something anyone else
wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.

-M

On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl <
trond.endres...@fagskolen.gjovik.no> wrote:

> On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
>
> > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
> >
> > > Is anyone else seeing this when building a new kernel with ZFS
> compiled in?
> > >
> > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
> > > --- kernel ---
> > > linking kernel
> > > ld: error: undefined symbol: dbuf_stats_init
> > > >>> referenced by dbuf.c
> > > >>>   dbuf.o:(dbuf_init)
> > >
> > > ld: error: undefined symbol: dbuf_stats_destroy
> > > >>> referenced by dbuf.c
> > > >>>   dbuf.o:(dbuf_fini)
> > > *** [kernel] Error code 1
> >
> > I was just about to create a thread of my own.
> >
> > I suspect r337670 didn't add everything
> > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See
> > lines 652 and 697.
> >
> > Meanwhile, I'll attempt to revert to r337669.
>
> r337669 builds and runs.
>
> Looking further into r337670, it seems
> cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes
> for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation
> can be found in any of the files affected by r337670.
>
> --
> Trond.
___
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 failure

[Trond Endrestøl]

On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:

> On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
> 
> > Is anyone else seeing this when building a new kernel with ZFS compiled in?
> > 
> > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
> > --- kernel ---
> > linking kernel
> > ld: error: undefined symbol: dbuf_stats_init
> > >>> referenced by dbuf.c
> > >>>   dbuf.o:(dbuf_init)
> > 
> > ld: error: undefined symbol: dbuf_stats_destroy
> > >>> referenced by dbuf.c
> > >>>   dbuf.o:(dbuf_fini)
> > *** [kernel] Error code 1
> 
> I was just about to create a thread of my own.
> 
> I suspect r337670 didn't add everything 
> cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See 
> lines 652 and 697.
> 
> Meanwhile, I'll attempt to revert to r337669.

r337669 builds and runs.

Looking further into r337670, it seems 
cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes 
for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation 
can be found in any of the files affected by r337670.

-- 
Trond.
___
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 failure

[Trond Endrestøl]

On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:

> Is anyone else seeing this when building a new kernel with ZFS compiled in?
> 
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
> --- kernel ---
> linking kernel
> ld: error: undefined symbol: dbuf_stats_init
> >>> referenced by dbuf.c
> >>>   dbuf.o:(dbuf_init)
> 
> ld: error: undefined symbol: dbuf_stats_destroy
> >>> referenced by dbuf.c
> >>>   dbuf.o:(dbuf_fini)
> *** [kernel] Error code 1

I was just about to create a thread of my own.

I suspect r337670 didn't add everything 
cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See 
lines 652 and 697.

Meanwhile, I'll attempt to revert to r337669.

-- 
Trond.
___
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 failure

[Michael Butler]

Is anyone else seeing this when building a new kernel with ZFS compiled in?

Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
--- kernel ---
linking kernel
ld: error: undefined symbol: dbuf_stats_init
>>> referenced by dbuf.c
>>>   dbuf.o:(dbuf_init)

ld: error: undefined symbol: dbuf_stats_destroy
>>> referenced by dbuf.c
>>>   dbuf.o:(dbuf_fini)
*** [kernel] Error code 1

imb


___
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: Build failure in stand

[Warner Losh]

On Tue, Dec 5, 2017 at 2:03 PM, Ryan Stone <ryst...@gmail.com> 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 than the objdir in certain cases when
> using make -C.  I have a workaround in place for now and bdrewery@ is
> working on a fix for the build infrastructure.
>

OK. That makes sense. It's caused by using the amd64 cpufuncs file being
used when compiling on i386 (aka -m32).

I have some fixes that should make it less likely to be an issue in the
works...

Warner
___
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: Build failure in stand

[Ryan Stone]

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 a workaround in place for now and bdrewery@ is
working on a fix for the build infrastructure.
___
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: Build failure in stand

[Warner Losh]

Oh, and one more btw, can you cd stand; cd ` make -V .OBJDIR ` ; find .
-name machine | xargs ls -l

The only way I can see this happening is if we're doing a 32-bit build, but
pulling in the amd64 header files for some bogus reason...

Finally, what's the host OS?

Warner


On Mon, Dec 4, 2017 at 4:20 PM, Warner Losh <i...@bsdimp.com> wrote:

> Also, can you make the full logs available? I can't recreate this with or
> without DEBUG_FLAGS or CFLAGS setting in my make.conf file.
>
> Warner
>
> On Mon, Dec 4, 2017 at 3:59 PM, Warner Losh <i...@bsdimp.com> wrote:
>
>> Please remove the DEBUG_FLAGS and try again. Trying to see if that's the
>> culprit. It works for me with the default build.
>>
>> Warner
>>
>> On Mon, Dec 4, 2017 at 3:32 PM, Ryan Stone <ryst...@gmail.com> wrote:
>>
>>> I'm seeing the following build failure when doing a buildworld of head:
>>>
>>> In file included from
>>> /repos/users/rstone/bsd-worktree/route-change/stand/ficl/i38
>>> 6/sysdep.c:18:
>>> /repos/users/rstone/bsd-worktree/route-change/stand/libsa/ma
>>> chine/cpufunc.h:491:13:
>>> error: shift count >= width of type [-Werror,-Wshift-count-overflow]
>>> high = val >> 32;
>>>^  ~~
>>> 1 error generated.
>>>
>>>
>>> My make.conf looks like:
>>>
>>> PERL_VERSION=5.14.2
>>>
>>> DEBUG_FLAGS=-g
>>> CFLAGS+=-fno-omit-frame-pointer
>>>
>>> #BTX_SERIAL=yes
>>> #BOOT_PXELDR_ALWAYS_SERIAL=yes
>>> # src/sys/boot/i386/libi386/Makefile (loader)
>>> #BOOT_COMCONSOLE_SPEED=115200
>>> ## src/sys/boot/i386/libi386/comconsole.c (loader)
>>> COMSPEED=115200
>>> # src/sys/dev/sio/sioreg.h (kernel)
>>> #CONSPEED=115200
>>>
>>> WITHOUT_DEBUG_FILES=yes
>>>
>>> and my src.conf is:
>>>
>>> WITH_TESTS=yes
>>> WITHOUT_DEBUG_FLAGS=yes
>>> WITHOUT_INFO=yes
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>> reebsd.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: Build failure in stand

[Warner Losh]

Also, can you make the full logs available? I can't recreate this with or
without DEBUG_FLAGS or CFLAGS setting in my make.conf file.

Warner

On Mon, Dec 4, 2017 at 3:59 PM, Warner Losh <i...@bsdimp.com> wrote:

> Please remove the DEBUG_FLAGS and try again. Trying to see if that's the
> culprit. It works for me with the default build.
>
> Warner
>
> On Mon, Dec 4, 2017 at 3:32 PM, Ryan Stone <ryst...@gmail.com> wrote:
>
>> I'm seeing the following build failure when doing a buildworld of head:
>>
>> In file included from
>> /repos/users/rstone/bsd-worktree/route-change/stand/ficl/
>> i386/sysdep.c:18:
>> /repos/users/rstone/bsd-worktree/route-change/stand/libsa/
>> machine/cpufunc.h:491:13:
>> error: shift count >= width of type [-Werror,-Wshift-count-overflow]
>> high = val >> 32;
>>^  ~~
>> 1 error generated.
>>
>>
>> My make.conf looks like:
>>
>> PERL_VERSION=5.14.2
>>
>> DEBUG_FLAGS=-g
>> CFLAGS+=-fno-omit-frame-pointer
>>
>> #BTX_SERIAL=yes
>> #BOOT_PXELDR_ALWAYS_SERIAL=yes
>> # src/sys/boot/i386/libi386/Makefile (loader)
>> #BOOT_COMCONSOLE_SPEED=115200
>> ## src/sys/boot/i386/libi386/comconsole.c (loader)
>> COMSPEED=115200
>> # src/sys/dev/sio/sioreg.h (kernel)
>> #CONSPEED=115200
>>
>> WITHOUT_DEBUG_FILES=yes
>>
>> and my src.conf is:
>>
>> WITH_TESTS=yes
>> WITHOUT_DEBUG_FLAGS=yes
>> WITHOUT_INFO=yes
>> ___
>> 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
>> "
>>
>
>
___
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: Build failure in stand

[Warner Losh]

Please remove the DEBUG_FLAGS and try again. Trying to see if that's the
culprit. It works for me with the default build.

Warner

On Mon, Dec 4, 2017 at 3:32 PM, Ryan Stone <ryst...@gmail.com> wrote:

> I'm seeing the following build failure when doing a buildworld of head:
>
> In file included from
> /repos/users/rstone/bsd-worktree/route-change/stand/ficl/i386/sysdep.c:18:
> /repos/users/rstone/bsd-worktree/route-change/stand/
> libsa/machine/cpufunc.h:491:13:
> error: shift count >= width of type [-Werror,-Wshift-count-overflow]
> high = val >> 32;
>^  ~~
> 1 error generated.
>
>
> My make.conf looks like:
>
> PERL_VERSION=5.14.2
>
> DEBUG_FLAGS=-g
> CFLAGS+=-fno-omit-frame-pointer
>
> #BTX_SERIAL=yes
> #BOOT_PXELDR_ALWAYS_SERIAL=yes
> # src/sys/boot/i386/libi386/Makefile (loader)
> #BOOT_COMCONSOLE_SPEED=115200
> ## src/sys/boot/i386/libi386/comconsole.c (loader)
> COMSPEED=115200
> # src/sys/dev/sio/sioreg.h (kernel)
> #CONSPEED=115200
>
> WITHOUT_DEBUG_FILES=yes
>
> and my src.conf is:
>
> WITH_TESTS=yes
> WITHOUT_DEBUG_FLAGS=yes
> WITHOUT_INFO=yes
> ___
> 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"
>
___
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"

Build failure in stand

[Ryan Stone]

I'm seeing the following build failure when doing a buildworld of head:

In file included from
/repos/users/rstone/bsd-worktree/route-change/stand/ficl/i386/sysdep.c:18:
/repos/users/rstone/bsd-worktree/route-change/stand/libsa/machine/cpufunc.h:491:13:
error: shift count >= width of type [-Werror,-Wshift-count-overflow]
high = val >> 32;
   ^  ~~
1 error generated.


My make.conf looks like:

PERL_VERSION=5.14.2

DEBUG_FLAGS=-g
CFLAGS+=-fno-omit-frame-pointer

#BTX_SERIAL=yes
#BOOT_PXELDR_ALWAYS_SERIAL=yes
# src/sys/boot/i386/libi386/Makefile (loader)
#BOOT_COMCONSOLE_SPEED=115200
## src/sys/boot/i386/libi386/comconsole.c (loader)
COMSPEED=115200
# src/sys/dev/sio/sioreg.h (kernel)
#CONSPEED=115200

WITHOUT_DEBUG_FILES=yes

and my src.conf is:

WITH_TESTS=yes
WITHOUT_DEBUG_FLAGS=yes
WITHOUT_INFO=yes
___
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: Build failure: non-SMP after SVN r324778

[Mateusz Guzik]

On Fri, Oct 20, 2017 at 3:52 PM, Michael Butler 
wrote:

> If SMP is not defined, as it isn't on my last remaining i386 platform, the
> build fails with:
>
> Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o
> --- kern_mutex.o ---
> /usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of
> function '_mtx_lock_spin' is invalid in C99 [-Werror,-Wimplicit-function-d
> eclaration]
> _mtx_lock_spin(m, v, opts, file, line);
> ^
> /usr/src/sys/kern/kern_mutex.c:313:3: error: this function declaration is
> not a prototype [-Werror,-Wstrict-prototypes]
> 2 errors generated.
> *** [kern_mutex.o] Error code 1
>
>
oops, fixed in r324803.

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

Build failure: non-SMP after SVN r324778

[Michael Butler]

If SMP is not defined, as it isn't on my last remaining i386 platform, 
the build fails with:


Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o
--- kern_mutex.o ---
/usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of 
function '_mtx_lock_spin' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]

_mtx_lock_spin(m, v, opts, file, line);
^
/usr/src/sys/kern/kern_mutex.c:313:3: error: this function declaration 
is not a prototype [-Werror,-Wstrict-prototypes]

2 errors generated.
*** [kern_mutex.o] Error code 1

make[2]: stopped in /usr/obj/usr/src/sys/SARAH

imb

___
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: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

[Simon J. Gerraty]

David Wolfskill  wrote:

> On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> > This is on my "build machine"; running GENERIC/amd64 built yesterday:
> > 
> > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353  
> > r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 
> > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> > 
> 
> Well, the laptop, running:

Compare the meta files for ARUBA_pfp.bin
in the failure case it looks very much like a input file was not
supplied (eg empty variable)

A possibility is .OODATE being used; which will be empty if none of the
srcs are out-of-date.


A quick scan didn't identify where the target for that comes from
so guessing...
___
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: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

[David Wolfskill]

On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> This is on my "build machine"; running GENERIC/amd64 built yesterday:
> 

Nevermind.  Replacing /usr/src with a fresh checkout resolved the issue.

Peace,
davdi
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

[David Wolfskill]

On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> This is on my "build machine"; running GENERIC/amd64 built yesterday:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353  
> r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 

Well, the laptop, running:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #355  
r318781M/318781:1200031: Wed May 24 19:23:41 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

failed to exhibit the failure.  I'll poke a bit more at the build machine.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

[David Wolfskill]

On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote:
> ...
> I have attached a copy of the meta file in question.
> 

Bah.  Really attaching this time.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
# Meta data file 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/ARUBA_pfp.bin.meta
CMD uudecode -p  > ARUBA_pfp.bin
CWD 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp
TARGET ARUBA_pfp.bin
-- command output --
uudecode: stdin: missing or bad "begin" line
*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 17403
# Start 1495712760.942230
V 5
E 17502 /bin/sh
R 17502 /etc/libmap.conf
R 17502 /var/run/ld-elf.so.hints
R 17502 /lib/libedit.so.7
R 17502 /lib/libc.so.7
R 17502 /lib/libncursesw.so.8
R 17502 /usr/share/locale/en_US.UTF-8/LC_COLLATE
R 17502 /usr/share/locale/en_US.UTF-8/LC_CTYPE
R 17502 /usr/share/locale/en_US.UTF-8/LC_MONETARY
R 17502 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
R 17502 /usr/share/locale/en_US.UTF-8/LC_TIME
R 17502 /usr/share/locale/en_US.UTF-8/LC_MESSAGES
F 17502 17505
W 17505 ARUBA_pfp.bin
E 17505 /usr/bin/uudecode
R 17505 /etc/libmap.conf
R 17505 /var/run/ld-elf.so.hints
R 17505 /lib/libc.so.7
X 17505 1 0
X 17502 1 0
# Stop 1495712760.979230
# Bye bye


signature.asc
Description: PGP signature

Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp

[David Wolfskill]

This is on my "build machine"; running GENERIC/amd64 built yesterday:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353  
r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

after updating sources to r318863:

>>> World build started on Thu May 25 03:59:04 PDT 2017
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 3.1: recording compiler metadata
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: building everything
>>> stage 5.1: building lib32 shim libraries
>>> World build completed on Thu May 25 04:45:02 PDT 2017
>>> Kernel build for GENERIC started on Thu May 25 04:45:02 PDT 2017
>>> stage 1: configuring the kernel
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: building everything
...
--- all_subdir_drm2/radeonkms ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkms/iicbus_if.h
--- all_subdir_ctl ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/ctl/ctl.ko.debug
--- all_subdir_drm2 ---
--- all_subdir_drm2/radeonkmsfw ---
--- ARUBA_pfp.bin ---
uudecode: stdin: missing or bad "begin" line
--- all_subdir_ctl ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/ctl/ctl.ko
--- all_subdir_drm2 ---
--- all_subdir_drm2/radeonkmsfw/ARUBA_me ---
Building 
/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin


bmake[6]: stopped in /usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp
.ERROR_TARGET='ARUBA_pfp.bin'
.ERROR_META_FILE='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/ARUBA_pfp.bin.meta'
.MAKE.LEVEL='6'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/common/S4/obj/usr/src/sys/GENERIC/modules'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tm
p/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /
usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/sys/modules/drm2/radeonkmsfw/
ARUBA_pfp/Makefile /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu
.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk 
/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /
usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk 
/usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src
/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk 
/usr/src/share/mk/bsd.subdir.mk /usr/src/sys/conf/kern.mk'



I have attached a copy of the meta file in question.

The only file in /usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp
is a Makefile ... last updated Oct 23 07:29:55 2014 (US/Pacific
time).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: HEAD [r313048] WITHOUT_INET6: tcpdump build failure

[Gleb Smirnoff]

  Thanks for report, I will look at it.

On Thu, Feb 02, 2017 at 06:00:45AM +0300, Alex Deiter wrote:
A> Hello,
A> 
A> Please take a look HEAD [r313048] - buildworld failed for IPv4-only system 
(WITHOUT_INET6):
A> 
A> cc -target x86_64-unknown-freebsd12.0 
--sysroot=/export/freebsd/obj/export/freebsd/src/tmp 
-B/export/freebsd/obj/export/freebsd/src/tmp/usr/bin  -O2 -pipe   
-I/export/freebsd/sr
A> c/usr.bin/ftp -I/export/freebsd/src/usr.bin/ftp/../../contrib/tnftp -DNDEBUG 
-MD  -MF.depend.util.o -MTutil.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Wall -Wno-for
A> mat-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equalit
A> y -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  
-c /export/freebsd/src/usr.bi
A> n/ftp/../../contrib/tnftp/src/util.c -o util.o
A> --- all_subdir_usr.sbin ---
A> print-ip6.o: In function `ip6_print':
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x4c6):
 undefined reference to `hbhopt_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x4d9):
 undefined reference to `rt6_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x530):
 undefined reference to `dstopt_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x574):
 undefined reference to `frag6_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x60b):
 undefined reference to `mobility_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x6ba):
 undefined reference to `icmp6_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x6da):
 undefined reference to `ospf6_print'
A> print-udp.o: In function `udp_print':
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x13e0):
 undefined reference to `ripng_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x13ff):
 undefined reference to `dhcp6_print'
A> 
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x143d):
 undefined reference to `babel_print'
A> cc: error: linker command failed with exit code 1 (use -v to see invocation)
A> *** [tcpdump] Error code 1
A> 
A> make[5]: stopped in /export/freebsd/src/usr.sbin/tcpdump/tcpdump
A> 1 error
A> 
A> Thank you!
A> 
A> Alex Deiter
A> alex.dei...@gmail.com
A> 
A> 
A> 
A> 

-- 
Totus tuus, Glebius.
___
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: HEAD [r313048] WITHOUT_INET6: tcpdump build failure

[Gleb Smirnoff]

On Thu, Feb 02, 2017 at 06:28:50AM +0300, Alex Deiter wrote:
A> Please review attached patch.

Thanks. It seems strange to me to reduce functionality of
tcpdump when a build doesn't support INET6. I still want
it able to parse packets I see on a network.

-- 
Totus tuus, Glebius.
___
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: HEAD [r313048] WITHOUT_INET6: tcpdump build failure

[Alex Deiter]

Hello,

Please review attached patch.

Thank you!

Alex Deiter
alex.dei...@gmail.com

Index: usr.sbin/tcpdump/tcpdump/Makefile
===
--- usr.sbin/tcpdump/tcpdump/Makefile   (revision 313074)
+++ usr.sbin/tcpdump/tcpdump/Makefile   (working copy)
@@ -36,6 +36,7 @@
print-ascii.c \
print-atalk.c \
print-atm.c \
+   print-babel.c \
print-beep.c \
print-bfd.c \
print-bgp.c \
@@ -50,6 +51,7 @@
print-cnfp.c \
print-dccp.c \
print-decnet.c \
+   print-dhcp6.c \
print-domain.c \
print-dtp.c \
print-dvmrp.c \
@@ -62,6 +64,7 @@
print-fddi.c \
print-forces.c \
print-fr.c \
+   print-frag6.c \
print-ftp.c \
print-geneve.c \
print-geonet.c \
@@ -70,10 +73,12 @@
print-hsrp.c \
print-http.c \
print-icmp.c \
+   print-icmp6.c \
print-igmp.c \
print-igrp.c \
print-ip.c \
print-ip6.c \
+   print-ip6opts.c \
print-ipcomp.c \
print-ipfc.c \
print-ipnet.c \
@@ -96,6 +101,7 @@
print-m3ua.c \
print-medsa.c \
print-mobile.c \
+   print-mobility.c \
print-mpcp.c \
print-mpls.c \
print-mptcp.c \
@@ -109,6 +115,7 @@
print-openflow.c \
print-openflow-1.0.c \
print-ospf.c \
+   print-ospf6.c \
print-otv.c \
print-pgm.c \
print-pim.c \
@@ -121,9 +128,11 @@
print-raw.c \
print-resp.c \
print-rip.c \
+   print-ripng.c \
print-rpki-rtr.c \
print-rrcp.c \
print-rsvp.c \
+   print-rt6.c \
print-rtsp.c \
print-rx.c \
print-sctp.c \
@@ -171,15 +180,6 @@
 CFLAGS+= -D_U_="__attribute__((unused))"
 
 .if ${MK_INET6_SUPPORT} != "no"
-SRCS+= print-babel.c \
-   print-dhcp6.c \
-   print-frag6.c \
-   print-icmp6.c \
-   print-ip6opts.c \
-   print-mobility.c \
-   print-ospf6.c \
-   print-ripng.c \
-   print-rt6.c
 CFLAGS+=   -DINET6 -DHAVE_OS_IPV6_SUPPORT
 .endif
 .if ${MACHINE_CPUARCH} != "i386"
___
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"

HEAD [r313048] WITHOUT_INET6: tcpdump build failure

[Alex Deiter]

Hello,

Please take a look HEAD [r313048] - buildworld failed for IPv4-only system 
(WITHOUT_INET6):

cc -target x86_64-unknown-freebsd12.0 
--sysroot=/export/freebsd/obj/export/freebsd/src/tmp 
-B/export/freebsd/obj/export/freebsd/src/tmp/usr/bin  -O2 -pipe   
-I/export/freebsd/sr
c/usr.bin/ftp -I/export/freebsd/src/usr.bin/ftp/../../contrib/tnftp -DNDEBUG 
-MD  -MF.depend.util.o -MTutil.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Wall -Wno-for
mat-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equalit
y -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  
-c /export/freebsd/src/usr.bi
n/ftp/../../contrib/tnftp/src/util.c -o util.o
--- all_subdir_usr.sbin ---
print-ip6.o: In function `ip6_print':
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x4c6):
 undefined reference to `hbhopt_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x4d9):
 undefined reference to `rt6_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x530):
 undefined reference to `dstopt_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x574):
 undefined reference to `frag6_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x60b):
 undefined reference to `mobility_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x6ba):
 undefined reference to `icmp6_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x6da):
 undefined reference to `ospf6_print'
print-udp.o: In function `udp_print':
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x13e0):
 undefined reference to `ripng_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x13ff):
 undefined reference to `dhcp6_print'
/export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x143d):
 undefined reference to `babel_print'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [tcpdump] Error code 1

make[5]: stopped in /export/freebsd/src/usr.sbin/tcpdump/tcpdump
1 error

Thank you!

Alex Deiter
alex.dei...@gmail.com



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

Build failure: smbios.ko (r312404)

[Jochen Neumeister]

Hi list,

i use 12 current, and will update to r312404.

Buildworld stop with this error:

===> bios (install)
===> bios/smbios (install)
install -T release -o root -g wheel -m 555   smbios.ko /boot/kernel/
install: smbios.ko: No such file or directory
*** Error code 71

Stop.
bmake[5]: stopped in /usr/src/sys/modules/bios/smbios
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/sys/modules/bios
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
bmake[2]: stopped in /usr/obj/usr/src/sys/MIWIBOX
*** Error code 1

Stop.
bmake[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

Google doesn't help me.

Any tipps for me?


Regards

Jochen

___
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: Build failure 'wmmintrin.h' file not found

[Warner Losh]

On Wed, Jan 18, 2017 at 1:21 PM, Dimitry Andric  wrote:
> On 18 Jan 2017, at 14:42, Magnus Ringman  wrote:
>>
>> On Wed, Jan 18, 2017 at 2:16 PM, Hans Petter Selasky 
>> wrote:
> ...
>>> And the error popped out. I'm not observing this error when building a
>>> 12-current kernel from an 11-stable install.
>>
>>
>> Isn't it all bets are off if going to -current from anything but most
>> recent -stable?

Nope. There's a range of supported major branches. This has been the
case for at least 15 years. Typically, we've supported 2-4 old
branches building current due to the needs of the FreeBSD community
and that community making sure it works often enough that we don't
just shut the door to it entirely. Each individual developer only
needs to test the latest branch, but that's not the same as what's
supported. From time to time we bump the minimum system, but it isn't
in lock step with the major branches.

>> Recommended practice[citation needed] would be
>> 10-stable->11-stable->12-current.
>
> That is the safest way, indeed.  But it should not be totally impossible
> to build recent versions of -current on 10.x.

We support building world on 10.3 and newer for -current today. There
were compiler changes to fix bad code generation between 10.2 and
10.3, however, so the usual "any stable-10' is no longer the case. In
fact, it's still supported building from the tip of stable/9 for
current. However, the same compiler bug is not fixed in the last 9.x
release, so there the upgrade is needed.

> Normally, buildworld takes care of the heavy lifting by building all the
> needed tools first.  But if you build only parts of the tree, you might
> encounter "interesting" situations. :)

Anything less than buildworld is defintely not supported when the host
system isn't completely up to date. Well, make kernel-toolchain is
sufficient for make buildkernel.

Warner
___
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: Build failure 'wmmintrin.h' file not found

[Dimitry Andric]

On 18 Jan 2017, at 14:42, Magnus Ringman  wrote:
> 
> On Wed, Jan 18, 2017 at 2:16 PM, Hans Petter Selasky 
> wrote:
...
>> And the error popped out. I'm not observing this error when building a
>> 12-current kernel from an 11-stable install.
> 
> 
> Isn't it all bets are off if going to -current from anything but most
> recent -stable?
> Recommended practice[citation needed] would be
> 10-stable->11-stable->12-current.

That is the safest way, indeed.  But it should not be totally impossible
to build recent versions of -current on 10.x.

Normally, buildworld takes care of the heavy lifting by building all the
needed tools first.  But if you build only parts of the tree, you might
encounter "interesting" situations. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failure 'wmmintrin.h' file not found

[Dimitry Andric]

On 18 Jan 2017, at 14:16, Hans Petter Selasky  wrote:
> 
> On 01/18/17 14:13, Dimitry Andric wrote:
>> On 18 Jan 2017, at 13:36, Hans Petter Selasky  wrote:
>>> 
>>> I'm seeing the following build-error trying to build 12-current from 
>>> 10-stable:
>>> 
>>> xxx/freebsd/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 
>>> 'wmmintrin.h' file not found
>>> #include 
>>> 
>>> Missing header exists:
>>> 
>>> xxx/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h
>>> 
>>> Missing include directory or compiler magic?
>> 
>> What are you building, and how?  Did you do a buildworld before buildkernel?
>> 
>> -Dimitry
>> 
> 
> I did:
> 
> make toolchain -jXX
> 
> And then:
> 
> make buildkernel -jXX
> 
> And the error popped out.

As far as I can see, the toolchain target does not install headers and
libraries.  Can you try the kernel-toolchain target instead?


> I'm not observing this error when building a 12-current kernel from an 
> 11-stable install.

Probably not, because you will be using /usr/bin/cc, and the wmmintrin.h
header in the base system.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail