Re: Inconsistent -DNO_CLEAN build failure r293913 -> r294086
On Fri, Jan 15, 2016 at 03:00:00PM -0800, Bryan Drewery wrote: > ... > World build started on Fri Jan 15 04:28:48 PST 2016 > > ... > stage 5.1: building 32 bit shim libraries > > ... > > --- lib/libldns__L --- > > --- libprivateldns.so.5 --- > > /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible > > /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so when searching for -lgcc_s > > This is odd... Agreed; that's largely why I posted. Well, that, and the apparently lack of consistent behavior between the 2 machines. > > --- secure/lib/libssl__L --- > > --- libssl.a --- > > --- kerberos5/lib/libhx509__L --- > > --- keyset.po --- > > --- secure/lib/libssl__L --- > > building static ssl library > > --- lib/libldns__L --- > > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s > > By this point (lib/libldns__L) libgcc should be built and installed. I > assume it says 'cannot find' since it is incompatible. Apparently, yes. > I don't think this is a build race or FAST_DEPEND issue. > > It could be a -DNO_CLEAN issue. Nothing is standing out as an issue in > the commit range given, except if you were building for arm. In each case, it was a native build on amd64. > ... > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > *** [libprivateldns.so.5] Error code 1 > > > > make[4]: stopped in /usr/src/lib/libldns > > > > > > from which that process didn't recover at all well... though a > > re-start without "-DNO_CLEAN" completed successfully. > ... > > One other (possibly-salient) point is that the build machine's disk > > drive is an SSD. (And yes, that does tend to help make it faster.) > Well, I suppose I'll take some small comfort in knowing that I'm not the only one perplexed by the behavior. :-} Thanks for looking at it. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Inconsistent -DNO_CLEAN build failure r293913 -> r294086
On 1/15/16 6:00 AM, David Wolfskill wrote: > OK, first: I realize that using "-DNO_CLEAN" is treading on somewhat > unstable ground. I'm testing; the results I obtained this morning were > a bit unexpected, so I'm reporting them in case said results might be > of use or interest to others. > > As indicated in the Subject, I started a couple of machines (a dedicated > "build machine" and my laptop) at r293913, updated source to r294086, > then proceeded to perform "make -j16 -DNO_CLEAN buildworld" on each. > > Please note that in each case, I have "WITH_FAST_DEPEND=1" in > /etc/src.conf. > > The laptop chugged along and completed normally; the build machine > encountered: > World build started on Fri Jan 15 04:28:48 PST 2016 > ... stage 5.1: building 32 bit shim libraries > ... > --- lib/libldns__L --- > --- libprivateldns.so.5 --- > /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible > /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so when searching for -lgcc_s This is odd... > --- secure/lib/libssl__L --- > --- libssl.a --- > --- kerberos5/lib/libhx509__L --- > --- keyset.po --- > --- secure/lib/libssl__L --- > building static ssl library > --- lib/libldns__L --- > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s By this point (lib/libldns__L) libgcc should be built and installed. I assume it says 'cannot find' since it is incompatible. I don't think this is a build race or FAST_DEPEND issue. It could be a -DNO_CLEAN issue. Nothing is standing out as an issue in the commit range given, except if you were building for arm. > --- secure/lib/libssl__L --- > ar -crD libssl.a `NM='nm' NMFLAGS='' lorder bio_ssl.o d1_both.o d1_clnt.o > d1_lib.o d1_meth.o d1_pkt.o d1_srtp.o d1_srvr.o s23_clnt.o s23_lib.o > s23_meth.o s23_pkt.o s23_srvr.o s3_both.o s3_cbc.o s3_clnt.o s3_enc.o > s3_lib.o s3_meth.o s3_pkt.o s3_srvr.o ssl_algs.o ssl_asn1.o ssl_cert.o > ssl_ciph.o ssl_conf.o ssl_err.o ssl_err2.o ssl_lib.o ssl_rsa.o ssl_sess.o > ssl_stat.o ssl_txt.o t1_clnt.o t1_enc.o t1_ext.o t1_lib.o t1_meth.o > t1_reneg.o t1_srvr.o tls_srp.o | tsort -q` > --- lib/libldns__L --- > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [libprivateldns.so.5] Error code 1 > > make[4]: stopped in /usr/src/lib/libldns > > > from which that process didn't recover at all well... though a > re-start without "-DNO_CLEAN" completed successfully. > > Here are the relevant "uname -a" outputs: > > FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #305 > r293913M/293913:1100093: Thu Jan 14 04:55:39 PST 2016 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #306 > r294086M/294086:1100094: Fri Jan 15 05:03:24 PST 2016 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > > FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1961 > r293913M/293913:1100093: Thu Jan 14 04:49:29 PST 2016 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1962 > r294086M/294086:1100094: Fri Jan 15 05:33:30 PST 2016 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > > One other (possibly-salient) point is that the build machine's disk > drive is an SSD. (And yes, that does tend to help make it faster.) > > Peace, > david > -- Regards, Bryan Drewery ___ 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: Inconsistent -DNO_CLEAN build failure r293913 -> r294086
On 1/15/16 6:00 AM, David Wolfskill wrote: > OK, first: I realize that using "-DNO_CLEAN" is treading on somewhat > unstable ground. I'm testing; the results I obtained this morning were > a bit unexpected, so I'm reporting them in case said results might be > of use or interest to others. > Thanks for this one. I'll keep it in mind to look at if someone doesn't beat me to it. I'm still looking into fixing the kernel panic ones. I've figured out the issue and am looking for a fix there. -- Regards, Bryan Drewery ___ 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"
Inconsistent -DNO_CLEAN build failure r293913 -> r294086
OK, first: I realize that using "-DNO_CLEAN" is treading on somewhat unstable ground. I'm testing; the results I obtained this morning were a bit unexpected, so I'm reporting them in case said results might be of use or interest to others. As indicated in the Subject, I started a couple of machines (a dedicated "build machine" and my laptop) at r293913, updated source to r294086, then proceeded to perform "make -j16 -DNO_CLEAN buildworld" on each. Please note that in each case, I have "WITH_FAST_DEPEND=1" in /etc/src.conf. The laptop chugged along and completed normally; the build machine encountered: >>> World build started on Fri Jan 15 04:28:48 PST 2016 ... >>> stage 5.1: building 32 bit shim libraries ... --- lib/libldns__L --- --- libprivateldns.so.5 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so when searching for -lgcc_s --- secure/lib/libssl__L --- --- libssl.a --- --- kerberos5/lib/libhx509__L --- --- keyset.po --- --- secure/lib/libssl__L --- building static ssl library --- lib/libldns__L --- /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s --- secure/lib/libssl__L --- ar -crD libssl.a `NM='nm' NMFLAGS='' lorder bio_ssl.o d1_both.o d1_clnt.o d1_lib.o d1_meth.o d1_pkt.o d1_srtp.o d1_srvr.o s23_clnt.o s23_lib.o s23_meth.o s23_pkt.o s23_srvr.o s3_both.o s3_cbc.o s3_clnt.o s3_enc.o s3_lib.o s3_meth.o s3_pkt.o s3_srvr.o ssl_algs.o ssl_asn1.o ssl_cert.o ssl_ciph.o ssl_conf.o ssl_err.o ssl_err2.o ssl_lib.o ssl_rsa.o ssl_sess.o ssl_stat.o ssl_txt.o t1_clnt.o t1_enc.o t1_ext.o t1_lib.o t1_meth.o t1_reneg.o t1_srvr.o tls_srp.o | tsort -q` --- lib/libldns__L --- cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libprivateldns.so.5] Error code 1 make[4]: stopped in /usr/src/lib/libldns from which that process didn't recover at all well... though a re-start without "-DNO_CLEAN" completed successfully. Here are the relevant "uname -a" outputs: FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #305 r293913M/293913:1100093: Thu Jan 14 04:55:39 PST 2016 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #306 r294086M/294086:1100094: Fri Jan 15 05:03:24 PST 2016 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1961 r293913M/293913:1100093: Thu Jan 14 04:49:29 PST 2016 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1962 r294086M/294086:1100094: Fri Jan 15 05:33:30 PST 2016 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 One other (possibly-salient) point is that the build machine's disk drive is an SSD. (And yes, that does tend to help make it faster.) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
