From owner-freebsd-ports@freebsd.org Thu Nov 15 19:47:01 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88FE21107BD7 for ; Thu, 15 Nov 2018 19:47:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C97E47B6CA for ; Thu, 15 Nov 2018 19:47:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 00Qy0qwVM1mIPc.21GcXvH_Xsfa4gG1YT1qHmJAI831PmlCYh6GRbtQrW7UI_ba jVOHCokIkE96b.ZXni0CJvfEAsqy_8NXyV1Q6Zu1BQhYyRD2COxCqS0S6RUX.iBW0ShylXdOPcY. icKav517qxdHlcSGkCPsABQg6a2czhk973GxltM2xb97h.89JgNXvRzgnM4QS0DQXlgxSb8Gytvw bKNOn7rAnoCudi9ha0GUXjvnlqsXAjDq7I4F3cV9A3A7Aeb5Vx3IEp4fa4LUVvFJRWXxS..s3AOx Tu5PiuMkau4kTPnJlfNhs8HFSSXCgvLAMNxrVt7QZgydjDxAcK40Cgn68tpeRMAdvNHAWRDokdgR trpgaAfwEK2jrpNWV0CVvnYEGrzRSZNhTdsVvz2LCOap9SIoQ70YQK4iGvJfQbGzIl0zRCxBXXcX ti9gcBdFMB1aPz4Gv8RuyofxS4741nlLpu.9iaz3OSOUY04SqPWctm68Yk.ecui37KTDSUvbtP1S QnCbyKRMoTmosIlebkXqD1_MIgDyrqt6njLt7TemvZ1CCjCVscp3pXxOZVIWmf7f2g7sPTMarwEb POXV16pOgsgbhEXlf5X_81VgS4waJJXKeCjjtvsowg0oa_.tWunAMbh_2AEnOrx_p0GqnCIKyupw NlAq6eCiizVtgnV2gVUc2oWrGeMoqAeJVgEHhAwplOHzU1.NfKRj_L2n1PEh2YNtFpJWpTmb1Wsf 7e8NLEM_ooJCYXYA38qrSNyiWOh8Q.8cyC1dbaVKbKxRTn7MBtd5TxpZpbwnPPWegI7niuMKLOyS Xh6_uuqvvXYFRo5AuqSy.obxuyBqT_mul30HFo5YpJOL40fuati9CqG2SALq6tlRnPDSipl4vL9E 9yyx0.zLmA12qBn3cs0pV3D73OiwPXn0E08U1t203OVOETi1YVt8B96ICSM4QC2F9Z62ERdPnmX6 AYsv9_9EWVnO5yENlJavKFTY8e6IWVHlOdQi0zpe0LG16BArPpfy.49mp.rw6CN_ANR4X4pzqeAS HyBTxM9bHwkMW5I7kawWrK8G6xBRona1LFj5vJuAxhJ_mIKuXDVt7dBU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Nov 2018 19:46:54 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp402.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d26cf804a773e47259dfee169d99e9c9; Thu, 15 Nov 2018 19:46:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: ports head -r484652: lang/ruby24 fails to amd64 -> armv7 cross build: qemu: uncaught target signal 11 (2 of them) [armv7 native build worked] From: Mark Millard In-Reply-To: <0E2549AE-5235-40C3-A5F8-4D66D3F3E0E5@yahoo.com> Date: Thu, 15 Nov 2018 11:46:49 -0800 Cc: Jan Beich Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E2549AE-5235-40C3-A5F8-4D66D3F3E0E5@yahoo.com> To: ports-list freebsd , freebsd-ruby@freebsd.org X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: C97E47B6CA X-Spamd-Result: default: False [-2.06 / 200.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com]; NEURAL_HAM_MEDIUM(-0.81)[-0.808,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.01)[0.007,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCVD_IN_DNSWL_NONE(0.00)[146.66.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; IP_SCORE(0.24)[ipnet: 98.137.64.0/21(0.73), asn: 36647(0.58), country: US(-0.10)]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 19:47:01 -0000 [While the poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7 cross build failed, a native armv7 build worked. It turns out the difference that matters is likely -O2 use vs -O use. More later below.] On 2018-Nov-10, at 23:29, Mark Millard wrote: > Poudriere-devel reported: >=20 > [00:18:32] [07] [00:02:56] Saved lang/ruby24 | ruby-2.4.5,1 wrkdir to: = /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/ruby-2= .4.5,1.tbz > [00:18:32] [07] [00:02:56] Finished lang/ruby24 | ruby-2.4.5,1: = Failed: build >=20 > The log showed: >=20 > --- miniruby --- > linking miniruby > --- .rbconfig.time --- > --- encdb.h --- > generating encdb.h > --- .rbconfig.time --- > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > *** [.rbconfig.time] Error code 139 >=20 > make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5 > --- encdb.h --- > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > *** [encdb.h] Error code 139 >=20 > make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5 > 2 errors >=20 >=20 > Despite how the above looks, I find only one .core file in the > tar archive produced for the failure: >=20 > # find /wrkdirs/usr/ports/lang/ruby/ -name "*.core" -print > /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/qemu_miniruby.core >=20 > Apparently qemu does not allow for separate files for distinct > processes. >=20 > For that .core file I find (libexec/gdb): >=20 > # chroot /usr/obj/DESTDIRs/clang-armv7-installworld-poud > # cd /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/ > # /usr/libexec/gdb miniruby qemu_miniruby.core=20 > . . . > (gdb) bt > #0 0x00113f84 in rb_gc_writebarrier_unprotect (obj=3D4104601600) at = gc.c:1119 > 1119 return RVALUE_WB_UNPROTECTED_BITMAP(obj) !=3D 0; > [New Thread f4b5d000 (LWP 100638/)] > [New LWP 61684] > Current language: auto; currently minimal > (gdb) bt > #0 0x00113f84 in rb_gc_writebarrier_unprotect (obj=3D4104601600) at = gc.c:1119 > #1 0x000c3fc8 in rb_include_class_new (module=3D4104569400, = super=3D) at ruby.h:1456 > #2 0x000c4424 in include_modules_at (klass=3D4104602160, = c=3D4104602160, module=3D4104569400, search_super=3D) at class.c:913 > #3 0x000c41f0 in rb_include_module (klass=3D4104602160, = module=3D4104569400) at class.c:870 > #4 0x001f6dec in Init_String () at string.c:10021 > #5 0x00129398 in rb_call_inits () at inits.c:28 > #6 0x00103bac in ruby_setup () at eval.c:60 > #7 0x00103be8 in ruby_init () at eval.c:76 > #8 0x000a3300 in main (argc=3D11, argv=3D0x9fffe41c) at main.c:35 > (gdb) up > #1 0x000c3fc8 in rb_include_class_new (module=3D4104569400, = super=3D) at ruby.h:1456 > 1456 rb_gc_writebarrier_unprotect(x); > (gdb) up > #2 0x000c4424 in include_modules_at (klass=3D4104602160, = c=3D4104602160, module=3D4104569400, search_super=3D) at class.c:913 > 913 iclass =3D rb_include_class_new(module, = RCLASS_SUPER(c)); > (gdb) up > #3 0x000c41f0 in rb_include_module (klass=3D4104602160, = module=3D4104569400) at class.c:870 > 870 changed =3D include_modules_at(klass, RCLASS_ORIGIN(klass), = module, TRUE); > (gdb) up > #4 0x001f6dec in Init_String () at string.c:10021 > 10021 rb_include_module(rb_cString, rb_mComparable); > (gdb) up > #5 0x00129398 in rb_call_inits () at inits.c:28 > 28 CALL(String); > (gdb) up > #6 0x00103bac in ruby_setup () at eval.c:60 > 60 rb_call_inits(); > (gdb) up > #7 0x00103be8 in ruby_init () at eval.c:76 > 76 int state =3D ruby_setup(); > (gdb) up > #8 0x000a3300 in main (argc=3D11, argv=3D0x9fffe41c) at main.c:35 > 35 ruby_init(); >=20 > (I'm not familiar with what details libexec/gdb gets > right vs. wrong. But the call chain seems coherent.) >=20 > Host environment: >=20 > # uname -apKU > FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r340287M: Fri = Nov 9 08:37:01 PST 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG amd64 amd64 1300003 1300003 A prior example that fails for native armv7 builds but works for poudriere-devel/qemu-arm-static/nxb-bin/ (native cross tools based) amd64 -> armv7 cross builds is x11/pixman. Previously I discovered that x11/pixman builds fine in poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7 cross builds but a link fails during native armv7 builds. It turned out that with the host-native cross tools involved -O2 was being used where native -O was being used: the code in share/mk/sys.mk that is designed to use -O for arm fails to do so and uses -O2 instead. (MACHINE_ARCH temporarily looks to be amd64, which gets a -O2 put in CFLAGS instead of -O .) ruby seems to go the other direction: with -O2 involved something builds that fails to run during the build. With -O involved instead ruby builds fine and produces a ruby that works. (I've not done any analysis to see if the -O2 based build failure is because of code making assumption that are not guaranteed vs. if the compiler/linker is producing something bad from well-defined code.) Bryan Drewery is now aware of the odd -O2 vs. -O behavior under poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7 cross builds and likely it will be fixed at some point. But the existing behavior means that official armv6 and armv7 port builds that use that poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7 cross build structure have been using -O2 for a long time. This may challenge the use of -O by default in CFLAGS for armv6 and armv7, in that -O2 has been under an implicit test for as long as the cross build structure has been used with share/mk/sys.mk having the MACHINE_ARCH based selection of -O2 vs. -O . mips* may have similar issues to arm* based on what share/mk/sys.mk does for -O2 vs. -O . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)