mundo instalar hola ejecutar compilar compilador codigos basicos c++ gcc c++11 centos centos6.5

instalar - hola mundo c++



g++ no incluye archivos, dice que incluye para C++ 11? (2)

Version corta

Cuando compilo incluso un código simple usando una característica del estándar C ++ 11 (la función std::stod ), GCC 4.9.1 falla con el siguiente error:

example.cpp: In function ''int main()'': example.cpp:10:18: error: ''stod'' is not a member of ''std'' double earth = std::stod (orbits,&sz); ^ example.cpp:11:17: error: ''stod'' is not a member of ''std'' double moon = std::stod (orbits.substr(sz)); ^

¿Qué?

El comando que uso es g++ -std=c++11 example.cpp .

Este es el código de prueba (que compila bien en otros sistemas):

// stod example from http://www.cplusplus.com/reference/string/stod/ #include <iostream> // std::cout #include <string> // std::string, std::stod int main () { std::string orbits ("365.24 29.53"); std::string::size_type sz; // alias of size_t double earth = std::stod (orbits,&sz); double moon = std::stod (orbits.substr(sz)); std::cout << "The moon completes " << (earth/moon) << " orbits per Earth year./n"; return 0; }

detalles

Estoy usando una versión de GCC 4.9.1. Me compilé en dos clusters diferentes ejecutando CentOS 6.5 (utilizo el sistema de módulos en cosas en mi directorio de inicio dado que no soy administrador).

Los llamaré clúster 1 y clúster 2 : el clúster 1 es donde ocurre la falla.

Los GCC se compilaron de la misma manera y al mismo tiempo, y se cargaron utilizando archivos de módulo idénticos (excepto por una pequeña diferencia en la ruta base). Las instalaciones son, por lo que puedo verificar fácilmente, idénticas (los mismos archivos de inclusión existen en ambos clústeres y tienen el mismo contenido).

El resultado de g++ -v es el mismo en ambos clústeres (de nuevo, a excepción de la ruta de instalación):

Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/andyras/bin/gcc-4.9.1/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.1/configure --prefix=/home/andyras/bin/gcc-4.9.1 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.9.1 (GCC)

g++ -v utilizando el sistema GCC da el mismo resultado en ambos clusters, excepto en el clúster 1, dice que es gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) y en el clúster 2 dice gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)

Estoy intentando depurar usando g++ -std=c++11 -save-temps -MD example.cpp para más información ... esto da algunas pistas, pero no sé a dónde ir desde aquí.

A los archivos intermedios ( .ii ) del clúster 1 les faltan algunas líneas, por ejemplo (extracto de los archivos .ii ):

< # 277 "/opt/gcc-4.9.1/include/c++/4.9.1/cwchar" 3 --- > # 277 "/home/andyras/bin/gcc-4.9.1/include/c++/4.9.1/cwchar" 3 961,963c934,936 < using std::wcstold; < using std::wcstoll; < using std::wcstoull; --- > > >

A medida que lo interpreto, GCC en ambos clusters intenta incluir archivos como cwchar , pero en el clúster 1 hay líneas en blanco en lugar de definir cosas. En el clúster 2, la función stod está en el archivo intermedio, pero no en el clúster 1 .

¿Podría ser un error del preprocesador?

Ahora mirando los archivos .d (dependencia), también veo una diferencia concreta. Hay algunos archivos enumerados en el clúster 2 que no figuran en el clúster 1 . Aquí está la lista (procesé el contenido de los archivos .d para tener en cuenta las diferentes rutas base; // representa la ruta de instalación):

85a86,108 > //gcc-4.9.1/include/c++/4.9.1/ext/string_conversions.h > //gcc-4.9.1/include/c++/4.9.1/cstdlib > /usr/include/stdlib.h > /usr/include/bits/waitflags.h > /usr/include/bits/waitstatus.h > /usr/include/sys/types.h > /usr/include/sys/select.h > /usr/include/bits/select.h > /usr/include/bits/sigset.h > /usr/include/sys/sysmacros.h > /usr/include/alloca.h > //gcc-4.9.1/include/c++/4.9.1/cstdio > /usr/include/libio.h > /usr/include/_G_config.h > /usr/include/bits/stdio_lim.h > /usr/include/bits/sys_errlist.h > //gcc-4.9.1/include/c++/4.9.1/cerrno > /usr/include/errno.h > /usr/include/bits/errno.h > /usr/include/linux/errno.h > /usr/include/asm/errno.h > /usr/include/asm-generic/errno.h > /usr/include/asm-generic/errno-base.h

Tenía curiosidad si cpp estaba buscando en todos los lugares equivocados, pero esto parece legítimo ( cpp -v ):

#include <...> search starts here: /home/andyras/bin/gcc-4.9.1/include /home/andyras/bin/gcc-4.9.1/include/c++/4.9.1/ /home/andyras/bin/gcc-4.9.1/include/c++/4.9.1/x86_64-unknown-linux-gnu/ /home/andyras/bin/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include /usr/local/include /home/andyras/bin/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed /usr/include End of search list.

Este ha sido un par de horas muy frustrantes tratando de rastrear el origen del problema. Podría, por supuesto, usar algo como atof(myString.c_str()) lugar de std::stod , pero me pregunto si hay un problema subyacente que std::stod futuros proyectos usando otros bits de C ++ 11.

Cualquier otra pista o idea sería muy apreciada.

Bueno, obviamente tienes (como tú mismo escribiste) dos versoins diferentes de gcc (una vez 4.4.7-3 y la otra 4.4.7-4), y parece que tienen (aunque ligeramente) diferencias en la compilación del código .

Como he leído en alguna parte, el estándar C ++ 11 aún no se incluye por completo en todos los compiladores, por lo que esta parece ser la causa en un Clúster. El otro tiene (es posible que sepa por qué) una versión en la que se incluye más de la nueva norma y dado que desea utilizar exactamente esta característica, le recomiendo que instale esta versión en la otra agrupación.

Ya has hecho todos los pasos necesarios para determinar la causa raíz. Ya conoce la respuesta: ha publicado claras diferencias entre el comportamiento de las instalaciones de gcc personalizadas en su "clúster 1" y "clúster 2", una compilación que no funciona y funciona.

Entonces, algo es obviamente diferente entre estas dos instalaciones de gcc; si uno compila, enlaza y ejecuta algún código, y el otro se ahoga en el mismo fragmento exacto de código. Desafortunadamente, es difícil precisar dónde las cosas se descarrilan. Después de haber creado gcc antes, puedo decir que gcc es un paquete extremadamente difícil y muy difícil de instalar. Por ejemplo, después de varios días persiguiendo una misteriosa falla al vincular algún código C ++, terminé persiguiendo a gcc al elegir la versión incorrecta de binutils, en la secuencia de comandos de configuración de gcc, y desactivé internamente alguna característica oscura, que finalmente se manifestó como una falla de enlace no de gcc, sino de cosas que se generaron con gcc. gcc se compiló e instaló, sin embargo, como una queja, pero estaba roto.

Por lo tanto, considero totalmente sorprendente y totalmente plausible, la proposición de que el gcc mismo se construyó e instaló sin un problema aparente, pero está roto, y se ahogará con un código válido, de esta manera.

Supongo que su compilación de gcc retenida está utilizando una ruta de acceso predeterminada incluida, está buscando encabezados en /usr/include , en lugar de su propio directorio de instalación personalizado. Esa es la respuesta más probable, pero realmente podría ser cualquier cosa.