Bug 196712 regressed USES=compiler:gcc-c++11-lib ports. gcc49 or later appear to have the following regression on /releng/10.1. Maybe toolchain@ has a clue.
$ cat a.cc
// Snippet from lilypond-devel
int argc = 5;
char **argv = new char*[argc + 2];
$ pkg install -y gcc libc++
$ g++49 -std=c++11 -nostdinc++ -isystem /usr/local/include/c++/v1 -L/usr/local/lib/c++ a.cc
/tmp//ccZYfujU.o: In function `main':
a.cc:(.text+0x2b): undefined reference to `__cxa_throw_bad_array_new_length'
collect2: error: ld returned 1 exit status
This is because g++ 4.9 is now inserting a call to __cxa_throw_bad_array_new_length, e.g.:
leal 4(%esp), %ecx
.cfi_def_cfa 1, 0
andl $-16, %esp
movl %esp, %ebp
subl $20, %esp
movl $5, -12(%ebp)
movl -12(%ebp), %eax
addl $2, %eax
cmpl $532676608, %eax
sall $2, %eax
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]
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. 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:
Date: Tue Jan 3 08:45:00 UTC 2017
New revision: 430445
lang/gcc: clear BROKEN from consumers as 10.1 is past EOL
A commit references this bug:
Date: Tue Jan 3 08:55:57 UTC 2017
New revision: 430446
cad/openvsp: drop 10.1 workaround (revert r428665) per EOL
PR: 214863 215307
Approved by: portmgr blanket