From owner-freebsd-toolchain@freebsd.org Sun Oct 7 10:57:43 2018 Return-Path: Delivered-To: freebsd-toolchain@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 04BAB10BDB1F for ; Sun, 7 Oct 2018 10:57:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 960A97FC68 for ; Sun, 7 Oct 2018 10:57:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 572FE10BDB15; Sun, 7 Oct 2018 10:57:42 +0000 (UTC) Delivered-To: toolchain@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 45DC210BDB14 for ; Sun, 7 Oct 2018 10:57:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC08E7FC5C for ; Sun, 7 Oct 2018 10:57:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2ECF4189F2 for ; Sun, 7 Oct 2018 10:57:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w97AvfSu027758 for ; Sun, 7 Oct 2018 10:57:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w97AvfCa027757 for toolchain@FreeBSD.org; Sun, 7 Oct 2018 10:57:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230412] graphics/GraphicsMagick: fails to build with libc++ 7 Date: Sun, 07 Oct 2018 10:57:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: antoine@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 10:57:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230412 --- Comment #6 from Antoine Brodin --- @sunpoet : can you verify that the c++03 is no longer needed and remove it? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Oct 10 06:05:56 2018 Return-Path: Delivered-To: freebsd-toolchain@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 EAFDE10C9450 for ; Wed, 10 Oct 2018 06:05:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.ne1.yahoo.com (sonic310-21.consmr.mail.ne1.yahoo.com [66.163.186.202]) (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 6DA9D8FFB7 for ; Wed, 10 Oct 2018 06:05:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6kc_KdIVM1lnW6xMUdOq1GT2KOl4aU39SKhC8Rm8E8Li2Oal373dGumsIXLE0Gw yzSrTYqCAcwMV8yC4oqEv8VYSzq6bN6ltpTkmHzt9.hKWsnj5Xp2aC4ugp36jq0JhGy9891PJofM KPw.pQI_GiVqj4ieuJkQdaKUm5rhcVJLoft4PthTN6VjIzZoGP.Rsl9AMAnhyRttPjOyx6hdNJWE i5esnczXSndgzRACxVLyoVqxqRDUMVRlMARsdcMoW4aY8LIRp9X5kOqLo98gxKHeLk7ueYBE5_vH 6yOWpmE_36pw_2yGADefauYcrLlkMmUbsSZcAyqw8xO3aTGo68OLypgPxAIMP4BC.hBALJQqwdKt .t0Tyyzqx67ltqKMXPAUeM5Vb5PX6fVx9wfW0ewryjyCdEm5MwzuwR.i8Y1FVgQFlTgqhr1UoVcE 9dDEmU0v2eFtEmTvpAq2Eya2XSTo7jOoq.4_48D1wG_aGWeww.rKK5mj0NG1eEoQHKbopqZOzaif jfAoPd3XtqyJPJf.9qtMj.kEWEOpOZFJ2hViJGz7U_3jlAFAY_ZSf7pTLOevRXche5yLM.N6tqgF 78ptEEUgUTqOSII5eIn3LF9VmTlS8aTv1S.5al5ecK118zZjxUmorV2_moeb5VIiINiIi21_Goxv TcCZYXsI3q78InP7oMfQb4wD610LNwG4UaUoN5xUp2saBLpaqz8aWhr.yqaBVFC.A0YdRkwxqSw3 aw2nfbMux9KzEbiYLUu7Hh0QJk0HamnMRTEJz5zYw7PMsho_IegGtpakUINaCXtmml_4n3otpytp v6YzANVtlEAFIkd_Jfaw0DAx2hNDTJBV7oBqQVZAvGbL.FlhGUuun2MRyvhEFH5CcrA1j6i1gk1g _aPDzhA3H01wFhdtRFlWupLDOMC63gG7.DcQuuxfVmBN9AS4w15IW35iqqsmhJTaS.mXu6gPT2HQ t0yo3t2.cBYT2.Kwl0WzX2tB1qeytykDThf46S8TQFQ8lBhoNVqOoO2k8FpEQpducGxE65zXb4E0 N2OuUUSuEYWEtUcQnV2nkGqJLmQND19CYX9SeM8w_xKLj.eOR8sFFkvWbi2PGW0Bo0IdtK5R8Sru tQwf66hM0HfaT Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Oct 2018 06:05:49 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.101]) ([76.115.7.162]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b3e0e53628045545e98e73a4881cea4e; Wed, 10 Oct 2018 06:05:46 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: A /usr/src/Makefile.inc1 question for its MK_SYSTEM_COMPILER=no MK_SYSTEM_LINKER=no usage Message-Id: <52C17ABC-B2CF-4064-8395-B78686342A93@yahoo.com> Date: Tue, 9 Oct 2018 23:05:44 -0700 To: Bryan Drewery , FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 06:05:56 -0000 Is the following as intended? In /usr/src/Makefile.inc1 there is: # If all targets are disabled for system llvm then don't expect it to work # for cross-builds. .if !defined(TOOLS_PREFIX) && ${MK_LLVM_TARGET_ALL} == "no" && \ ${MACHINE} != ${TARGET} && ${MACHINE_ARCH} != ${TARGET_ARCH} && \ !make(showconfig) MK_SYSTEM_COMPILER= no MK_SYSTEM_LINKER= no .endif Take an example context of: MACHINE=arm64 TARGET=arm MACHINE_ARCH=aarch64 TARGET_ARCH=armv7 This would potentially allow the MK_SYSTEM_COMPILER and MK_SYSTEM_LINKER assignments to "no". (As an example use: MK_SYSTEM_COMPILER=="yes" is required to set to disable the bootstrap compiler via MK_CLANG_BOOTSTRAP and MK_GCC_BOOTSTRAP being set to "no".) Note: Any time ${MACHINE} != ${TARGET} then ${MACHINE_ARCH} != ${TARGET_ARCH} for the existing/supported combinations (if I understand right). This is probably a requirement on any future combinations as well in order to avoid _ARCH's being ambiguous. But both the contrasting example contexts of: MACHINE=arm TARGET=arm MACHINE_ARCH=armv6 TARGET_ARCH=armv7 and: MACHINE=arm TARGET=arm MACHINE_ARCH=armv7 TARGET_ARCH=armv7 would prevent the MK_SYSTEM_COMPILER and MK_SYSTEM_LINKER assignments to "no" based on (at least) ${MACHINE} == ${TARGET}. Note: Any time ${MACHINE_ARCH} == ${TARGET_ARCH} then ${MACHINE} == ${TARGET} for the existing/supported combinations (if I understand right). This is probably a requirement on any future combinations as well in order to avoid _ARCH's being ambiguous. So overall it seems the code is effectively (for valid combinations): .if !defined(TOOLS_PREFIX) && ${MK_LLVM_TARGET_ALL} == "no" && \ ${MACHINE} != ${TARGET} && \ !make(showconfig) MK_SYSTEM_COMPILER= no MK_SYSTEM_LINKER= no .endif Is that the intent? (I avoided powerpc combinations because of the current problematical status of clang/llvm materials when powerpc family members are involved for FreeBSD. Hopefully some year this will have proved temporary.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Oct 10 15:11:59 2018 Return-Path: Delivered-To: freebsd-toolchain@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 03E6A10B3B48 for ; Wed, 10 Oct 2018 15:11:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 93F8E846A2 for ; Wed, 10 Oct 2018 15:11:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 588D310B3B47; Wed, 10 Oct 2018 15:11:58 +0000 (UTC) Delivered-To: toolchain@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 3443810B3B46 for ; Wed, 10 Oct 2018 15:11:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA78D8469C for ; Wed, 10 Oct 2018 15:11:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id DC08120F37 for ; Wed, 10 Oct 2018 15:11:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9AFBuTT028072 for ; Wed, 10 Oct 2018 15:11:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9AFBuTN028063 for toolchain@FreeBSD.org; Wed, 10 Oct 2018 15:11:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230857] loading carp module panic i386 kernel (VIMAGE related) Date: Wed, 10 Oct 2018 15:11:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: panic, toolchain, vimage X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 15:11:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230857 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org Keywords| |toolchain --- Comment #5 from Bjoern A. Zeeb --- I'll start describing the problem from a reduced piece of code, which is no= t as big as carp, replicating carpstats, assuming VIMAGE is on: -------- #include #include #include #include #include #include #include struct xstats { uint64_t foo1; uint64_t bar1; uint64_t baz1; uint64_t mad1; uint64_t foo2; uint64_t bar2; uint64_t baz2; uint64_t mad2; uint64_t foo3; uint64_t bar3; uint64_t baz3; uint64_t mad3; uint64_t foo4; uint64_t bar4; uint64_t baz4; uint64_t mad4; }; VNET_PCPUSTAT_DEFINE(struct xstats, xstats); VNET_PCPUSTAT_SYSINIT(xstats); -------- This unrolls into: 1 struct _hack; 2 counter_u64_t vnet_entry_xstats[sizeof(struct xstats) / sizeof(uint64_= t)] __attribute__((__section__("set_vnet"))) __attribute__((__used__)); 3 4 5 static void 6 vnet_xstats_init(const void *unused) 7 { 8 do { 9 for (int i =3D 0; i < (sizeof((*(__typeof(vnet_entry_xst= ats) *) (((((__curthread())->td_vnet))->vnet_data_base) + (uintptr_t) & vnet_entry_xstats))) / sizeof(counter_u64_t)); i++) 10 ((*(__typeof(vnet_entry_xstats) *) (((((__curthread())->td_vnet))->vnet_data_base) + (uintptr_t) & vnet_entry_xstats)))[i] =3D counter_u64_alloc((0x0002)); 11 } while (0); 12 } In essance what looks so complicated is (on a per vnet base): void *array[16]; for (i=3D0 ; i<16; i++) array[i] =3D alloc(); The above (with the vnet bits), on i386, is translated into: 00000340 : 340: 55 push %ebp 341: 89 e5 mov %esp,%ebp 343: 56 push %esi 344: 50 push %eax 345: be c0 ff ff ff mov $0xffffffc0,%esi 34a: 90 nop 34b: 90 nop 34c: 90 nop 34d: 90 nop 34e: 90 nop 34f: 90 nop 350: c7 04 24 02 00 00 00 movl $0x2,(%esp) 357: e8 fc ff ff ff call 358 358: R_386_PC32 counter_u64_alloc 35c: 64 8b 0d 00 00 00 00 mov %fs:0x0,%ecx 363: 8b 89 1c 03 00 00 mov 0x31c(%ecx),%ecx 369: 8b 49 1c mov 0x1c(%ecx),%ecx 36c: 89 84 31 88 14 00 00 mov %eax,0x1488(%ecx,%esi,1) 36f: R_386_RELATIVE *ABS* 373: 83 c6 04 add $0x4,%esi 376: 75 d8 jne 350 378: 83 c4 04 add $0x4,%esp 37b: 5e pop %esi 37c: 5d pop %ebp 37d: c3 ret Now here's the problem: __start_set_vnet is 0x1448 __stop_set_vnet is 0x1488 The problem is that the code generated goes like this: %esi =3D -64 repeat: %eax =3D alloc() We do all the curthread->td_vnet->vnet_data_base in %ecx and then do mov %eax,0x1488(%ecx,%esi,1)=20=20=20 Which is: move the alloc() result into curthread->td_vnet->vnet_data_base + 0x148= 8 + (1 * -64) Now 0x1488 - 64 gets us to the beginning of the array[] or array[0]. %esi +=3D 4 So next iteration it'll be 0x1488 - 60 or array[1] ... and so on. while %esi !=3D 0 goto repeat; It's an easy way to to the for(i=3D0; i<16; i++) loop. The problem is that 0x1488 was not relocated. When we are going over the relocations and calling into elf_relocaddr() the check for VIMAGE is: if (x >=3D ef->vnet_start && x < ef->vnet_stop) { In our case we have an *ABS* R_386_RELATIVE of 0x1488, which is =3D=3D ef->vnet_stop but not < ef->vnet_stop. The real problem is that with non-simple-types the code generated with an absolute relocation might be just outside the range. We cannot adjust the check as there might be a simple-type following in the next section which w= ould then be relocated. For CARP this showed up because the VNET_PCPUSTAT_DEFINE() went into the VN= ET section the last and hence the problem showed up. If there was any other, = say int V_Foo after it, we'd never have noticed. We cannot fully control the order in which symbols go into the section, or at least not to the extend w= e'd like to, so we cannot make sure there's always a char at the end. The only solution arichardson and I agreed to would be to add 1 byte of pad= ding to the end of the section. Using BYTE(1) in a linker script however would always create a set_vnet sec= tion in all kernel modules even if they do not have any virtualized objects. Using a https://sourceware.org/binutils/docs-2.31/ld/Output-Section-Discarding.html= #Output-Section-Discarding . =3D . + <0|sym>; should not create the section. This leads to a multi-stage solution: (1) add a symbol based on SIZEOF(set_vnet) which is either 0 or 1. SIZEOF= () does not create a section if it does not exist. (2) pass the *(set_vnet) through and then increment "." by the amount of the symbol from (1); which if there is a section it will increase the section b= y 1 byte and any non-simple-type objects resulting in absolute relocations on t= he boundary should also be relocated. If there is no section . =3D . + 0; wil= l not create the empty section. The problem is that the symbol from (1) relies on the section size to be kn= own which we don't seem to in the first pass. The second problem is that the symbol from (1) is not immediately visible (despite it should me; XXX sourceware reference for that) So we really have to do multiple linker invocations with different linker scripts. With ld.bfd an empty set_vnet section will not show up, only the symbol from (1) will be left behind and that's fine. With ld.lld 6 it will also leave an empty set_vnet section behind; emaste points me to https://reviews.llvm.org/rL325887 where this had been under discussion already with dim, him, and lld developers. It's not beautiful,= but should not harm either (XXX to be tested). We need to exclude "firmware" from the dance and for now make it i386 speci= fic. The entire problem described above for VNET also applies to DPCPU (set_pcpu= ). I'll attached a preliminary patch which seems to hack this together and onc= e I added a bit more description etc to the files, I'll put it into Phab as well (if you have comments earlier let me know). I hope this all kind-of makes any sense ;-) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Oct 10 15:13:38 2018 Return-Path: Delivered-To: freebsd-toolchain@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 D956810B3B83 for ; Wed, 10 Oct 2018 15:13:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 72BAE8476C for ; Wed, 10 Oct 2018 15:13:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3438910B3B82; Wed, 10 Oct 2018 15:13:38 +0000 (UTC) Delivered-To: toolchain@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 22B9410B3B81 for ; Wed, 10 Oct 2018 15:13:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF43884764 for ; Wed, 10 Oct 2018 15:13:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0822720F5B for ; Wed, 10 Oct 2018 15:13:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9AFDawC081038 for ; Wed, 10 Oct 2018 15:13:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9AFDaIi081036 for toolchain@FreeBSD.org; Wed, 10 Oct 2018 15:13:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230857] loading carp module panic i386 kernel (VIMAGE related) Date: Wed, 10 Oct 2018 15:13:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: panic, toolchain, vimage X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 15:13:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230857 --- Comment #6 from Bjoern A. Zeeb --- Created attachment 198004 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D198004&action= =3Dedit kmod.mk adjustments along with two new linker scripts --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Oct 10 19:18:59 2018 Return-Path: Delivered-To: freebsd-toolchain@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 8099710B9AEA for ; Wed, 10 Oct 2018 19:18:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5228E58C for ; Wed, 10 Oct 2018 19:18:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D20DA10B9AE9; Wed, 10 Oct 2018 19:18:58 +0000 (UTC) Delivered-To: toolchain@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 C09EA10B9AE8 for ; Wed, 10 Oct 2018 19:18:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61DF48E589 for ; Wed, 10 Oct 2018 19:18:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B8A0B23107 for ; Wed, 10 Oct 2018 19:18:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9AJIvAG052815 for ; Wed, 10 Oct 2018 19:18:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9AJIvBW052812 for toolchain@FreeBSD.org; Wed, 10 Oct 2018 19:18:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 231952] emulators/rpcs3: clang crashes during build Date: Wed, 10 Oct 2018 19:18:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 19:18:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231952 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #5 from Dimitry Andric --- Reduced and submitted as https://bugs.llvm.org/show_bug.cgi?id=3D39246 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Oct 10 21:45:32 2018 Return-Path: Delivered-To: freebsd-toolchain@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 B88CD10BD505 for ; Wed, 10 Oct 2018 21:45:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5595C73408 for ; Wed, 10 Oct 2018 21:45:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1716110BD504; Wed, 10 Oct 2018 21:45:32 +0000 (UTC) Delivered-To: toolchain@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 05DC010BD503 for ; Wed, 10 Oct 2018 21:45:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B92373405 for ; Wed, 10 Oct 2018 21:45:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C9F5724620 for ; Wed, 10 Oct 2018 21:45:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9ALjUBg082960 for ; Wed, 10 Oct 2018 21:45:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9ALjUQ3082957 for toolchain@FreeBSD.org; Wed, 10 Oct 2018 21:45:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 220590] math/fftw3: fails to build on armv6 (729 ports skipped) Date: Wed, 10 Oct 2018 21:45:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jhale@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 21:45:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220590 --- Comment #12 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Wed Oct 10 21:44:42 UTC 2018 New revision: 481771 URL: https://svnweb.freebsd.org/changeset/ports/481771 Log: math/fftw3: drop FreeBSD 11.1 support per EOL PR: 220590 (for tracking) Changes: head/math/fftw3/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Oct 10 22:13:49 2018 Return-Path: Delivered-To: freebsd-toolchain@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 5B5A910BE215; Wed, 10 Oct 2018 22:13:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 014FD743EC; Wed, 10 Oct 2018 22:13:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 182F510A87D; Wed, 10 Oct 2018 18:13:46 -0400 (EDT) Subject: Re: base/binutils vs. /usr/local/lib references and also: undefined reference to `pthread_create' (powerpc64 targeting example) To: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML References: <4C338B84-1179-4569-A964-CA18A22AF1D7@yahoo.com> From: John Baldwin Message-ID: <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> Date: Wed, 10 Oct 2018 15:13:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 10 Oct 2018 18:13:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 22:13:49 -0000 On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: > [Actually devel/gettext-tools is a build time dependency: it should not be using > libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=. . . > It looks like the /usr/local/lib references are correct but the wrong linker was > being used. About 5 other ports have a similar status for making base/binutils > as a cross build.] base/binutils should not be pulling in any other ports at all. Everytime I've built it it has had no other dependencies beyond pkg. As far as I'm aware, the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are ports-mgmt/pkg, base/gcc, and base/binutils. > On 2018-Oct-5, at 11:00 PM, Mark Millard wrote: > >> In trying to follow the base/binutils part of https://wiki.freebsd.org/ExternalGCC >> (or /usr/ports/base/README) for targeting powerpc64 I got: >> >> ( My /etc/make.conf has: WRKDIRPREFIX?=/wrkdirs .) >> >> # cd ../../base/binutils/ >> # make CROSS_TOOLCHAIN=powerpc64-gcc CROSS_SYSROOT=/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld package >> . . . > > Note: This should involve building devel/gettext-tools targetting amd64 > (the host environment in this example) because devel/gettext-tools is > a build-time dependency, not to be run on the target system. Maybe install gettext on your system first before doing the build. Probably the CROSS_* aren't stripped from the environment when building dependencies. > May be if devel/gettext-tools had been pre-built and installed > before trying the CROSS_TOOLCHAIN=powerpc64-gcc > CROSS_SYSROOT=/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld > based build activity it would have been okay? > > [I try such later below and report on the results.] > > There are no words on https://wiki.freebsd.org/ExternalGCC or > in /usr/ports/base/README for such special build-sequence > instructions. You're maybe the 3rd person trying it. :-/ >> (It is also unclear how the process involving base/* mixes with doing >> later FreeBSD updates from source --including any use of a delete-old >> step if WITHOUT_BINUTILS= is used at the time. For the cross buildworld >> itself it is not clear what options are intended.) So I plan on having a freebsd-gcc.mk (or freebsd-cc.mk) toolchain file that base/gcc will install that will set WITHOUT_BINUTILS and some other things. I have manually done that for now when building world inside a MIPS qemu instance using base/binutils and base/gcc as the native toolchain. Once I have a build that actually finishes I plan to add the toolchain to the port and then have Makefile.inc1 automatically include the file it is present. >> Notes about some typos on: https://wiki.freebsd.org/ExternalGCC >> >> /usr/ports/devel/ports-mgmt/pkg should be: >> /usr/ports/ports-mgmt/pkg >> >> 3 examples of CROSS_TOOCLAHIN should be: >> CROSS_TOOLCHAIN Fixed. >> Notes about the /usr/ports/base/README : >> >> No mention is made of the pkg build so that it can be >> set up on the target. Only https://wiki.freebsd.org/ExternalGCC >> has that information. /usr/ports/base/README does not >> reference https://wiki.freebsd.org/ExternalGCC either. The README predates the wiki page by a fair bit. The current known issue I need to get back to with base/gcc is that it improperly looks for libraries in /usr/lib when --sysroot is used. I need to get that fixed so that a buildworld via base/gcc works correctly and then I will probably get back to working on more of the todo items on the wiki page. -- John Baldwin                                                                              From owner-freebsd-toolchain@freebsd.org Wed Oct 10 22:49:45 2018 Return-Path: Delivered-To: freebsd-toolchain@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 4018610BF138 for ; Wed, 10 Oct 2018 22:49:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D09C97582A for ; Wed, 10 Oct 2018 22:49:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 94F9510BF137; Wed, 10 Oct 2018 22:49:44 +0000 (UTC) Delivered-To: toolchain@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 838A410BF136 for ; Wed, 10 Oct 2018 22:49:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 255F275826 for ; Wed, 10 Oct 2018 22:49:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6BDD624EA0 for ; Wed, 10 Oct 2018 22:49:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9AMnhwl034663 for ; Wed, 10 Oct 2018 22:49:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9AMnh1b034662 for toolchain@FreeBSD.org; Wed, 10 Oct 2018 22:49:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230857] loading carp module panic i386 kernel (VIMAGE related) Date: Wed, 10 Oct 2018 22:49:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: panic, toolchain, vimage X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 22:49:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230857 --- Comment #7 from Bjoern A. Zeeb --- https://reviews.freebsd.org/D17512 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Oct 11 00:19:55 2018 Return-Path: Delivered-To: freebsd-toolchain@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 B677710C0B02 for ; Thu, 11 Oct 2018 00:19:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-9.consmr.mail.gq1.yahoo.com (sonic315-9.consmr.mail.gq1.yahoo.com [98.137.65.33]) (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 3D33677EE3 for ; Thu, 11 Oct 2018 00:19:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZegNRuYVM1m2bxJtHZKB5zq32IMpeKVD5oKQkGjPQCL2RQJSZpMJglwkWNLyVaO hierI6xO..PZ3sT8A.TowLlcKDhzcyUuxhwdlWXGCsideGjQnte8B8Cef9m77PgqATrw5hR4Ybt4 J4NeDm0t_edJG0mL.75TximM_llUjY.hCzt0YbjapSj_XD9SqCpfchjczUEpOUDK8zDKxsrzv3OQ HqIIVGiMQ0EHVjnTD9Md6_2.EICzpAtbm.54KguK5KB2ProZyvAsQAAoMAK7vgKRGOFZF8fjctjm ZhegYHPtLwXhtJC68N7vUGpXo01UIcHsfYhZPmZW5DB7PzW0msOYSMuoupQbOjOkb7YMdlLX03ng gxSiuaZzqv76GSdZ.ofjWqYPxSw.EcrOIYdit2FuWPJ6AG1_0Cb76OBl_xhFQGcTtlnvHOohrwZC 2ahRvC4lJ69hqr7iGnWXxf2jkCLfakmRHeE117fPaLLwVgqh2pTZZfARFg2T4nGwuwUv8PanI9OP RB8q2yOijD95fQ5TAlt6wBIZb06oNuO7kO36bODWp5prpWzrTKPFeT8Thu02.BfVRWRuch_J504Z S3eAqjM0YUn8tUDYlHe4xI95g3DuYS555exG4phroBTL1GaROUerv8UNGw2mlyQ2s_vr7Wa5xHJY Ew9uY6EHuPWWc53Wf5eLqf7qgmkSM3BrV2DVdVr0RuSHjEiTW3MX4DWsMH6Eq.xbHmFM4QvLRTby rdI9w0M5EflHlORci.QYt05RFtHnFNFYaDYC57jzKgOZAopbLbOUJSwXq7M0qPHEQfI2ZiSxBLuF HNSph8hd3UfngorePSwt09IHWQmqdGMX9p_mRvFsqLTpJgvbfABgTH6FMERsHB_gxKveJnbYjFVn fv1qomujrwcVxXCMudPu3QoAoovYGU08yAEMRhn6nQojt2gII7ZZS9lf14ZKpPGR9b9d7KzfyQiT ShAG5ycVsGLJh_TA35QxZJApvKg2q_KS0PNlN.U7Q1XVoXOi6F1YYcvdI14MpawKcKK4NNVPrtOL _zI.rsDE5muJoSbBPB7tRP.x.eLK2vbvVgbNntWxrsYbw99BuIjWSynsaV1K4hjXu7.5sMcVcpbq JWD.rKtQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Oct 2018 00:19:54 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dec724c1e4b3d40b3abe02b231b9bed8; Wed, 10 Oct 2018 23:59:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: base/binutils vs. /usr/local/lib references and also: undefined reference to `pthread_create' (powerpc64 targeting example) From: Mark Millard In-Reply-To: <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> Date: Wed, 10 Oct 2018 16:59:33 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C338B84-1179-4569-A964-CA18A22AF1D7@yahoo.com> <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 00:19:55 -0000 On 2018-Oct-10, at 3:13 PM, John Baldwin wrote: > On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: >> [Actually devel/gettext-tools is a build time dependency: it should = not be using >> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc = --sysroot=3D. . . >> It looks like the /usr/local/lib references are correct but the wrong = linker was >> being used. About 5 other ports have a similar status for making = base/binutils >> as a cross build.] >=20 > base/binutils should not be pulling in any other ports at all. = Everytime I've > built it it has had no other dependencies beyond pkg. As far as I'm = aware,=20 > the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are > ports-mgmt/pkg, base/gcc, and base/binutils. If devel/gettext-tool is already installed, things just work. In such a context the dependency is less likely to be noticed. >> On 2018-Oct-5, at 11:00 PM, Mark Millard = wrote: >>=20 >>> In trying to follow the base/binutils part of = https://wiki.freebsd.org/ExternalGCC >>> (or /usr/ports/base/README) for targeting powerpc64 I got: >>>=20 >>> ( My /etc/make.conf has: WRKDIRPREFIX?=3D/wrkdirs .) >>>=20 >>> # cd ../../base/binutils/ >>> # make CROSS_TOOLCHAIN=3Dpowerpc64-gcc = CROSS_SYSROOT=3D/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld package >>> . . . >>=20 >> Note: This should involve building devel/gettext-tools targetting = amd64 >> (the host environment in this example) because devel/gettext-tools is >> a build-time dependency, not to be run on the target system. >=20 > Maybe install gettext on your system first before doing the build. = Probably > the CROSS_* aren't stripped from the environment when building = dependencies. That is what I did and it worked fine after devel/gettext-tool had already been installed. In general build-time dependencies are more likely to be for the host environment's execution and run-time dependencies are more likely to be for the target's execution. (But if something is both, then likely both forms are needed, tracking HOST vs. TARGET for where used.) I do not see evidence of such considerations in the ports infrastructure. So I expect "install gettext on your system first before doing the build" should be a standard part of the instructions for base/binutils --at least for now. >> May be if devel/gettext-tools had been pre-built and installed >> before trying the CROSS_TOOLCHAIN=3Dpowerpc64-gcc >> CROSS_SYSROOT=3D/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld >> based build activity it would have been okay? >>=20 >> [I try such later below and report on the results.] >>=20 >> There are no words on https://wiki.freebsd.org/ExternalGCC or >> in /usr/ports/base/README for such special build-sequence >> instructions. >=20 > You're maybe the 3rd person trying it. :-/ Long ago I submitted bugzilla reports when I first tried it. A lot of that was addressed later. It was much nicer to explore the 2nd time. And, for what I used this time, even nicer now. >>> (It is also unclear how the process involving base/* mixes with = doing >>> later FreeBSD updates from source --including any use of a = delete-old >>> step if WITHOUT_BINUTILS=3D is used at the time. For the cross = buildworld >>> itself it is not clear what options are intended.) >=20 > So I plan on having a freebsd-gcc.mk (or freebsd-cc.mk) toolchain file > that base/gcc will install that will set WITHOUT_BINUTILS and some = other > things. I have manually done that for now when building world inside = a > MIPS qemu instance using base/binutils and base/gcc as the native = toolchain. > Once I have a build that actually finishes I plan to add the toolchain = to > the port and then have Makefile.inc1 automatically include the file it = is > present. I'm actually only using the pkg cross build and the base/binutils cross build. The existing src.conf/make.conf infrastructure already allowed me to build or cross-build based on devel/powerpc64-gcc (via devel/powerpc64-xtoolchain-gcc) and I've been doing that for years and clang is useful for powerpc ( but not good for buildworld buildkernel ). WITHOUT_BINUTILS=3D use has the consequences that delete-old will delete base/binutils materials (and so base/binutils materials have to be put back afterwards). That is what I've been doing. I actually have the build include clang and set up clang as cc for the target (no bootstrap clang). Clang's powerpc family problems are tied to special aspects associated with buildworld and buildkernel . Right now I've a poudriere-devel building what expanded to 414 ports on the old PowerMac G5, based on system-clang and the base/binutils material. One thing that I use is WITHOUT_LIB32=3D because any modern gcc that I've tried sticks in a R30 use in crtbeginS code that does not follow the powerpc family ABI FreeBSD is based on for this code: 32-bit powerpc code just produces core files on powerpc64 --from the bad dereference of R30 as holding an context-defined address. If I remember right, base/gcc had this problem for targeting powerpc64 as well. If there was a devel/powerpc-gcc and devel/powerpc-binutils and devel/powerpc-xtoolchain-gcc I could do the same for the 32-bit context. >>> Notes about some typos on: https://wiki.freebsd.org/ExternalGCC >>>=20 >>> /usr/ports/devel/ports-mgmt/pkg should be: >>> /usr/ports/ports-mgmt/pkg >>>=20 >>> 3 examples of CROSS_TOOCLAHIN should be: >>> CROSS_TOOLCHAIN >=20 > Fixed. Thanks. >>> Notes about the /usr/ports/base/README : >>>=20 >>> No mention is made of the pkg build so that it can be >>> set up on the target. Only https://wiki.freebsd.org/ExternalGCC >>> has that information. /usr/ports/base/README does not >>> reference https://wiki.freebsd.org/ExternalGCC either. >=20 > The README predates the wiki page by a fair bit. Ahh. I see. > The current known issue I need to get back to with base/gcc is that it > improperly looks for libraries in /usr/lib when --sysroot is used. I = need > to get that fixed so that a buildworld via base/gcc works correctly = and then > I will probably get back to working on more of the todo items on the = wiki > page. >=20 Other than when I explicitly go to test base/gcc, I do not see such because I use the src.conf/make.conf ways of putting devel/powerpc64-gcc and such to use and have the build include clang as cc: no use of base/gcc. I've not tested base/gcc in a long time. I do this style of buildworld buildkernel on the PowerMac G5's too: a = sort of "self hosted cross build". =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Thu Oct 11 04:50:34 2018 Return-Path: Delivered-To: freebsd-toolchain@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 846B510CEF90 for ; Thu, 11 Oct 2018 04:50:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 1460E84861 for ; Thu, 11 Oct 2018 04:50:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Ad0pBmYVM1kWNwxV2gZ6UcxOxlk.ZKHShKro60XGQRXYKVOPTiw6ScgMPl.2XMN C4ZOstrKIPu0KsFtim81QnakMcHLYfllTiLsay7A.lqfyzUrRudFy6tSrl8bdRjK4RioMO7hKKG9 v.buvZJOTKD4WZ8QxgSbXzdxfdQYAK9zHNrszIyaxd9rmCTK4mD7XJWh_FJaPLodByzY83.Tu6FP gEvkPSkUKBXvHjEEYXNO7bHFkQ2CW.1loD66_mKmixmZd67Un0OZfHiP_dKJV7ZuL4GppOxkOukZ VxOItXG_Vh_4dLvFyKcB8D18S1_9OKkV8V1oV5kVeIFFYmmyPSEQ11VquHMPTOgJJC2JL8EJS0a3 u7L21Cq1JFlWZTTxzK0FZXi.YKuI_4m2SUHNx4FPs0ABoNChyBdELvm8SrpecVOynQYWfH9yUDV9 wLt6uwZH89boeDAfKf2Jaaf3_eEnSIP3XmePsIvE61miDPYWVGQ8D6CRDDq0cJh8jT4HCl15aTKn amc5hgEDuqy2k_lMUhOvvNdLCKVpl94xTe6N8.ypqKhHKUSjBROwCp7eTPkwgTy7U.n0JShGbVGA pvBme0NLfRF5JDGdnWRO7LC5bc3dVMTpcYHLWdCUXuLBa5cKcItzaks5qyWtBZAVMqEH_nRfzvZ_ TaXJZXRYJtpfDECYioMBXEFViBBiycEyRV3UO8rCUwLWTIc7Ga6DcfyMAn9vOCQpx3xTK7qm9HaI 1oJp8ExnKl.9pSwW.CMQ1qNVueE.xCmD._jcK7qZQh0aSOF0ZtXVTmlmK4xezDb467jsl_lSzUf3 9MT3fUm.bixgci4d4MQGabSycw1hSqb_NT8VWJXVQgx5CRNLdILxRwqUHzK7qmkAaKsB7pq8ZbKf JQYDcN7jM45NURSp18GYUuC9wTVxFftN1tEENQQFkXGfHRrEek66HfYkOFr.HdEQS0K5H8dTGbyl 8NoOY_Dtdlt5GsAhk5fwAvZF5Yl1VhXjq9_f18bdbPWqraBkdrrJOAFRGaYHNRyWSyLfFQiifRYV JPCX6zuKl8CR_VuuYATc1vhpnKK.jBtKMT3UFnTFgParL.p2sPeI_mJ7S8fzlwW1u2MeT7Z0liMd CJ98ikdaNvlmODw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Oct 2018 04:50:27 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp427.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 589737411686f8e493cdda52d667a76e; Thu, 11 Oct 2018 04:40:17 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined" Message-Id: <1B7575F6-ED4D-42FE-BD51-B976F21B7CA6@yahoo.com> Date: Wed, 10 Oct 2018 21:40:17 -0700 Cc: Jan Beich To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 04:50:34 -0000 The following is on a powerpc64 machine (old PowerMac G5 so-called "Quad Core") running a personal build of head -r339076 that was built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1). The compiler for the port build is system-clang (so clang 6 as cc), not used for buildworld buildkernel. [I experiment with more modern compilers and toolchains for some powerpc family members.] The system is using base/binutils materials, such as for the system-linker. (lld is not yet reasonable for powerpc64 as I understand and the old system-binutils' ld is not sufficient either.) The port build is via ports-mgmt/poudriere-devel with -w . But it looks like the /tmp/control-* files are not captured. It will probably be 12 hours or more before the bulk build finishes, then more time before I investigate/reproduce and get such files. But for now here is an extraction from the log file: --- control.lo --- /bin/sh ../../libtool --tag=3DCC --mode=3Dcompile cc -DHAVE_CONFIG_H = -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files = -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF = .deps/control.Tpo -c -o control.lo control.c . . . --- control.lo --- libtool: compile: cc -DHAVE_CONFIG_H -I. -I../../include = -I../../include -I/usr/ports/audio/alsa-lib/files -O2 -pipe -g = -fno-strict-aliasing -MT control.lo -MD -MP -MF .deps/control.Tpo -c = control.c -fPIC -DPIC -o .libs/control.o . . . --- control.lo --- fatal error: error in backend: A @@ version cannot be undefined cc: error: clang frontend command failed with exit code 70 (use -v to = see invocation) FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. cc: note: diagnostic msg:=20 ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/control-696205.c cc: note: diagnostic msg: /tmp/control-696205.sh cc: note: diagnostic msg:=20 ******************** *** [control.lo] Error code 1 make[3]: stopped in = /wrkdirs/usr/ports/audio/alsa-lib/work/alsa-lib-1.1.2/src/control 1 error For reference: [06:50:02] [04] [00:02:54] Saved audio/alsa-lib | alsa-lib-1.1.2_1 = wrkdir to: = /usr/local/poudriere/data/wrkdirs/FBSDpowerpc64-default/default/alsa-lib-1= .1.2_1.tbz [06:50:05] [04] [00:02:57] Finished audio/alsa-lib | alsa-lib-1.1.2_1: = Failed: build [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-archiver | = lumina-archiver-1.4.1: Dependent port audio/alsa-lib | alsa-lib-1.1.2_1 = failed [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-calculator | = lumina-calculator-1.4.1: Dependent port audio/alsa-lib | = alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping x11/lumina-core | lumina-core-1.4.1: = Dependent port audio/alsa-lib | alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping x11/lumina-coreutils | = lumina-coreutils-1.4.1: Dependent port audio/alsa-lib | alsa-lib-1.1.2_1 = failed [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-fileinfo | = lumina-fileinfo-1.4.1_1: Dependent port audio/alsa-lib | = alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-fm | = lumina-fm-1.4.1: Dependent port audio/alsa-lib | alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-mediaplayer | = lumina-mediaplayer-1.4.1_1: Dependent port audio/alsa-lib | = alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-screenshot | = lumina-screenshot-1.4.1: Dependent port audio/alsa-lib | = alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping deskutils/lumina-textedit | = lumina-textedit-1.4.1_1: Dependent port audio/alsa-lib | = alsa-lib-1.1.2_1 failed [06:50:07] [04] [00:02:59] Skipping multimedia/qt5-multimedia | = qt5-multimedia-5.11.1: Dependent port audio/alsa-lib | alsa-lib-1.1.2_1 = failed =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Thu Oct 11 15:39:31 2018 Return-Path: Delivered-To: freebsd-toolchain@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 0D5DA10BE6E8 for ; Thu, 11 Oct 2018 15:39:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.ne1.yahoo.com (sonic310-22.consmr.mail.ne1.yahoo.com [66.163.186.203]) (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 8CDFC75643 for ; Thu, 11 Oct 2018 15:39:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sP8.EjQVM1kKHA_VGwgTPolBaHiDUxUT3AkMKplUKmgxvBFllZFVgjkTeD.CXZN qaxlWZY0ZfrJ_JY1gB95R738sTlR38bMeuTNhvJqGlTA3sRMREPO14c6KmLquWVQYa4wwoW9UjhV iYKy2KQT0694KrtWyzO1umcKKJaHriCNJ16vVjJw.d9yCEOJ1J_EVAyVRGZAVxJWMck9dgdJkRNK 3quCw8QLXZlRPyyrDo7T_rvwgBB.CYnWvTGZKNyH9mljiAjXnE4WdlFxZ29W7o_gxCo2n9NTKmzl QBZJhCx4RqExgX9d_c3ZsKF.dddMS4ISaiuFQMWr9GSf7pkRs2eEwtfyueQ68D4iEgyy5ZjPPq1v v911jBG11iOLoSIKRdM6cJVKWeO_nVAlSGxV1xd5O6m90grhCpyiB3K6NBi5aziEhci4r7hBLbU4 QV9zYB1RBfWb5Wv3SeAXwY6E1s55osP.hIcJMTpnrBlQR5chzfqKhRzcu3c_IpJ8hbf8Qxk.ZJCM b.XPYeF8F4W6gkWT7akEfeGkO.6EMRemdLQtPMSzLeVa7i7krSI_B5kXVCND.S9_LzK1iGndkcAP sBV.LLik9uvkYCOmcIb5RWQ7yfDC1Dbsd02qdG3rG7v5tR0mnW7PWvsiZSRIBcKC08HbIpm8si4U feVeOhdJp0PRn0ZfHUd7UP9Ls6UQgUx2HtCopXos4CvDR92tkXkk_FKPJoY4._WAhL8QZq75AYrb oEY8AxgATzA56jjtgWZHxkw3PegJcsiZnOiCNW_DJoXUFLqVDtkwUhkOMCwuc81YPbn.JCvux8F4 hVzzOyYg3FzfS6.kFM3xF7i9fT_gSJODnab2Ia9m3E_IvgB9cjT6BRvYJ24ofrKDYHru_Coy9Q_x mclW0dsWdlOeKxsPp8NJfk84XThRz8iXAdeKxg4E88RImGlDswGqGk0SZ84LrKfjsNiDWOKmPqyk jsm3rIqehG396IvFgpCghuthObhZsyBzv4U4Qn_PIjAqWTg7Ni6lR86rnUFlGECos1Yw_st7Segx yctu6PIRct5RM6F0xjKWgOBZnrCBBun8jybP7gWFwVGj50iKwvSe48gy2w0ZqEHPbrcUWPPr9ScA uygR0xw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Thu, 11 Oct 2018 15:39:23 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 016c2ad776b4e99de9adbf3f9aa3e0a7; Thu, 11 Oct 2018 15:39:19 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: xmlcharent-0.3_2 and iso8879-1986_3 package reinstalls: "pkg: POST-INSTALL script failed"? Message-Id: <156D3788-3987-40AF-BE9B-4DDC8FC53600@yahoo.com> Date: Thu, 11 Oct 2018 08:39:17 -0700 Cc: FreeBSD PowerPC ML To: FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 15:39:31 -0000 In updating a powerpc64 context after a poudriere-devel bulk run, I got the following from pkg upgrade . . . Installed packages to be REINSTALLED: xmlcharent-0.3_2 (ABI changed: = 'freebsd:12:powerpc:64' -> 'freebsd:12:*') . . . iso8879-1986_3 (ABI changed: 'freebsd:12:powerpc:64' -> = 'freebsd:12:*') . . . [127/181] Extracting iso8879-1986_3: 100% xmlcatmgr: entry already exists for = `/usr/local/share/sgml/iso8879/catalog' of type `CATALOG' pkg: POST-INSTALL script failed . . . [138/181] Extracting xmlcharent-0.3_2: 100% xmlcatmgr: entry already exists for = `/usr/local/share/xml/xmlcharent/catalog' of type `CATALOG' xmlcatmgr: entry already exists for = `/usr/local/share/xml/xmlcharent/catalog.xml' of type `nextCatalog' pkg: POST-INSTALL script failed The context is a personal head-based -r339076 buildworld buildkernel (it was cross built) and ports being updated based on -r480180 . Is there anything that I should do because of the messages? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Oct 12 13:00:53 2018 Return-Path: Delivered-To: freebsd-toolchain@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 D674510BBDDD; Fri, 12 Oct 2018 13:00:53 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8695A81622; Fri, 12 Oct 2018 13:00:53 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 5DD52A606; Fri, 12 Oct 2018 13:00:53 +0000 (UTC) From: Jan Beich To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined" References: <1B7575F6-ED4D-42FE-BD51-B976F21B7CA6@yahoo.com> Date: Fri, 12 Oct 2018 15:00:49 +0200 In-Reply-To: <1B7575F6-ED4D-42FE-BD51-B976F21B7CA6@yahoo.com> (Mark Millard's message of "Wed, 10 Oct 2018 21:40:17 -0700") Message-ID: <8t33-9v5q-wny@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 13:00:54 -0000 Mark Millard writes: > The following is on a powerpc64 machine (old PowerMac G5 so-called > "Quad Core") running a personal build of head -r339076 that was > built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1). > The compiler for the port build is system-clang (so clang 6 as cc), > not used for buildworld buildkernel. [I experiment with more modern > compilers and toolchains for some powerpc family members.] [...] > /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H > -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files > -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF > .deps/control.Tpo -c -o control.lo control.c [...] > fatal error: error in backend: A @@ version cannot be undefined > cc: error: clang frontend command failed with exit code 70 (use -v to see invocation) > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) > Target: powerpc64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin Looks easy to reproduce on amd64 via -target e.g., $ cd /usr/ports/audio/alsa-lib $ make clean configure $ cd $(make -V WRKSRC)/src/control $ ln -s ${SYSDIR:-/usr/src/sys}/powerpc/include /tmp/machine $ make control.lo CC='cc -target powerpc64-unknown-freebsd12.0 -isystem /tmp' [...] fatal error: error in backend: A @@ version cannot be undefined cc: error: clang frontend command failed with exit code 70 (use -v to see invocation) FreeBSD clang version 7.0.0 (tags/RELEASE_700/final 342383) (based on LLVM 7.0.0) which points to the following conditional #ifdef __powerpc64__ # define symbol_version(real, name, version) \ __asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@" #version); \ __asm__ (".symver ." ASM_NAME(#real) ",." ASM_NAME(#name) "@" #version) # define default_symbol_version(real, name, version) \ __asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@" #version); \ __asm__ (".symver ." ASM_NAME(#real) ",." ASM_NAME(#name) "@@" #version) #else # define symbol_version(real, name, version) \ __asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@" #version) # define default_symbol_version(real, name, version) \ __asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@" #version) #endif and can be further reduced to int main() { __asm__ (".symver __foo,foo@@FOO"); __asm__ (".symver .__foo,.foo@@FOO"); } From owner-freebsd-toolchain@freebsd.org Fri Oct 12 13:51:57 2018 Return-Path: Delivered-To: freebsd-toolchain@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 84A2710BED22 for ; Fri, 12 Oct 2018 13:51:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 2D17E83926 for ; Fri, 12 Oct 2018 13:51:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: usM2PhYVM1kKiLi0V3eEcgmDEVZmI2QqpNo8P297am_kMznZjOfq06veKwZkbsf S8_13PZzuSpKCfCR1lXOqdh493uv4fvVHmD3H0GDNVT7mCmWF0lowKY9OT_ZqJ0rv8KFfc9ruyui chNyIlQGykKTd.xHqJDb9_DLP7wBPzJxv01ermn9GGwg.1dE6btVOJmtZWKZP.7PSczC24flOY6M L9ZMb869wtFHpldhFSxfZqmm8fyGKc61_aFHZnUG0yTZYDuRIwxJvPG0RXwzx57wIyl6HkHpIyuz umihGpeV8WXjFO5V7ONzJjdzNhV2idBoFG6cQkYbg61sGEaQokyy4bOf0Tol0Qua.bekZaIZxfHT mhNyiDO8Z0bg4gZMqcoCRDBbcUQIleVzAXrSvpAFZo92OCsNK23y2a0QcI.T37Db6zlzvpCw90wR 3hQU1FVdTA6QVsnNBDI1zR7dEDedCxg5CBBPD.Z373._91oC_0yKzpZKSBayXaKL4GrkVCXFYZ_U ND3Y2XYuGCDhZmATVvvCSj6XS9qc_LLMtmf7CfCw4q7DCASA5jlDrWN35oj6g6wTOPjb8BRshFeC U2Pe0BWXB7ke18HtGGTxoyPlRJ1BlXMHZo66DukWPrFkRsn5HHA46SRtlJx87i1fDOoI1DoRLce4 OMIMOq4wowwKHaF8ScF2Ca.bmLvIK7RHIatqqnZgOiPJV_gaeuSMpGtu1laTd7UAxX_3B6ZU62_7 PiqJmVh2ALsaO72P7w9rf69npqz9jVUEbHXUrPayqwZV2g3ZMqUYRLpH1v8mHlZMaNyh_GJraGSk Oc74TiY_nP.UNBBWaMQgWvHF35ODcfqxjM.dqPLrdPp0ZxUUbKC9BeP.AXmKxfvc7V5ZGer84vZB 8xWGBXrz9BdgVU0PbZeU3U2AI3AKTV4oEpGoDvjadOC1AGKyu8MovVSrUks8gD9yjrZtfWYOWNCn VskgrmRH8DECJiPvzECtrII7EjcTHRyJOFiwDu.Xx0hkfgE.v6SBwbfChEmJIZhDIJjA.dcHriJL AXJV7sa5Hdbn856TjfE29_XZXQFlzexefM03CACG_G9u8SlLji8L4pCMJKGtNI2Arz5yh571n2sB 9sIAFScOjep8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 12 Oct 2018 13:51:56 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bf21e8408964bb0de38e6ed012fee1d6; Fri, 12 Oct 2018 13:51:56 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build Message-Id: <925D3E9A-4EF0-4B49-83D4-C9574170EB66@yahoo.com> Date: Fri, 12 Oct 2018 06:51:54 -0700 To: John Baldwin , FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 13:51:57 -0000 The following is from attempting to build devel/powerpc-gcc via poudriere-devel on the powerpc64 system after having bootstrapped via (in part) base/binutils and the .txz produced on the host (amd64). Looks like having both: /usr/bin/powerpc64-unknown-freebsd12.0-* and: /usr/local/bin/powerpc64-unknown-freebsd12.0-* in a powerpc64 environment confuses "phase: build-depends" in poudriere for the devel/powerpc64-gcc build: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> powerpc64-gcc-6.4.0_2 depends on executable: = powerpc64-unknown-freebsd12.0-as - found I.e., poudriere finds /usr/bin/powerpc64-unknown-freebsd12.0-as and concludes that devel/powerpc64-binutils does not need to be installed for the devel/powerpc64-gcc to build. Eventually this leads to aborting based on gcc's config noticing an oddity: . . . checking for ld used by GCC... /usr/bin/powerpc64-unknown-freebsd12.0-ld checking if the linker (/usr/bin/powerpc64-unknown-freebsd12.0-ld) is = GNU ld... yes configure: error: cannot execute: = /usr/local/bin/powerpc64-unknown-freebsd12.0-ld: check --with-ld or env. = var. DEFAULT_LINKER This is associated with: CONFIGURE_ARGS+=3D--target=3D${GCC_TARGET} --disable-nls = --enable-languages=3Dc,c++ \ --enable-gnu-indirect-function \ --without-headers \ --with-gmp=3D${LOCALBASE} \ --with-pkgversion=3D"FreeBSD Ports Collection for = ${PKGNAMEPREFIX:C/-//g}" \ --with-system-zlib \ --with-gxx-include-dir=3D/usr/include/c++/v1/ \ --with-sysroot=3D"/" \ --with-as=3D${LOCALBASE}/bin/${BU_PREFIX}-as \ --with-ld=3D${LOCALBASE}/bin/${BU_PREFIX}-ld having the --with-ld not list the */bin/${BU_PREFIX}-ld it actually finds and tests in config ( /usr used instead of ${LOCALBASE} ). If any other port binds to devel/powerpc64-binutils it probably has the same sort of issue. (Unlikely?) This is not likely to be specific to powerpc64 as a base/binutils target: powerpc64 is likely just an example. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Oct 12 14:45:00 2018 Return-Path: Delivered-To: freebsd-toolchain@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 E576610C05FB for ; Fri, 12 Oct 2018 14:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-10.consmr.mail.ne1.yahoo.com (sonic308-10.consmr.mail.ne1.yahoo.com [66.163.187.33]) (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 793FE8587E for ; Fri, 12 Oct 2018 14:44:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5tDIXPkVM1nqBi_rs9XEnOXW9Gk66dqiwPlaM5ARrrgl1B_uefe6Ke1pvn_nwtI wT4e2gsEGrbd9i0isrSySXcfjyoqbycJ3z9yTUfE5stz2XLMbtSahWDOacOLsCiQJJRf3uscI1II Pd.IBv2ZTvEuE8yZc2FdMNvd4i9xANL6GFoH7JPw3fWYIS1fEAq4HLsslroFAvMhMPGZn5Xz5XTA luIBDCsJRbd5YtEdf05yCKlPJ29uXkbUAn7naNExu0cQn3.OrUikQBsq3oa5Ju2ecGqK5trP81Fm d_DZwwYdozMJ30kzIF91PYUCxV7ZXd_HxZY5yk6f7mlfD7557rEpVh636YnJB4dS6w6AfPgtnXtZ XPGTzzxfZeBkSzrc7HxUEPcpOGIh1hm8fAScT50o9zzd3XSbVLL8y5pRHCBj496GDDwPK79Ilp6V wewqkbILGgvj4anfdTv_GmpXFKtBzXqZm8.DqvKyweYrliJPxXHz.5aLZ8E7eGSsLd.8zzSrduf0 vPLTiQnyKcggfOpx9t9_0WfGUSsj7DGOpQ1Ajr8qAslvo2OkrUnzdudIIB9DfZYoBOpLGEqnVeCf wn.HSyKiz0nSQoEcucrukCR7K6WSzj.cHz8ID3TzwkhZ2T27OfQoFkYJWCEZiBe3v_8OMpbw9mde HSXhExyPaVPa.6hQW4iMLc6o.5vhI_0ZPVgzS_UsOiHqnHkygjCOrUCAHV8FeYjtZl3g5wSi1U90 CpK.arJOq34ihSoe1oksSPzuWTzvbl7bQ2tzRUvZ0u3baA5sWrucAu7ktvIkSGiNPOSndzpUk5ta iEBq1snfGGPsTWyU.SW.e9x4q3i3F2QFfNNfFkCA3yPxCBcJZn2OcFtTnmJPAOI3YIv5vyGk9BhL EZcf9AHKh1lZoSAdxr83JjAIeOXmYZ8tQoXXVpb3IZpL8IX0WyzaGo9XyLtDkOIDKZ3Rw1dpHdjG HmndNPHLehLzHpmFfp9WVEHk2cymwPoQerJKsX9DUuZgy_RvdChB35r7YNuGtnQXOA_U9B3Pzmpn q83q2XPQCwFOvAR8_Noltio2VZBWV5s0Jjhf8RIriQv2d.KvYtFH4Nr740JBl5XzRvy3nv2.IOcL xNI6ps8rvuIRj1Spy Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 Oct 2018 14:44:52 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c653ea202ddf8ae0ce4bbcf1f75bf0bb; Fri, 12 Oct 2018 14:44:50 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Two example patches: enable powerpc64 builds of devel/powerpc64-gcc and lang/gcc8 via system-clang ( avoiding clang's reserving vec_step ) Message-Id: <4B3B6F66-9B65-48F3-814B-49528B88EE0E@yahoo.com> Date: Fri, 12 Oct 2018 07:44:49 -0700 Cc: gerald@FreeBSD.org To: FreeBSD Toolchain , FreeBSD Ports ML , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 14:45:00 -0000 [I experiment with using modern compilers on powerpc64, here buildworld buildkernel was via devel/powerpc64-xtoolchain-gcc but included building clang and having clang as cc. clang's problems are tied to aspects of buildworld buildkernel but is otherwise usable.] When clang is built with support for altivec for powerpc* (powerpc64 here) and such it reserves a name not from the C/C++ language standards: vec_step . system-clang has enough enabled for powerpc64 to have reserved vec_step. If devel/llvm* ever enable enough powerpc64 support they would reserve vec_step too. (I've not checked if this is already happening.) Unfortunately, various devel/*gcc and lang/gcc* use that name in gcc/tree-vect-loop.c and so on powerpc64 those various *gcc* fail to build. The below just avoids the extra reserved word by renaming each non-comment vec_step in gcc/tree-vect-loop.c to vec_step_renamed . This has allowed me to build the example *gcc* 's in poudriere-devel on powerpc64 (head -r339076 based). One could imagine sed'ing or otherwise processing gcc/tree-vect-loop.c instead of having patch files. In the examples the original gcc/tree-vect-loop.c files are not the same: one patch for all *gcc* would not work. # svnlite status /usr/ports/devel/powerpc64-gcc/files/ | more ? /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c # svnlite status /usr/ports/lang/gcc8/files/ | more ? /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c # more /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c --- gcc/tree-vect-loop.c.orig 2017-03-28 15:35:56 UTC +++ gcc/tree-vect-loop.c @@ -3832,7 +3832,7 @@ get_initial_def_for_induction (gimple *iv_phi) edge pe =3D loop_preheader_edge (loop); struct loop *iv_loop; basic_block new_bb; - tree new_vec, vec_init, vec_step, t; + tree new_vec, vec_init, vec_step_renamed, t; tree new_name; gimple *new_stmt; gphi *induction_phi; @@ -3986,7 +3986,7 @@ get_initial_def_for_induction (gimple *iv_phi) stepvectype =3D get_vectype_for_scalar_type (TREE_TYPE (new_name)); gcc_assert (stepvectype); new_vec =3D build_vector_from_val (stepvectype, t); - vec_step =3D vect_init_vector (iv_phi, new_vec, stepvectype, NULL); + vec_step_renamed =3D vect_init_vector (iv_phi, new_vec, stepvectype, = NULL); =20 =20 /* Create the following def-use cycle: @@ -4008,7 +4008,7 @@ get_initial_def_for_induction (gimple *iv_phi) induc_def =3D PHI_RESULT (induction_phi); =20 /* Create the iv update inside the loop */ - new_stmt =3D gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, = vec_step); + new_stmt =3D gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, = vec_step_renamed); vec_def =3D make_ssa_name (vec_dest, new_stmt); gimple_assign_set_lhs (new_stmt, vec_def); gsi_insert_before (&si, new_stmt, GSI_SAME_STMT); @@ -4049,7 +4049,7 @@ get_initial_def_for_induction (gimple *iv_phi) gcc_assert (CONSTANT_CLASS_P (new_name) || TREE_CODE (new_name) =3D=3D SSA_NAME); new_vec =3D build_vector_from_val (stepvectype, t); - vec_step =3D vect_init_vector (iv_phi, new_vec, stepvectype, = NULL); + vec_step_renamed =3D vect_init_vector (iv_phi, new_vec, = stepvectype, NULL); =20 vec_def =3D induc_def; prev_stmt_vinfo =3D vinfo_for_stmt (induction_phi); @@ -4057,7 +4057,7 @@ get_initial_def_for_induction (gimple *iv_phi) { /* vec_i =3D vec_prev + vec_step */ new_stmt =3D gimple_build_assign (vec_dest, PLUS_EXPR, - vec_def, vec_step); + vec_def, vec_step_renamed); vec_def =3D make_ssa_name (vec_dest, new_stmt); gimple_assign_set_lhs (new_stmt, vec_def); =20 @@ -6324,13 +6324,13 @@ vectorizable_reduction (gimple *stmt, = gimple_stmt_iter =20 /* Create a vector of the step value. */ tree step =3D build_int_cst (cr_index_scalar_type, = nunits_out); - tree vec_step =3D build_vector_from_val (cr_index_vector_type, = step); + tree vec_step_renamed =3D build_vector_from_val = (cr_index_vector_type, step); =20 /* Create an induction variable. */ gimple_stmt_iterator incr_gsi; bool insert_after; standard_iv_increment_position (loop, &incr_gsi, = &insert_after); - create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi, + create_iv (series_vect, vec_step_renamed, NULL_TREE, loop, = &incr_gsi, insert_after, &indx_before_incr, &indx_after_incr); =20 /* Next create a new phi node vector (NEW_PHI_TREE) which = starts # more /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c --- gcc/tree-vect-loop.c.orig 2018-10-10 22:41:40.295753000 -0700 +++ gcc/tree-vect-loop.c 2018-10-10 22:57:44.698855000 -0700 @@ -4970,13 +4970,13 @@ =20 /* Create a vector of the step value. */ tree step =3D build_int_cst (cr_index_scalar_type, nunits_out); - tree vec_step =3D build_vector_from_val (cr_index_vector_type, = step); + tree vec_step_renamed =3D build_vector_from_val = (cr_index_vector_type, step); =20 /* Create an induction variable. */ gimple_stmt_iterator incr_gsi; bool insert_after; standard_iv_increment_position (loop, &incr_gsi, &insert_after); - create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi, + create_iv (series_vect, vec_step_renamed, NULL_TREE, loop, = &incr_gsi, insert_after, &indx_before_incr, &indx_after_incr); =20 /* Next create a new phi node vector (NEW_PHI_TREE) which starts @@ -7641,7 +7641,7 @@ tree vec_def; edge pe =3D loop_preheader_edge (loop); basic_block new_bb; - tree new_vec, vec_init, vec_step, t; + tree new_vec, vec_init, vec_step_renamed, t; tree new_name; gimple *new_stmt; gphi *induction_phi; @@ -7834,7 +7834,7 @@ new_name =3D vect_init_vector (phi, new_name, TREE_TYPE (step_expr), NULL); new_vec =3D build_vector_from_val (vectype, new_name); - vec_step =3D vect_init_vector (phi, new_vec, vectype, NULL); + vec_step_renamed =3D vect_init_vector (phi, new_vec, vectype, = NULL); =20 /* Now generate the IVs. */ unsigned group_size =3D SLP_TREE_SCALAR_STMTS (slp_node).length = (); @@ -7873,7 +7873,7 @@ =20 /* Create the iv update inside the loop */ vec_def =3D make_ssa_name (vec_dest); - new_stmt =3D gimple_build_assign (vec_def, PLUS_EXPR, = induc_def, vec_step); + new_stmt =3D gimple_build_assign (vec_def, PLUS_EXPR, = induc_def, vec_step_renamed); gsi_insert_before (&si, new_stmt, GSI_SAME_STMT); set_vinfo_for_stmt (new_stmt, new_stmt_vec_info (new_stmt, = loop_vinfo)); =20 @@ -7904,7 +7904,7 @@ new_name =3D vect_init_vector (phi, new_name, TREE_TYPE (step_expr), NULL); new_vec =3D build_vector_from_val (vectype, new_name); - vec_step =3D vect_init_vector (phi, new_vec, vectype, NULL); + vec_step_renamed =3D vect_init_vector (phi, new_vec, vectype, = NULL); for (; ivn < nvects; ++ivn) { gimple *iv =3D SLP_TREE_VEC_STMTS (slp_node)[ivn - nivs]; @@ -7915,7 +7915,7 @@ def =3D gimple_assign_lhs (iv); new_stmt =3D gimple_build_assign (make_ssa_name (vectype), PLUS_EXPR, - def, vec_step); + def, vec_step_renamed); if (gimple_code (iv) =3D=3D GIMPLE_PHI) gsi_insert_before (&si, new_stmt, GSI_SAME_STMT); else @@ -8041,7 +8041,7 @@ gcc_assert (CONSTANT_CLASS_P (new_name) || TREE_CODE (new_name) =3D=3D SSA_NAME); new_vec =3D build_vector_from_val (vectype, t); - vec_step =3D vect_init_vector (phi, new_vec, vectype, NULL); + vec_step_renamed =3D vect_init_vector (phi, new_vec, vectype, NULL); =20 =20 /* Create the following def-use cycle: @@ -8064,7 +8064,7 @@ =20 /* Create the iv update inside the loop */ vec_def =3D make_ssa_name (vec_dest); - new_stmt =3D gimple_build_assign (vec_def, PLUS_EXPR, induc_def, = vec_step); + new_stmt =3D gimple_build_assign (vec_def, PLUS_EXPR, induc_def, = vec_step_renamed); gsi_insert_before (&si, new_stmt, GSI_SAME_STMT); set_vinfo_for_stmt (new_stmt, new_stmt_vec_info (new_stmt, = loop_vinfo)); =20 @@ -8108,7 +8108,7 @@ gcc_assert (CONSTANT_CLASS_P (new_name) || TREE_CODE (new_name) =3D=3D SSA_NAME); new_vec =3D build_vector_from_val (vectype, t); - vec_step =3D vect_init_vector (phi, new_vec, vectype, NULL); + vec_step_renamed =3D vect_init_vector (phi, new_vec, vectype, = NULL); =20 vec_def =3D induc_def; prev_stmt_vinfo =3D vinfo_for_stmt (induction_phi); @@ -8116,7 +8116,7 @@ { /* vec_i =3D vec_prev + vec_step */ new_stmt =3D gimple_build_assign (vec_dest, PLUS_EXPR, - vec_def, vec_step); + vec_def, vec_step_renamed); vec_def =3D make_ssa_name (vec_dest, new_stmt); gimple_assign_set_lhs (new_stmt, vec_def); =20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Oct 12 20:59:47 2018 Return-Path: Delivered-To: freebsd-toolchain@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 9763410CAA07 for ; Fri, 12 Oct 2018 20:59:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 3B0F375D8C for ; Fri, 12 Oct 2018 20:59:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nTrznQcVM1movPyqsSzA_RVJLedC9.cvfhNV_tZVSvF5wh13zbwd2oqHN.6cEeR WelSy2bmlP5bhjiTaJfyP.E5DFOFaAFn9tJE_hFV96sOuBlZyiE0IkN_5GeBPH3XYPrVP5I2FmyG rPrgyp.Xxqnkj5ee1anBH7mWJvE9y5SYSK5m1PalC23fpGzEEBF32tbHA2.22h5H_l1x16Bw6iTs G3jHHR_E.0y04bsE7fBPU26dWrQjB8FHsJfxXr0ZTPsxRg2AwaHYEeXOMiRQUv7eIzNtvZWcYAOs 3WfML2sDay4eEwLsqTOWwfivfR.x6NK25YeZRZ771dT_mstHOaebq6eQ66wgnOGPN9AcAIwoX9nT aMozZEmaVLN8Bq.wFQ05GyYhWUmht0jcyn3wM_alDT7Jh6XZLb0YHN0Bzz1JMFaur.vjkXvxn46N qVS9tAXZpsDlGOQeCU3yDWx46xKHR0q5AJOrpRjL3ZWNtTAabWOgfJhO8WQTV1BXYrIJYZaLX.o7 yStXq.1nGyvzpZuwHo90Zoe1REh8xGfT5AAH2ho3Ivc5MPO3futS7VE7kYHV3kOJ04iM1kTk35Tl r1zn_yUpXTqdAU7.MW9Sm2SzKEEB9xZU3HhSvMyqhmlwHAWm7guKDxQrT225wT3r7vgt6GZY_Zag Oplzx2On.D22XyYSEH9WQYivKHuopBS_dJO93vQsHFJlXSRqoWJ15O8VQ01Te8zl4DtiorTbINGE yFZNQ.RkkBAyDAwtydA.EUfVWAIkcIPFtKWlG6tezPfkC276Nj7ijeDNbV.atiJov58N8vcgFA6m cO1O1qkktp.reKJf0sp9R3Kn0MqeUTV3i0.QYtdb371f4BtfVrU38Vv0Xt0vHa25okMCctcd7.MU arVL8bnMarZNqrtD6aAmYQWhvBz038ZD0hT4d57ARpiGMobY7vH0C5RUCZ2xPK.oGppFxi0nvLQ3 yZWxAac.hG4IWsyTaii5XLhdPVBItk_7.JP7Dn0o7FMWwgzekrUxA4xOtog2yG8skXfr5nkQoYsR V9suaFHo2vZECuB2qdxyqSw5M4v5y_XYKkMZJpCxDzRJvA_ZP9FeF4a_Qb.heQBrzhH_pBPlcDgf xfuW0zZrZDQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 12 Oct 2018 20:59:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d73803324d96c0df1040ed9066030d1a; Fri, 12 Oct 2018 20:59:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180) Message-Id: Date: Fri, 12 Oct 2018 13:59:39 -0700 Cc: FreeBSD Toolchain , John Baldwin To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 20:59:47 -0000 I built a powerpc64 head -r339076 via devel/powerpc64-gcc and the like that built clang as cc as well (and WITHOUT_LIB32). This included use of base/binutils to the the powerpc64 set up. The system and kernel are non-debug builds (but with symbols). [system-clang is not used for buildworld buildkernel because of known issues (last I tried).] booting, buildworld, buildkernel, poudriere building what totaled to be somewhat under 400 ports all seem to work. But . . . It been a long time since I've done something analogous and a significant item in the result is different than in the past once I started testing the throwing of C++ exceptions in code produced by system-clang or by devel/powerpc64-gcc : Such code ends up stuck using around 100% of a CPU. An example is the program: # more exception_test.cpp #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } For system-clang it ended up with: # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000) libm.so.5 => /lib/libm.so.5 (0x8101ab000) libc.so.7 => /lib/libc.so.7 (0x8101eb000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810554000) That program goes into an possibly unbounded execution. (Historically when this program had problems it would stop and produce a core file.) When compiled by devel/powerpc64-gcc the a.out that results does the same thing. ( /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ as the compiler path ) So this is not really clang specific in any way. This ended up with: # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000) libm.so.5 => /lib/libm.so.5 (0x8101ab000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8101eb000) libc.so.7 => /lib/libc.so.7 (0x810211000) (That should not have involved clang or llvm at all.) But compiled by lang/gcc8's g++8 the a.out that results works fine. This ends up with: # ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81006e000) libm.so.5 => /lib/libm.so.5 (0x8102c7000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810307000) libc.so.7 => /lib/libc.so.7 (0x81032d000) It is not clear if using base/gcc as system cc would do any better than using system-clang does or than devel/powerpc64-gcc does: it is sort of a variant of devel/powerpc64-gcc . It will probably be some time before I figure out much about what is going on. Two things common to the problem cases are: libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000) lang/gcc8 avoids those being involved. Notes: Some time ago I'd used system-clang to build such programs in an environment built via devel/powerpc64-gcc and devel/powerpc64-binutils and the programs worked. The same for devel/powerpc64-gcc use: the code it produced for the programs also worked. At this point I've no clue what changed or when. WITHOUT_LIB32= is because, for every post-gcc 4.2.1 that I've tried, the lib32 produced misuses R30 in crtbeginS code (vs. the ABI for FreeBSD) and 32-bit code just produces core files from the bad so-called address dereference that results. I'd rather have throwing C++ exceptions working and lack of lib32 than have lib32 but not have throwing C++ exceptions working. But at the moment how to have such is not obvious when fairly modern compilers and toolchains are involved. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Oct 12 22:33:36 2018 Return-Path: Delivered-To: freebsd-toolchain@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 1158B10CD1CB; Fri, 12 Oct 2018 22:33:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9566A79413; Fri, 12 Oct 2018 22:33:35 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D97333A352; Sat, 13 Oct 2018 00:33:27 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_75297E3E-55E8-49FC-91C0-B17BC9CB6C87"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined" Date: Sat, 13 Oct 2018 00:33:23 +0200 In-Reply-To: <8t33-9v5q-wny@FreeBSD.org> Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML To: Jan Beich References: <1B7575F6-ED4D-42FE-BD51-B976F21B7CA6@yahoo.com> <8t33-9v5q-wny@FreeBSD.org> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 22:33:36 -0000 --Apple-Mail=_75297E3E-55E8-49FC-91C0-B17BC9CB6C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Oct 2018, at 15:00, Jan Beich wrote: >=20 > Mark Millard writes: >> The following is on a powerpc64 machine (old PowerMac G5 so-called >> "Quad Core") running a personal build of head -r339076 that was >> built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1). >> The compiler for the port build is system-clang (so clang 6 as cc), >> not used for buildworld buildkernel. [I experiment with more modern >> compilers and toolchains for some powerpc family members.] > [...] >> /bin/sh ../../libtool --tag=3DCC --mode=3Dcompile cc -DHAVE_CONFIG_H >> -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files >> -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF >> .deps/control.Tpo -c -o control.lo control.c > [...] >> fatal error: error in backend: A @@ version cannot be undefined ... > and can be further reduced to >=20 > int main() > { > __asm__ (".symver __foo,foo@@FOO"); > __asm__ (".symver .__foo,.foo@@FOO"); > } Submitted as https://bugs.llvm.org/show_bug.cgi?id=3D39270, though upstream alsa-lib seems to have dropped this powerpc64 specific workaround: = http://git.alsa-project.org/?p=3Dalsa-lib.git;a=3Dcommit;h=3D3bad0a21b4d13= d8d10691f382c836897fa7a7cb9 You might want to try if that also works for you. -Dimitry --Apple-Mail=_75297E3E-55E8-49FC-91C0-B17BC9CB6C87 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW8EhMwAKCRCwXqMKLiCW o/qHAKCBM+r/K4IMa4bJSkYbP1vgn2DLaACfZUsEsi5Td1e4eV2xAuydncfW49I= =3S57 -----END PGP SIGNATURE----- --Apple-Mail=_75297E3E-55E8-49FC-91C0-B17BC9CB6C87-- From owner-freebsd-toolchain@freebsd.org Fri Oct 12 23:26:19 2018 Return-Path: Delivered-To: freebsd-toolchain@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 520BF10CEA96; Fri, 12 Oct 2018 23:26:19 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C34B7B507; Fri, 12 Oct 2018 23:26:19 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id F0DF91672E; Fri, 12 Oct 2018 23:26:18 +0000 (UTC) From: Jan Beich To: Dimitry Andric Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined" References: <1B7575F6-ED4D-42FE-BD51-B976F21B7CA6@yahoo.com> <8t33-9v5q-wny@FreeBSD.org> Date: Sat, 13 Oct 2018 01:26:15 +0200 In-Reply-To: (Dimitry Andric's message of "Sat, 13 Oct 2018 00:33:23 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 23:26:19 -0000 Dimitry Andric writes: > http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=3bad0a21b4d13d8d10691f382c836897fa7a7cb9 > > You might want to try if that also works for you. Applied in r481945. Let's see what happens. ;) From owner-freebsd-toolchain@freebsd.org Sat Oct 13 00:48:53 2018 Return-Path: Delivered-To: freebsd-toolchain@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 0E4B110D0DD5 for ; Sat, 13 Oct 2018 00:48:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 A923A7E2E1 for ; Sat, 13 Oct 2018 00:48:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QbSR9H4VM1mdfhejX.cGklv6KUdbf7RZQwFJTMhAnzgmbKHl1bFAHIOuOUPFSBV RHr2gnrcmtKjETl8fhja4S8U4ULJukKGIsVixQZwCQ1YhQXqcIRN6KmBD346uhid8gnf7ykwRxWp 0J0aGANxdOReJeE2wmNH6X4Q4M.sNi.7.8WawiMGZB_wECzxULVVEuZvY0ihJ3W1ZhCra5ssq425 oRJaYk_Qro.8Bc5YSZlRTuT5TtkGtJcFDGV.M.AlEncHXek0Ab9SXh1PyVV9wLkyCVjakoJMkRtL .q5qKBWjiUbTr7DUVjrRU6v7UAbV.kxZ_FMoZ51JYxL4yFMZoS2Nz_c81jq.ZerWcc9q6.wY7sXG 3uC3oGCZyDgk5eDxQJn5zcdSPxhFxU8fHWvjdoNzUDNazRIfZcUsgDewjSZfeqQ5Lflfwh1GzQBY 5AKyt0kEO_RBTrlgXrhMj328F21O8Dck7wuFqTFbPIlpwkfmgxFdp0_gI0eg.6XyOK8YT1PNz4Ju QJb9cDoKTJHp0L9cxI5QdCLrCyDo2LutQwTXVx4IspkmAyzztP4DnZVkeXQq1Y9f0MY_2c23Z9Nj bE.w2y_S6wOElFLAVXh079uqbHRyFv8dzeQNglIt4X97z5vlz1_heIQ.kvQfZ_20TgiOkVMkyBS2 7Eo72oIxxSFz1CNqu27AZimBK.tRtHYamB54OAYJ3MZ3Ct4QjUgjKZZDAYEfMz00wcRjb07HcIXP 8oA.bq5HgjVwR3jH0dzQdcETctcRMSnayrr4jAP.KUL2qIsbM4BooiYWTosuBALswQ1JhDscnW8J 6yUsA5BYO2CkU9jwPbJV5z5I18Z76K1ADFTAZ2yb9xquaW55r0a5qE0Tr86mQyN4DeM0nCHyfxzy oUafEI1nBNBVGUFa.VdxnvymBWu_sfHRoEyeoGjlv_4TI1LthyiDIjYWZ0DvVvzSncg2Bwt2Knbr aY3LxxhQWwP7ewrxGVtOS8wnTJCYXsDo3HaLhLQkQHqC_Gntvxd6luH0e9npyDHOZsgnwdG35CZ1 HVYZMGvl5k.ZfSTrEwCzydq_N2pES2z2rA0vI93O5oRUVoVj17fZ20q8fBgkCFdyfHljEgyGuxW1 C.IyrQiE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 13 Oct 2018 00:48:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 72eefb673feb346b9e4c85f6cd9796a7; Sat, 13 Oct 2018 00:48:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: "base/binutils should not be pulling in any other ports at all"? (That confuses me.) From: Mark Millard In-Reply-To: <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> Date: Fri, 12 Oct 2018 17:48:41 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C338B84-1179-4569-A964-CA18A22AF1D7@yahoo.com> <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:48:53 -0000 On 2018-Oct-10, at 3:13 PM, John Baldwin wrote: > On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: >> [Actually devel/gettext-tools is a build time dependency: it should = not be using >> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc = --sysroot=3D. . . >> It looks like the /usr/local/lib references are correct but the wrong = linker was >> being used. About 5 other ports have a similar status for making = base/binutils >> as a cross build.] >=20 > base/binutils should not be pulling in any other ports at all. That last quote confuses me still. May be it means it is all to be manually managed instead of automatic? (The actual build using things link devel/bison on the host if base/binutils is to build at all.) All versions of binutils have direct build dependencies on: math/gmp math/mpfr devel/bison devel/gmake as far as I know. Some of those in turn have more build dependencies. Some of all that have Runtime dependencies and/or library dependencies as well. (Host context of usage.) The following may not be complete but is suggestive. Build dependencies: math/gmp: print/texinfo devel/bison: devel/m4 print/texinfo devel/gettext-tools lang/perl5.* devel/m4: print/texinfo misc/help2man: devel/p5-Locale-gettext devel/gmake devel/gettext-tools = lang/perl5.* devel/p5-Locale-gettext: devel/gettext-tools lang/perl5.* print/texinfo: misc/help2man devel/gmake devel/gettext-tools = lang/perl5.* So removing multiple listings: (some runtime and library dependencies not covered yet) math/gmp math/mpfr devel/bison devel/gmake devel/m4 misc/help2man devel/p5-Locale-gettext devel/gettext-tools print/texinfo lang/perl5.* (I'm not explicit about which perl5 version.) Runtime dependencies: math/gmp: print/indexinfo math/mpfr: print/indexinfo devel/gmake: print/indexinfo devel/m4: print/indexinfo misc/help2man: devel/p5-Locale-gettext lang/perl5.* print/indexinfo devel/p5-Locale-gettext: lang/perl5.* devel/gettext-tools: print/indexinfo print/texinfo: lang/perl5.* print/indexinfo So this adds, removing multiple listings: print/indexinfo Library dependencies: math/mpfr: math/gmp devel/bison: devel/m4 print/indexinfo devel/gmake: devel/gettext-runtime misc/help2man: devel/gettext-runtime devel/p5-Locale-gettext: devel/gettext-runtime devel/gettext-tools: devel/gettext-runtime converters/libiconv print/texinfo: converters/libiconv devel/gettext-runtime devel/gettext-runtime: converters/libiconv So this adds, removing multiple listings: devel/gettext-runtime converters/libiconv Putting the 3 lists together I get that all the following are used in building any 6.4 or so version of binutils that is in ports: math/gmp math/mpfr devel/bison devel/gmake devel/m4 misc/help2man devel/p5-Locale-gettext devel/gettext-tools print/texinfo lang/perl5.* print/indexinfo devel/gettext-runtime converters/libiconv > Everytime I've > built it it has had no other dependencies beyond pkg. I expect the dependencies were already satisfied at the time of the attempted build of make/binutils and so caused no additional build activity at the time. My environment tends to have somewhat less than normal installed for development-environment type ports. The ones that I listed above that I did not have trouble with are exactly the ones that were in place beforehand. The ones I had trouble with are exactly the ones that were not in place beforehand. > As far as I'm aware,=20 > the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are > ports-mgmt/pkg, base/gcc, and base/binutils. Good to know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Oct 13 01:43:10 2018 Return-Path: Delivered-To: freebsd-toolchain@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 5EDAD10D38B3 for ; Sat, 13 Oct 2018 01:43:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (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 EA7CD81122 for ; Sat, 13 Oct 2018 01:43:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZJ8WTaUVM1l.pzbseOmHDKhMpm8YasS_NMbaoqO0Paq8BiRa7bFOmHPuJMjNwIp kY5aZmLJ3KkNMzavWlvdBioyk3tPr77Mg0Ybz.C.15p2o7azDaP05mGf5UW0d5cwSWsiA6BSuTQO WmZYkP9L24ytdIGraXAoPdEjL.BTDSYSKLlkZQiLsfUOzMhfAedZpDsrIlWQXvyxwhXrM9qXoKjs NHYp5lH14tGRnC4pvXZokpgfjVWguzl66hViVTX1A2GaGT2Ieow9Z.0s.NA5wXD3db3PcAGzY7BN U1ehnjFGwDSmceTLPXwV7lMNAuTi8BI9KLX_VBehzYdvJNCWcUJDiG0b6ZA6itfJiOG0PvpQtJ13 kCiy90FrGyw3yDBXB_qG8Ygxh7amIIOIJeWP1HhZ3z.G0TXpIancUpMBAfBoeqq.EjqqJdhsbKlv XrR0558rpOUrb4UY1rckUABR12N4PLsIvQ8_Mjz63hgm7HddhEEFMEy3M6OmRvZt4YFIeu7R64Og sNP.a0hj0_mUWxXWeDB280TQWsWiT.OWc8vmdnfv.JmALjmF0gwBUI3xH00dnlLbBlCk4SCf8sGl K2DSl9JGOeUiHIbfaNY106mmYj6n8o17gyeugiBZoJ6c5_gfUassjhtAYCVwmn5QYh0lVGQhAPoA G.M4XZokv0FfTCFn.kgdOUqq4SszV9NekFHFdUbWTe55Ok1H2mPGqwRbJGEUkl4uPQnUNXhm4X4z d4k4zmcs_1OCaEAVfyA_FcYmHGgc2DhI5iMvSaTi7TMraMgA8elf45trfJYb4HLxmM49gVvfL_tx v39gfwrZiHiLPKB_wti3bOX.V3BIUQZ.RH22x7pFXLLJ2UkdjUL_WqdLG3DRP_0SC8Mw_7b7ptdd Y6BSNp6_B4QtI1QCie5B.yP_f8qBrEdrT4T6IJ46puDInvLkw41P.FoOYi6JpPWRDLFlTLbWiX6t 6KzJMYnYb.3Iyh7twrnaw82dR3XbHQQNREzxRsnyb6JyDMWJdm5JKqGhH.Gr4_IVif1oeameW..c WCF4.5VqX2zWVxg1QXw_pU5tlWfEiu0oVa2HCbSqekzFB9GnsoAj2j7YANHBDQasqqyELYpB6d3e l.xCO4TCwow-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sat, 13 Oct 2018 01:43:02 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp430.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dd16601c3225be0f153d316a3f2b0b83; Sat, 13 Oct 2018 01:32:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: "base/binutils should not be pulling in any other ports at all"? (That confuses me.) From: Mark Millard In-Reply-To: Date: Fri, 12 Oct 2018 18:32:49 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <7FDF7A77-D40F-4BE0-8440-9F3DC4C8E21D@yahoo.com> References: <4C338B84-1179-4569-A964-CA18A22AF1D7@yahoo.com> <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 01:43:10 -0000 [Top post going in a somewhat different direction. Plus I listed the wrong version for bintils, not 6.4, but 2.30 .] I probably should have referenced the line in base/binutils/Makefile : MASTERDIR=3D ${.CURDIR}/../../devel/binutils which in turn brings in references for all the direct dependencies that devel/binutils normally has, such as seen via freshports. This is how things that are missing up front end up with an attempt to build them. I do not see anything that effectively would say "disable the dependencies that devel/binutils indicates". On 2018-Oct-12, at 5:48 PM, Mark Millard wrote: > On 2018-Oct-10, at 3:13 PM, John Baldwin wrote: >=20 >> On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: >>> [Actually devel/gettext-tools is a build time dependency: it should = not be using >>> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc = --sysroot=3D. . . >>> It looks like the /usr/local/lib references are correct but the = wrong linker was >>> being used. About 5 other ports have a similar status for making = base/binutils >>> as a cross build.] >>=20 >> base/binutils should not be pulling in any other ports at all. >=20 > That last quote confuses me still. May be it means > it is all to be manually managed instead of automatic? > (The actual build using things link devel/bison on > the host if base/binutils is to build at all.) >=20 > All versions of binutils have direct build dependencies on: >=20 > math/gmp > math/mpfr > devel/bison > devel/gmake >=20 > as far as I know. Some of those in turn have more > build dependencies. Some of all that have Runtime > dependencies and/or library dependencies as well. > (Host context of usage.) >=20 > The following may not be complete but is suggestive. >=20 >=20 > Build dependencies: >=20 > math/gmp: print/texinfo > devel/bison: devel/m4 print/texinfo devel/gettext-tools lang/perl5.* > devel/m4: print/texinfo > misc/help2man: devel/p5-Locale-gettext devel/gmake devel/gettext-tools = lang/perl5.* > devel/p5-Locale-gettext: devel/gettext-tools lang/perl5.* > print/texinfo: misc/help2man devel/gmake devel/gettext-tools = lang/perl5.* >=20 > So removing multiple listings: > (some runtime and library dependencies not covered yet) >=20 > math/gmp > math/mpfr > devel/bison > devel/gmake > devel/m4 > misc/help2man > devel/p5-Locale-gettext > devel/gettext-tools > print/texinfo > lang/perl5.* >=20 > (I'm not explicit about which perl5 version.) >=20 > Runtime dependencies: >=20 > math/gmp: print/indexinfo > math/mpfr: print/indexinfo > devel/gmake: print/indexinfo > devel/m4: print/indexinfo > misc/help2man: devel/p5-Locale-gettext lang/perl5.* print/indexinfo > devel/p5-Locale-gettext: lang/perl5.* > devel/gettext-tools: print/indexinfo > print/texinfo: lang/perl5.* print/indexinfo >=20 > So this adds, removing multiple listings: >=20 > print/indexinfo >=20 >=20 > Library dependencies: >=20 > math/mpfr: math/gmp > devel/bison: devel/m4 print/indexinfo > devel/gmake: devel/gettext-runtime > misc/help2man: devel/gettext-runtime > devel/p5-Locale-gettext: devel/gettext-runtime > devel/gettext-tools: devel/gettext-runtime converters/libiconv > print/texinfo: converters/libiconv devel/gettext-runtime > devel/gettext-runtime: converters/libiconv >=20 > So this adds, removing multiple listings: >=20 > devel/gettext-runtime > converters/libiconv >=20 >=20 > Putting the 3 lists together I get that all the following > are used in building any 6.4 or so version of binutils > that is in ports: That "6.4" should have been: 2.30 (I inappropriately thought of the gcc version number originally.) > math/gmp > math/mpfr > devel/bison > devel/gmake > devel/m4 > misc/help2man > devel/p5-Locale-gettext > devel/gettext-tools > print/texinfo > lang/perl5.* > print/indexinfo > devel/gettext-runtime > converters/libiconv >=20 >=20 >> Everytime I've >> built it it has had no other dependencies beyond pkg. >=20 > I expect the dependencies were already satisfied at > the time of the attempted build of make/binutils > and so caused no additional build activity at the > time. >=20 > My environment tends to have somewhat less than normal > installed for development-environment type ports. The > ones that I listed above that I did not have trouble > with are exactly the ones that were in place beforehand. > The ones I had trouble with are exactly the ones that > were not in place beforehand. >=20 >> As far as I'm aware,=20 >> the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are >> ports-mgmt/pkg, base/gcc, and base/binutils. >=20 > Good to know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Oct 13 03:21:54 2018 Return-Path: Delivered-To: freebsd-toolchain@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 7BB5B10D6D63 for ; Sat, 13 Oct 2018 03:21:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.ne1.yahoo.com (sonic309-22.consmr.mail.ne1.yahoo.com [66.163.184.148]) (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 13AA184664 for ; Sat, 13 Oct 2018 03:21:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: uccTcnwVM1nrPWxYKi9xWQUcVEs1ix3ZXaAC57jjWldTJuKu8HDAo9EccuHCSY6 1iBObpl3m10ChwRLzsBmkA4q97KU0w0.f5mtlrpoyIAPvDdh6pVnmLvkcMVs29Td5hnHNdg9x4Fm f_DmT9WPfhzxop42ATmlDS7YDLnKTA6YysPD2SVP85S3mQpNjI3IKCfq_9pokIDEGT0PAPBeKN5q Lu5LY0tcNHtpVFN1OGxc6ezAYoBUqHg8ISQ_pfVJlNTi2BitFLX7G6.tPj.JPWzMiLFPKKIQ5aZ4 6.VE8ngbSNSCgu5e2D2hv9.UsY_ay72Du3nrBv9hDDlgOH_WIFsVdCEiJm_HvD_d53mxNSuRcV1Q RUhSdAdQ_ucSNJ228DAfvI1XrHf6wdZz_xIJgjF5xxiPQal4Vx2F59Mt08v4isWE0.V8Vbvf0vtU .uhNHQDGIFByURtqNUq92mCUDjoXy4JjRUBwEQnTxTHM3KQkejGPnlPciwF_SEPS5_ZuZhxnVuXL Uvu84R8uq_2i0EWHgC94.IbR97iDr1GLAKGMV9CaphXnCEp.e8F0OROSII7KMEIUFyiAc9NPDDpV tn3bNyLDOEgEeGiZfNQ3pOmi0kxy_uuoN2fW_Og8.5_2MQRhqIakY3wM8XKqsgrQKofo2Kiq__PX GTSzD98zaSkuLyfXxbPXWu1YLgcLY6u_Pcv1EW0DuzpWKLE19nNQVUGa0CYLK6M3PaI327FILAGi L2fzucRFhUdSrRJ.BcE8k3tq8PvPX_6iSsKi85OhbOuxvCUUBwpS8BiJ1IbhkdoqBMmr2VH0FFA4 8PERCgf0C3fqHRT0W4tMkJtvf6a7QveriuJlkGdDqSa30Y26WyswBr1Z06H846HaB0VQ_VxC1E2g lf6Y8VqzNUJqcc0zmWIyWMP7Bq.thCQ84mTEP2TqnzLxLOVRe7VxZZQc5iFFEafCDl84H0hBJSrY cuUieRfynufi7URqW6lxZFpnwZjQVsJmAr9m_KfcwBLVdn_TBWLf7VVHeUGYg.qmv8QFxhuhCRYL wGadzVThipJUXXwdAlaYiWANray2kmLDuO66mwLbgIY_X5O7wrIxjm9FfiFH6IUo0xUO33CpVzOC qAAqdPg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sat, 13 Oct 2018 03:21:52 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp403.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f196d83be02f0b17d30a9e6c8270fd15; Sat, 13 Oct 2018 03:21:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: An FYI: What lldb is built for when targeting powerpc64: Current executable set to 'a.out' (powerpc64le) Message-Id: <8FE32D65-6FB7-4E6A-9FBD-A3AEBDE88020@yahoo.com> Date: Fri, 12 Oct 2018 20:21:47 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 03:21:54 -0000 [I was not expecting lldb to work on/for powerpc64. But I thought the powerpc64le reference by lldb was interesting.] # lldb a.out (lldb) target create "a.out" Current executable set to 'a.out' (powerpc64le). # file a.out a.out: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version = 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, = FreeBSD-style, for FreeBSD 12.0 (1200084), with debug_info, not stripped =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Oct 13 17:12:29 2018 Return-Path: Delivered-To: freebsd-toolchain@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 6330E10D03B6 for ; Sat, 13 Oct 2018 17:12:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 E65B082A00 for ; Sat, 13 Oct 2018 17:12:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: V1.Pk.QVM1ljzfn0oAHwx6UMxa1_xnMmXHx2GeKbZLZnq5aZGhCY2NKuLtr9gmk GOTZtfDZ_MsgIJkKfRVp3Av5ALsu5CnUBpMDgIMdLFGU7QDDupmXU8kvbgPRcZOYi4tsXfldh2eH Troumi5UPWEaaYAOQ_eaqoIugJ49tv4.xTA_sWL8MFxqxIZo.YaDj826nHeUtLW_Xx_jfSrwYgaY 2hnP8QMto3LefA1w6V51E7WJ6bxIexeEJjeB89brUkY5_2qZdq4UF7rnaybD2jkK1nEDg5c.Vin. u4OOtgcLQyBWE735AhN3RNDqaT8VC9rOMy9iBhFTrJNptos.sQPsX_aoKWNFOfrdooYKf0yZnV.m yUrI_d5B20btBJf8yeBykoYXyCUbez2yhtrqNUvisiY.3cnU.iqPQJP3gJ5ZhAhUIb8JHGjWETB9 s9glmTS1vC7ryQzmE.12wJWMay56.jm59m.o92x_sdNBwCJ1Ml0jxEROQTwZCVnFvIBgJHaXo.vT ygqGQDqcYkGX7wVmyqDA95T4M0x9a3l30P9Lz9DtBvgZhNyDixQ3sBcnSNUbGpRe5OgHHRxtQo63 37CRgIDWXyhY_1h41wrmjlqo7flsHXZj1SjqiGKwS6yVbEtSxdnWh3cgorW3St5WcBdL1HvJuFgO sZYC4IzMXqa5x6bjciNhD_pNx8zKceiM4Em5ZA70KLGJLmMISFoEhvkEdkv2a2V2X7461OG2tQoe 8_J7H9tX0ESSu9n87n4d81h4dPzYHkfoOLldc7cstqd8nQTU2BP3MzW7sHJnywzadBBS3ws0ikad ucLR_B3yE0U1GTvrm0s0O1QDnmE9mbSJ.diRVeTVQMpHvEx_C8bSxBMhvsLeeb_P3cuMVXFMVmuJ vlza_9dOdoNt4rx6bKXwI69j83_MIvh8et9XXXSTY.lxyzI_SS_Sepm45HYs7FP7gJljtLsL4R8h mih6SNHBYPJw4QK7zsBSJFke_BOI3jKsx9M9t.JnBtwIm.xp44d6kk3dkYukcCx28IdDvDA49ifr jMuaFq.MDFckgyaTDn_moS4VvoVNTvmpbb.1AYH3EDbflCifBn08mxjQVt7p__b1xAA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Oct 2018 17:12:21 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp408.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5be009593758ec2d2a97f3b3b40971cf for ; Sat, 13 Oct 2018 17:12:18 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions? Message-Id: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> Date: Sat, 13 Oct 2018 10:12:17 -0700 To: FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 17:12:29 -0000 While investigating powerpc64 C++ exception handling for builds under devel/powerpc64-gcc I ran into the following in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : /* As a special exception, if you link this library with other files, some of which are compiled with GCC, to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public = License. */ So in contexts were clang/llvm is used to exclusion . . . are any such files in use? (I happen to be using devel/powerpc64-gcc at the moment.) For me this has no real implications: I do not distribute my experiments. But I was surprised by what I read. Looking I find: # grep -r "some of which are compiled with GCC" /usr/src/* | more /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/mips/mips16.S: some of which are compiled = with GCC, to produce an executable, /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, to = produce an executable, /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/gthr-single.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled with = GCC, to produce an executable, /usr/src/contrib/gcc/tsystem.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/typeclass.h: some of which are compiled with GCC, = to produce an executable, /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are = compiled with GCC, to produce an executable, /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are = compiled with GCC, to produce an executable, =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Oct 13 17:16:10 2018 Return-Path: Delivered-To: freebsd-toolchain@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 AC0E610D0456 for ; Sat, 13 Oct 2018 17:16:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theravensnest.org [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F67882B41 for ; Sat, 13 Oct 2018 17:16:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-136-0-129.range86-136.btcentralplus.com [86.136.0.129]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w9DHEiKp012534 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Oct 2018 17:14:44 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: mail: Host host86-136-0-129.range86-136.btcentralplus.com [86.136.0.129] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions? From: David Chisnall In-Reply-To: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> Date: Sat, 13 Oct 2018 18:15:56 +0100 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <61B6C299-2F93-4678-8928-3CABDFED6623@FreeBSD.org> References: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3445.100.39) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 17:16:10 -0000 This is a known problem with the GCC runtime libraries. GCC 4.3 and = later have a much better exemption (which talks about any eligible = compilation process, rather than being compiled with GCC), but those are = GPLv3 and so unacceptable for FreeBSD. I don=E2=80=99t believe that we are using any of those files on = platforms where clang is the default system compiler. LLVM=E2=80=99s = libUnwind should be able to handle PowerPC on Linux, so it=E2=80=99s = worth checking if this is the case on FreeBSD. David > On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain = wrote: >=20 > While investigating powerpc64 C++ exception handling for > builds under devel/powerpc64-gcc I ran into the following > in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : >=20 > /* As a special exception, if you link this library with other files, > some of which are compiled with GCC, to produce an executable, > this library does not by itself cause the resulting executable > to be covered by the GNU General Public License. > This exception does not however invalidate any other reasons why > the executable file might be covered by the GNU General Public = License. */ >=20 > So in contexts were clang/llvm is used to exclusion . . . are > any such files in use? (I happen to be using devel/powerpc64-gcc at > the moment.) >=20 > For me this has no real implications: I do not distribute > my experiments. But I was surprised by what I read. >=20 > Looking I find: >=20 > # grep -r "some of which are compiled with GCC" /usr/src/* | more > /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/mips/mips16.S: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with GCC, = to produce an executable, > /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, to = produce an executable, > /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with GCC, = to produce an executable, > /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-single.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/tsystem.h: some of which are compiled with GCC, = to produce an executable, > /usr/src/contrib/gcc/typeclass.h: some of which are compiled with = GCC, to produce an executable, > /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are = compiled with GCC, to produce an executable, > /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are = compiled with GCC, to produce an executable, >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org"