TritonDataCenter / pkgsrc-legacy

Automatically updated conversion of the "pkgsrc" module from anoncvs.netbsd.org
http://www.pkgsrc.org
127 stars 64 forks source link

Regression: C++11 support in g++ seems to be broken from the upgrade from 4.7.3 to 4.7.4 #270

Closed trondn closed 8 years ago

trondn commented 9 years ago

I've got a zone based on: 3f57ffe8-47da-11e4-aa8b-dfb50a06586a standard64 14.2.1 smartos 2014-09-29T13:12:19Z

where I've got g++ 4.7.3 and everything is working as "expected", but today I tried to create a new zone by using "the latest bits" and I'm getting trouble with g++..

I created the zone based on: 0edf00aa-0562-11e5-b92f-879647d45790 base-64 15.1.1 smartos 2015-05-28T17:50:41Z

and the C++11 support seems to be broken.. std::to_string seems to be missing (and there are a number of other functions as well). I've tried g++ 4.7.4, 4.8.4 and 4.9.2 in pkgsrc and they all seem to have the problem.. anyone else seen this?

Try compiling this with g++ -std=c++11 filename

include

int main(void) { std::string s = std::to_string(4); std::stoi(s); std::stof(s); std::stoull(s); return 0; }

jperkin commented 9 years ago

This looks like it is caused by the default platform change for our 14.4.0 builds onwards. 14.3.x and earlier were built on joyent_20130322T181205Z, whilst 14.4.0 onwards are built on joyent_20141030T081701Z.

The GCC pkgsrc packages for 14.3 and 14.4 are identical, with both containing gcc47-4.7.3nb6, and I've compared lang/gcc47 between both branches to verify there are no changes, but whilst 14.3.0's GCC works correctly, 14.4.2's GCC fails.

/* test.cc */
#include <string>

int main(void)
{
        std::string s = std::to_string(4);
}
# grep ^Image /etc/product
Image: base64 14.3.0

# pkg_info -e gcc47
gcc47-4.7.3nb6

# g++ -std=c++11 test.cc -o test; echo $?
0
# grep ^Image /etc/product
Image: minimal-64-lts 14.4.2

# pkg_info -e gcc47
gcc47-4.7.3nb6

# g++ -std=c++11 test.cc -o test; echo $?
test.cc: In function 'int main()':
test.cc:5:18: error: 'to_string' is not a member of 'std'
1

In addition, trying gcc49 on the older platform also works fine:

# grep ^Image /etc/product
Image: base64 14.3.0

# pkg_info -e gcc49
gcc49-4.9.1

# /opt/local/gcc49/bin/g++ -std=c++11 test.cc -o test; echo $?
0

This strongly rules out the cause being GCC related, and so I'll start looking into platform changes which may be causing this.

jperkin commented 9 years ago

Differences in installed C++ headers between the two builds:

--- gcc-14.3-inst/opt/local/gcc47/include/c++/i386-sun-solaris2.11/bits/c++config.h Wed Jun 24 13:19:44 2015
+++ gcc-14.4-inst/opt/local/gcc47/include/c++/i486-sun-solaris2.11/bits/c++config.h Wed Jun 24 13:20:08 2015
@@ -491,7 +491,7 @@
 #define _GLIBCXX_HAVE_CEILL 1

 /* Define to 1 if you have the <complex.h> header file. */
-#define _GLIBCXX_HAVE_COMPLEX_H 1
+/* #undef _GLIBCXX_HAVE_COMPLEX_H */

 /* Define to 1 if you have the `cosf' function. */
 #define _GLIBCXX_HAVE_COSF 1
@@ -1202,17 +1202,17 @@

 /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
    <stdio.h>, and <stdlib.h> can be used or exposed. */
-#define _GLIBCXX_USE_C99 1
+/* #undef _GLIBCXX_USE_C99 */

 /* Define if C99 functions in <complex.h> should be used in <complex>. Using
    compiler builtins for these functions requires corresponding C99 library
    functions to be present. */
-#define _GLIBCXX_USE_C99_COMPLEX 1
+/* #undef _GLIBCXX_USE_C99_COMPLEX */

 /* Define if C99 functions in <complex.h> should be used in <tr1/complex>.
    Using compiler builtins for these functions requires corresponding C99
    library functions to be present. */
-#define _GLIBCXX_USE_C99_COMPLEX_TR1 1
+/* #undef _GLIBCXX_USE_C99_COMPLEX_TR1 */

 /* Define if C99 functions in <ctype.h> should be imported in <tr1/cctype> in
    namespace std::tr1. */

I'm starting to suspect issues with GCC's fixincludes vs the newer headers, as some of the fixincludes for <complex.h> are working around things that have now been fixed, potentially causing problems. Am testing a build of GCC with fixincludes disabled which I was working on previously anyway.

