Closed trondn closed 8 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.
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.
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.
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.
This was resolved a while ago. Closing issue.
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; }