Bug 214863
| Summary: | lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> | ||||
| Component: | Individual Port(s) | Assignee: | Port Management Team <portmgr> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Many People | CC: | bapt, dim, emaste, gerald, portmgr, re, rhurlin, theraven, toolchain | ||||
| Priority: | Normal | Keywords: | regression | ||||
| Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(portmgr) koobs: merge-quarterly? |
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215192 | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 196712 | ||||||
| Attachments: |
|
||||||
|
Description
Jan Beich
2016-11-27 00:02:33 UTC
This is because g++ 4.9 is now inserting a call to __cxa_throw_bad_array_new_length, e.g.:
main:
.LFB0:
.cfi_startproc
leal 4(%esp), %ecx
.cfi_def_cfa 1, 0
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
.cfi_escape 0x10,0x5,0x2,0x75,0
movl %esp, %ebp
pushl %ecx
.cfi_escape 0xf,0x3,0x75,0x7c,0x6
subl $20, %esp
movl $5, -12(%ebp)
movl -12(%ebp), %eax
addl $2, %eax
cmpl $532676608, %eax
ja .L2
sall $2, %eax
jmp .L5
.L2:
call __cxa_throw_bad_array_new_length
but the support for this call was only merged to stable/10 in r278724, way after 10.1-R was created.
One option is to compile the program without exception support, or to explicitly use gcc 4.8 or lower. I could not find a gcc command line option to disable the generation of these calls.
Created attachment 177468 [details] gcc48 workaround Maybe dangerous if USES=compiler:gcc-c++11-lib is mixed with USES=fortran in dependencies. I've only tested direct consumers. graphics/GraphicsMagick had to be patched to avoid breaking science/gnudatalanguage: http://sprunge.us/bMYN It would be good to put out an EN for the libcxxrt change and merge it back to all supported branches - the same problem will occur if you are using a recent clang on these systems. (In reply to David Chisnall from comment #3) > It would be good to put out an EN for the libcxxrt change and merge it back > to all supported branches - the same problem will occur if you are using a > recent clang on these systems. 10.1 and 10.2 have one month of life left... Do you really think this is worth the trouble? > 10.1 and 10.2 have one month of life left... Do you really think this is worth
> the trouble?
Regardless of the branches still being supported today, some of our downstream consumers continue to use FreeBSD releases long after they're no longer supported. I think there is value in an EN even if the branch is EOL at the end of the year. I can't really say for sure that this is enough value to justify the effort: I suspect those downstream users don't follow -pN releases directly anyhow and it's easy enough for them to incorporate the patch into their local tree.
Up until a branch is out of support, it should get all the EN/SA that we promise. So any EN/SA that comes out before January 1st should include 10.1 and 10.2 (and 9.3 if applicable) Now, after the support runs out, we should really not support them any more, otherwise, people will start expecting our EOL to be automatically extended, and I am not sure secteam@ or re@ has the manpower to handle that. All but compiler.mk changes are blanket, re-assign accordingly Can someone please create a separate issue (blocking this one) for the creation of the Errata Notice, and assign it to the correct team/person(s). One question though: why are ports on 10.x using devel/libc++, while libc++ is in base? I would really like to understand the reasoning behind this. IIRC Baptiste added it, so I'm putting him on the CC list. Another way to fix this would be to make the ports that use devel/libc++, also use devel/libcxxrt, in which this problem has already been fixed. E.g, change the devel/libc++ port so the /usr/local/lib/c++/libstdc++.so linker scripts it installs contains: GROUP ( /usr/local/lib/libc++.so.1 /usr/local/lib/libcxxrt.so ) and add devel/libcxxrt as a dependency of devel/libc++. This is far easier than an EN, and this workaround can be removed as soon as 9.x and 10.[12] reach end of life. In fact, we should actively try to remove the whole devel/libc++ and devel/libcxxrt ports in the future. well this is a bug :) They should not devel/libcxxrt workaround would be no better than lang/gcc48. One has to make sure RPATH works properly or backward compatibility would fail due to multiple layers of indirection (see libgcc_s vs. libgfortran mess). What's portmgr's plan for quarterly? Will 2017Q1 still support 9.x, 10.1, 10.2 and tag RELEASE_9_EOL at the end? (In reply to Jan Beich (mail not working) from comment #11) Unless the FreeBSD Security Officer changes his mind, at 23:59 UTC December 31, 2016, FreeBSD 9.3, 10.1 and 10.2 will reach end-of-life and will no longer be supported. So 2017Q1 will not support those releases (unless so@ changes his mind). A commit references this bug: Author: jbeich Date: Tue Jan 3 08:45:00 UTC 2017 New revision: 430445 URL: https://svnweb.freebsd.org/changeset/ports/430445 Log: lang/gcc: clear BROKEN from consumers as 10.1 is past EOL PR: 214863 Changes: head/math/ceres-solver/Makefile head/math/saga/Makefile head/print/lilypond-devel/Makefile A commit references this bug: Author: jbeich Date: Tue Jan 3 08:55:57 UTC 2017 New revision: 430446 URL: https://svnweb.freebsd.org/changeset/ports/430446 Log: cad/openvsp: drop 10.1 workaround (revert r428665) per EOL PR: 214863 215307 Approved by: portmgr blanket Changes: head/cad/openvsp/Makefile |