jperkin commented 9 years ago

Failing test:

--- gcc-14.3/build/i386-sun-solaris2.11/libstdc++-v3/config.log     2015-06-24 11:37:23.000000000 +0000
+++ gcc-14.4/build/i486-sun-solaris2.11/libstdc++-v3/config.log     2015-06-24 12:13:11.000000000 +0000
 configure:16666: checking complex.h usability
-configure:16666:  /home/pbulk/build/lang/gcc47/work/build/./gcc/xgcc -shared-libgcc -B/home/pbulk/build/lang/gcc47/work/build/./gcc -nostdinc++ -L/home/pbulk/build/lang/gcc47/work/build/i386-sun-solaris2.11/libstdc++-v3/src -L/home/pbulk/build/lang/gcc47/work/build/i386-sun-solaris2.11/libstdc++-v3/src/.libs -B/opt/local/gcc47/i386-sun-solaris2.11/bin/ -B/opt/local/gcc47/i386-sun-solaris2.11/lib/ -isystem /opt/local/gcc47/i386-sun-solaris2.11/include -isystem /opt/local/gcc47/i386-sun-solaris2.11/sys-include    -c -g -O2 -pipe -O2 -I/opt/local/include -I/usr/include -std=c++98 -fno-exceptions  conftest.cpp >&5
-configure:16666: $? = 0
-configure:16666: result: yes
+configure:16666:  /home/pbulk/build/lang/gcc47/work/build/./gcc/xgcc -shared-libgcc -B/home/pbulk/build/lang/gcc47/work/build/./gcc -nostdinc++ -L/home/pbulk/build/lang/gcc47/work/build/i486-sun-solaris2.11/libstdc++-v3/src -L/home/pbulk/build/lang/gcc47/work/build/i486-sun-solaris2.11/libstdc++-v3/src/.libs -B/opt/local/gcc47/i486-sun-solaris2.11/bin/ -B/opt/local/gcc47/i486-sun-solaris2.11/lib/ -isystem /opt/local/gcc47/i486-sun-solaris2.11/include -isystem /opt/local/gcc47/i486-sun-solaris2.11/sys-include    -c -g -O2 -pipe -O2 -I/opt/local/include -I/usr/include -std=c++98 -fno-exceptions  conftest.cpp >&5
+In file included from conftest.cpp:65:0:
+/home/pbulk/build/lang/gcc47/work/build/./gcc/include-fixed/complex.h:139:1: error: expected '}' at end of input

caused by incorrect patching by fixincludes:

--- gcc-14.3/build/gcc/include-fixed/complex.h      2015-06-24 11:08:49.000000000 +0000
+++ gcc-14.4/build/gcc/include-fixed/complex.h      2015-06-24 11:17:23.000000000 +0000
@@ -28,6 +28,9 @@
  * CDDL HEADER END
  */
 /*
+ * Copyright 2011 Nexenta Systems, Inc.  All rights reserved.
+ */
+/*
  * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
  * Use is subject to license terms.
  */
@@ -35,7 +38,9 @@
 #ifndef _COMPLEX_H
 #define        _COMPLEX_H

-#pragma ident  "@(#)complex.h  1.10    05/10/06 SMI"
+#ifdef __cplusplus
+extern "C" {
+#endif

 #ifdef __cplusplus
 extern "C" {
@@ -44,7 +49,12 @@
  * Compilation environments for Solaris must provide the _Imaginary datatype
  * and the compiler intrinsics _Complex_I and _Imaginary_I
  */
+#if defined(__SUNPRO_C)
 #define        _Complex_I      (__extension__ 1.0iF)
+#else
+#define        _Complex_I      1.0fi
+#define        _Imaginary_I    1.0fi
+#endif
 #define        complex         _Complex
 #undef I
 #define        I               _Complex_I
@@ -124,7 +134,9 @@
 extern long double complex ctanhl(long double complex);
 extern long double complex ctanl(long double complex);

+/* #endif */   /* !defined(__cplusplus) */
 #ifdef __cplusplus
 }
 #endif
+
 #endif /* _COMPLEX_H */

i.e. adding an extra extern "C" { without a matching closing brace.

jperkin commented 9 years ago

Confirmed that a build with fixincludes disables at least resolves this issue:

# uname -v
joyent_20141030T081701Z

# pkg_info -e gcc47
gcc47-4.7.3nb6

# /opt/local/gcc47/bin/g++ -std=c++11 test.cc -o test; echo $?
0

I'll look to build our 2015Q2 packages with fixincludes disabled and perform some comparison bulk builds to catch any potential regressions from doing so.

jperkin commented 8 years ago

This was resolved a while ago. Closing issue.