Russian Qt Forum
Сентябрь 22, 2024, 13:31 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: QTextStream txtOut( stdout ) - ошибка в ntdll.dll  (Прочитано 8747 раз)
Zmeishe
Гость
« : Июль 07, 2009, 11:46 »

Qt 4.5.1

В Линуксе никаких проблем - код рабочий.

Портирую на Windows XP

Использовать компилятор НЕ от MS не могу из-за api OpenOffice

Поэтому сборку делал компилятором nmake от MSVS 2005 тоже всё работало без проблем.
Но т.к. Студия вшивает зависимость от .NET приходиться таскать на компьютеры клиентов 200 метров барахла.
Я пересобрал QT и свой проект и избавился от зависимости .NET
Все модули прекрасно работают. Ну слегка потолстели на 40Кб - думаю это адекватная плата за отсутствие .NET

И только в одной маленькой консольной служебной утилитке используется строчка кода:
QTextStream txtOut( stdout );
на ней теперь Винда предлагает отправить отчёт в MS.
так тоже пробовал:
QFile fileOut( stdout );
QTextStream txtOut( &fileOut );

тоже самое - отваливается на QFile fileOut( stdout );

Как же тогда работать с std ? Где собака-то порылась?
« Последнее редактирование: Июль 07, 2009, 11:49 от Zmeishe » Записан
f-r-o-s-t
Гость
« Ответ #1 : Июль 07, 2009, 11:52 »

В .pro есть CONFIG += console ?
Записан
Zmeishe
Гость
« Ответ #2 : Июль 07, 2009, 11:57 »

Для этой утилиты - есть.
Записан
Zmeishe
Гость
« Ответ #3 : Июль 07, 2009, 17:02 »

Блин, измучился так и не понял почему без .NET не хочет работать QTextStream( stdout );
Сделал через cout << , но пришлось ко всем строкам добавлять .toLatin1().data()

Не по фен-шую это!
Записан
ритт
Гость
« Ответ #4 : Июль 08, 2009, 08:07 »

последнее, что приходит на ум: #include <qt_windows.h> (или аналог) имеется?
Записан
Zmeishe
Гость
« Ответ #5 : Июль 08, 2009, 12:05 »

#include <qt_windows.h> не поможет.

У класса QTextStream
есть конструктор QTextStream ( FILE * fileHandle, QIODevice::OpenMode openMode = QIODevice::ReadWrite )

для того, чтобы он знал FILE * fileHandle, в файле qtextstream.h
есть #include <stdio.h>

Вопрос лишь в том, откуда он берётся во время компиляции ?
Подозреваю, что из "C:\Program Files\Microsoft Visual Studio 8\VC\include" - больше не откуда.
Но даже если бы он брался из "C:\MinGW\include" это не должно вызывать ошибку - исходники stl, они в Африке stl.

Методом дедукции подходим к линкеру.
Вот где и что он берёт, когда линкуется с stl`ными функциями?
Похоже, что та .lib, и собрана для .NET

Или что-то ещё?
Записан
shadone
Гость
« Ответ #6 : Июль 10, 2009, 19:36 »

Поэтому сборку делал компилятором nmake от MSVS 2005 тоже всё работало без проблем.
Но т.к. Студия вшивает зависимость от .NET приходиться таскать на компьютеры клиентов 200 метров барахла.
Я пересобрал QT и свой проект и избавился от зависимости .NET
Все модули прекрасно работают. Ну слегка потолстели на 40Кб - думаю это адекватная плата за отсутствие .NET

расскажите в этом месте поподробнее - что именно сделали и про какую зависимость от .NET идет речь? Для работы c++ приложения собранного с помощью msvc достаточно библиотек рантайма (который устанавливаются с помощью redistributable package).
Записан
Zmeishe
Гость
« Ответ #7 : Июль 11, 2009, 07:43 »

Устанавливал Студию выборочно. FrameWork ставить не стал - мне нужен был только компилятор.
Ничего не работает. Поставил ещё раз, с FrameWork`ом - заработало.
Собрал Qt, собрал свой Линуксовый проект - на моей машине всё в "шоколаде".
Поставил на чистую Винду - не работает. Сначала писАл об отсутствии библиотек Qt...dll. Ну ебстественно...
Скопировал Qt библиотеки - перестал что-либо спрашивать, но не работает. Программы не стартуют - молча не стартуют.
Вспомнив, что Студия вела себя аналогично - поставил FrameWork 2.0 на чистую Винду. Проект заработал.

Сделал вывод - Студия вшила зависимость от FrameWork 2.0
Пошерстил но форуму.
> make confclean
 - в файле
./mkspecs/win32-msvc2005/qmake.conf
заменил QMAKE_CFLAGS_RELEASE = -O2 -MD -GL
на QMAKE_CFLAGS_RELEASE = -O2 -MT

из CONFIG выкинул embed_manifest_dll embed_manifest_exe

> configure
> make

собрал Qt, собрал свой проект.
На тестовой машине снёс FrameWork 2.0
Проект работает.
Не работает одна утилитка со строчкой QTextStream txtOut( stdout );

Дело в том, что QTextStream знаком с QString, а cout нет.
Я, конечно, выкрутился наставив везде cout << QString().toLatin1().data(), но
хотелось бы по фен-шую QTextStream() << QString().
К тому же QTextStream ещё и QTextCodec знает...
Записан
shadone
Гость
« Ответ #8 : Июль 12, 2009, 10:06 »

Поставил на чистую Винду - не работает. Сначала писАл об отсутствии библиотек Qt...dll. Ну ебстественно...
Скопировал Qt библиотеки - перестал что-либо спрашивать, но не работает. Программы не стартуют - молча не стартуют.
Вспомнив, что Студия вела себя аналогично - поставил FrameWork 2.0 на чистую Винду. Проект заработал.

Сделал вывод - Студия вшила зависимость от FrameWork 2.0

странные вывод - причина со следствием абсолютно не связаны.
Как я написал выше - для работы приложения собранного с помощью компилятора msvc необходимо наличие redistributable package.
 
Пошерстил но форуму.
> make confclean
 - в файле
./mkspecs/win32-msvc2005/qmake.conf
заменил QMAKE_CFLAGS_RELEASE = -O2 -MD -GL
на QMAKE_CFLAGS_RELEASE = -O2 -MT

из CONFIG выкинул embed_manifest_dll embed_manifest_exe

> configure
> make

собрал Qt, собрал свой проект.
На тестовой машине снёс FrameWork 2.0
Проект работает.
Не работает одна утилитка со строчкой QTextStream txtOut( stdout );

Дело в том, что QTextStream знаком с QString, а cout нет.
Я, конечно, выкрутился наставив везде cout << QString().toLatin1().data(), но
хотелось бы по фен-шую QTextStream() << QString().
К тому же QTextStream ещё и QTextCodec знает...
конечно не будет работать. мало-того, половина Qt может перестать работать, про утечки памяти я уж молчу.
если вы прочитали в документации что значат эти опции то должно быть понятно что вы заменили dynamic runtime library на static runtime, соответственно все объекты рантайма локальны в каждом модуле, в том числе куча (насколько я помню windows по-умолчанию использует локальную кучу), например на любой new в динамической библиотеке, соответствующий delete в приложении (т.е. другом модуле) будет просто падать.

Такой режим использования Qt не поддерживается разработчиками.
Записан
Zmeishe
Гость
« Ответ #9 : Июль 12, 2009, 10:19 »

Ясно.
Спасибо.
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.047 секунд. Запросов: 21.