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: LatestFlags: 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    
Description Flags
gcc48 workaround jbeich: maintainer-approval? (portmgr)

Description Jan Beich freebsd_committer 2016-11-27 00:02:33 UTC
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
  int main()
    // Snippet from lilypond-devel
    int argc = 5;
    char **argv = new char*[argc + 2];
    return 0;

  $ 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

Affected ports:

Comment 1 Dimitry Andric freebsd_committer 2016-11-27 17:15:34 UTC
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
        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
        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.
Comment 2 Jan Beich freebsd_committer 2016-11-28 00:44:44 UTC
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
Comment 3 David Chisnall freebsd_committer 2016-11-28 08:37:23 UTC
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.
Comment 4 Dimitry Andric freebsd_committer 2016-11-28 18:54:27 UTC
(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?
Comment 5 Ed Maste freebsd_committer 2016-11-29 00:28:02 UTC
> 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.
Comment 6 Mathieu Arnold freebsd_committer 2016-11-29 08:34:05 UTC
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.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2016-11-30 10:35:27 UTC
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).
Comment 8 Dimitry Andric freebsd_committer 2016-11-30 18:38:47 UTC
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.
Comment 9 Baptiste Daroussin freebsd_committer 2016-12-01 22:52:47 UTC
well this is a bug :)

They should not
Comment 10 Jan Beich freebsd_committer 2016-12-11 12:10:29 UTC
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).
Comment 11 Jan Beich freebsd_committer 2016-12-25 14:35:03 UTC
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?
Comment 12 Antoine Brodin freebsd_committer 2016-12-25 14:53:57 UTC
(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).
Comment 13 commit-hook freebsd_committer 2017-01-03 08:45:27 UTC
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

  lang/gcc: clear BROKEN from consumers as 10.1 is past EOL

  PR:		214863

Comment 14 commit-hook freebsd_committer 2017-01-03 08:56:39 UTC
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

  cad/openvsp: drop 10.1 workaround (revert r428665) per EOL

  PR:		214863 215307
  Approved by:	portmgr blanket