std :: endl приводит к сбою Windows 8, скомпилированному с использованием MinGW

У меня есть 3 компьютера, два из которых используют Windows 8. Используя последнюю версию MinGW g ++ (4.8.1-4), моя программа hello world зависает при компиляции и запуске на компьютерах с Windows 8, но не в Windows 7.

#include <iostream>
int main()
{
std::cout << "Hello, World!" <<std::endl;
return 0;
}

Это прекрасно компилируется в g ++, но при запуске a.exe отобразится «Hello, World!» затем появится окно с сообщением «a.exe перестал работать, Windows может проверить в Интернете решение проблемы с программой ….» и т. д.

Кто-нибудь видел эту проблему.

Также я попробовал «std :: cout» << «Привет, мир! \ N» << std :: flush; «и это та же проблема. Кажется, что каждая функция, которая очищает буфер, вызывает сбой.

Следуя совету Эрика, я перекомпилировал программу, запустил ее в gdb и получил следующий вывод:

Program received signal SIGILL, Illegal instruction.
0x00405065 in _Jv_RegisterClasses ()

9

Решение

Во втором случае ‘\ n’ должен вызывать сброс выходных данных в любом случае, хотя в Windows я считаю, что вывод на консоль немедленный (или, возможно, автоматический после короткого времени ожидания) в любом случае без явного сброса.

Я предлагаю следующие эксперименты:

1) Посмотрите, является ли она специфичной для библиотеки C ++ с помощью библиотеки C (в MinGW Microsoft использует среду выполнения C вместо glibc):

#include <stdio.h>
int main()
{
printf( "Hello, World!\n" ) ;
return 0;
}

2) устранить код выхода путем:

int main()
{
return 0;
}

3) Нет новой строки вообще:

#include <iostream>
int main()
{
std::cout << "Hello, World! ;
return 0;
}

4) Попробуйте разные варианты компилятора, такие как уровни оптимизации или -fno-builtin например, или как предложено Вот: -static-libgcc -static-libstdc++ (хотя я сомневаюсь, что `-static-libgcc` сам по себе будет иметь какой-либо эффект, поскольку MinGW использует библиотеку DLL времени выполнения C от Microsoft, а статическая библиотека доступна только с инструментами Microsoft).

6

Другие решения

У меня возникла та же проблема, и я обнаружил, что после долгих мучительных поисков на моем компьютере было установлено несколько версий mingw, предоставленных libstdc ++ — 6.dll. Один был частью установки mingw, другие были частью других установочных пакетов (gnuplot и GIMP). Поскольку у меня был gnuplot в моем PATH, скомпилированный mingw exe, он использовал бы более старую несовместимую версию этой dll и падал с описанными симптомами. Поэтому я могу подтвердить подозрение Дитмара Кюля. Как указывалось выше, статическая компоновка библиотеки, очевидно, помогает в этом случае, поскольку библиотечные функции включаются в exe во время компиляции.

0

По вопросам рекламы [email protected]