Форум по операционной системе GNU/Linux и свободному программному обеспечению
Текущее время: 20 сен 2019, 08:31

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 9 ] 
Автор Сообщение
Непрочитанное сообщениеДобавлено: 09 апр 2013, 17:55 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Разговор начат вот здесь: независимый от платформы код:

Olej писал(а):
Виктория писал(а):
Olej писал(а):
P.S. Я сейчас попробовал перенести в Windows приложения под Glib и GTK+, так создание среды сборки и исполнения там - задача "ещё та". Настолько, что отдельную тему я создам для памятки ... чтобы здесь частностями не засорять.

Сборка в Visual Studio 2008 или можно использовать clang?


Нет, насколько я понял, все порты GNU (Glib, GTK+, и др. ) для Windows делаются под компиляцию с помощью MinGW (там, где нужна сборка, а не устанавливается готовая бинарная инсталляция).
Так что приходится начинать с MinGW ... и далее.
В принципе, насколько я понял, можно компилятор MinGW (mingw32-gcc, например) пристроить компилятором проекта в Visual Studio...


Т.е. кроме того, что можно выбирать для разработки проектов разные программные прослойки переносимости:
Olej писал(а):
Итого, из тех инструментальных средств кросс-программирования, мы уже упомнили из тех, которые активно используются (не беря во внимание всякую экзотику):
- для C : APR, Glib;
- для C++ : Qt, Boost, Juce, Ultimate++;
- каждый из этих инструментов в своей группе (C или C++) - это полная альтернатива другим (т.е. Qt не заменяет Boost во многих аспектах, как и Boost не заменяет Qt в других аспектах ... но с точки зрения переносимости - они альтернативы).

... так вот это ПО переносимости нужно ещё и установить.
Даже более того: создать окружение для корректирования, компиляции-сборки и выполнения проектов, перенесенных сюда (в Windows ... не к ночи будет помянут ;-) ) из Linux.

Почему акцент (для меня) на установке этого ПО именно в Windows? ... переносится то программный код взаимно: из Windows в Linux ... из Linux в Windows ...
За что такие привилегии Windows? ;-)
Да потому, что:
- инструменты кросс-переносимости разрабатываются или в кругах UNIX, GNU (Glib, GTK+), либо в сторонних кругах близких к Linux/UNIX (APR, Qt, Boost, ... Eclipse, NetBeans, ...), но никогда в среде Microsoft и её сателитов...
- оно и понятно: зачем Microsoft миграция ПО из других сфер в Windows?
- но из-за этого такое ПО ставится в Linux ("на родине") - в-лёт ... а вот в Windows оно устанавливается "через задницу" ... т.е. сильно отличаясь от способов инсталляций в Windows ... построено на выдумке и фантазии разработчиков из GNU :lol:


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 09 апр 2013, 18:01 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
Нет, насколько я понял, все порты GNU (Glib, GTK+, и др. ) для Windows делаются под компиляцию с помощью MinGW (там, где нужна сборка, а не устанавливается готовая бинарная инсталляция).
Так что приходится начинать с MinGW ... и далее.


Это может и не так на 100% категорично (относительно необходимости MinGW помимо всяких прочих удовольствий), т.е. можно разыскать и использовать для всего готовые бинарные установки... но что-то мне не верится ... и об этом отчётливо сказано на странице установки GTK+:
Цитата:
The most natural toolchain to use together with these packages would probably be the GNU compiler and other utilities. When targeting Windows, that combination is known as MinGW. Using Cygwin tools to build non-Cygwin Windows binaries is not recommended unless you are very careful and look out for mixups.

It is possible to use these packages also with Microsoft's compiler. However, the DLLs here use the msvcrt.dll run-time library. This means that also applications that use the DLLs should preferably use the msvcrt.dll run-time. Specifically, this means that you should not use newer versions of the Microsoft compiler than Visual C++ 6 without knowing exactly what you are doing.


Так что начинать всё-равно с MinGW (хоть он непосредственно не входил в мои планы).


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 09 апр 2013, 18:10 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
Так что начинать всё-равно с MinGW (хоть он непосредственно не входил в мои планы).


Установка MinGW описана столько раз, что и комментировать её излишне:
- сайт проекта MinGW;
- простейший диалоговый инсталлятор - запустил и наслаждайся...

Важнейшим критическим шагом, который предстоит выполнить вручную - это добавить путь к MinGW каталогу bin (у меня это будет C:\MinGW\bin) к переменной окружения PATH. Проверкой правильности чего может быть "отклик" из консоли Windows gcc:
Код:
C:\MinGW\msys\1.0\home\olej\gthre>gcc --version
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
▌Єю ётюсюфэю ЁрёяЁюёЄЁрэ хьюх яЁюуЁрььэюх юсхёяхўхэшх. ╙ёыютш  ъюяшЁютрэш 
яЁштхфхэ√ т шёїюфэ√ї ЄхъёЄрї. ┴хч урЁрэЄшш ъръшї-ышсю ърўхёЄт, тъы■ўр 
ъюььхЁўхёъє■ ЎхээюёЄ№ ш яЁшьхэшьюёЄ№ фы  ъръшї-ышсю Ўхыхщ.


И это сюрприз номер 1:
- консоль Windows использует локаль исключительно CP-866 для совместимости с MS-DOS производства 1980 года...
- но MinGW, который сделан исключительно для использования в консоли Windows - разговаривает о чём-то своём ;-) ... в кодировке, предполагаю, CP-1251
- зачем?
- это у всех так?
- возможно, это для встраивания в разные IDE Windows (Visual Studio и др.), которые разговаривают на языке CP-1251? ... но это очень странное решение :-o

P.S. О маразмах буквоотображения, чтоб не отвлекаться, см. переносимость Lin<=>Win консольных приложений

Т.е. ... маразм крепчает ... потому как нам туда сейчас предстоит переносить Linux проекты (приложения), в которых текстовые строки пишутся в UTF-8 ...


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 апр 2013, 00:44 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
Так что начинать всё-равно с MinGW (хоть он непосредственно не входил в мои планы).


Дальше:
- Glib: https://developer.gnome.org/glib/stable/
- GTK+ : http://www.gtk.org/download/win32.php

Все эти (GNU) пакеты (под Windows) представляются в виде ./zip архивов, общий принцип установки всех, похоже одинаков:
- разархивировать (предупреждают, что лучше не делать это WinZip)...
- ... в любой каталог xxx
- в переменную PATH добавить xxx/bin

Такой ... довольно странненький для Windows способ инсталляций ;-)

Эти пакеты тянут за собой целый ряд зависимостей (которые так же нужно установить).
Но есть сторонние сборки, например all-in-one bundle, которые содержат GTK+ "всё в одном флаконе", а Glib входит в число зависимостей GTK+, поэтому устанавливается автоматом... Я воспользовался такой инсталляцией (поскольку меня интересует только проверка степени переносимости API, а не детальные разборки с пакетами).
- разархивировал...
- добаавил в PATH ... (C:\GTK\bin)
- PATH к этому времени принял вид:
Код:
C:\MinGW\bin>set PATH
Path=C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\WINDOWS\system32;C:\WIN
DOWS;C:\WINDOWS\System32\Wbem;C:\MinGW\bin;C:\GTK\bin;C:\Program Files\Microsoft
 SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\

- необходимые для сборки приложений опции компилятора:
Код:
C:\MinGW\bin>pkg-config --cflags gtk+-2.0
-mms-bitfields -IC:/GTK/include/gtk-2.0 -IC:/GTK/lib/gtk-2.0/include -IC:/GTK/in
clude/atk-1.0 -IC:/GTK/include/cairo -IC:/GTK/include/gdk-pixbuf-2.0 -IC:/GTK/in
clude/pango-1.0 -IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0/include -IC:/GTK
/include -IC:/GTK/include/freetype2 -IC:/GTK/include/libpng14

C:\MinGW\bin>pkg-config --libs gtk+-2.0
-LC:/GTK/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lpangowin32-1.
0 -lgdi32 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lcairo -lgobject-2.0 -l
gmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl

- и представленный в пакете GTK+ их тест:
Код:
C:\MinGW\bin>gtk-demo
...


Вложения:
gtk-demo.JPG
gtk-demo.JPG [ 33.65 КБ | Просмотров: 8658 ]
Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 апр 2013, 01:25 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
- необходимые для сборки приложений опции компилятора:


- собираю приложения, которые раньше показывал в Linux: glib.tgz

- собираю MinGW (gcc)...

- проекты для MinGW ищите в C:\MinGW\msys\1.0\home\<user> (у меня это C:\MinGW\msys\1.0\home\olej)

- сюрприз номер 2:
Код:
C:\MinGW\msys\1.0\home\olej\glib>mingw32-make gthre
gcc -Wall -mms-bitfields -IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0/include
   -LC:/GTK/lib -lgthread-2.0 -lglib-2.0 -lintl   gthre.c -o gthre
C:\Temp\cciw2IR2.o:gthre.c:(.text+0xd): undefined reference to `g_get_current_ti
me'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0x2a): undefined reference to `g_printf'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0x36): undefined reference to `g_usleep'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0x41): undefined reference to `g_get_current_t
ime'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0x54): undefined reference to `g_printf'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0x88): undefined reference to `g_thread_init'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0xc4): undefined reference to `g_thread_create
_full'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0xd4): undefined reference to `g_thread_join'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0xe9): undefined reference to `g_printf'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0xfe): undefined reference to `g_printf'
C:\Temp\cciw2IR2.o:gthre.c:(.text+0x113): undefined reference to `g_printf'
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: C:\Temp\cc
iw2IR2.o: bad reloc address 0x20 in section `.eh_frame'
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: final link
 failed: Invalid operation
collect2.exe: ю°шсър: т√яюыэхэшх ld чртхЁ°шыюё№ ё ъюфюь тючтЁрЄр 1
Makefile.0:21: recipe for target 'gthre' failed
mingw32-make: *** [gthre] Error 1

Как оказалось, этот GCC строку Makefile в прежней записи не понимает:
Код:
gthre: gthre.c
   $(CC) $(CGLIB) $(LGLIB) gthre.c -o gthre

А хочет он видеть только в угодном ему порядке параметров и опций:
Код:
gthre: gthre.c
   $(CC) gthre.c  $(CGLIB) $(LGLIB) -o gthre

Вот только так и никак иначе! ;-)

- переписываю (формально) Makefile, и пересборка:
Код:
C:\MinGW\msys\1.0\home\olej\glib>mingw32-make
gcc gthre.c -Wall -mms-bitfields -IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0
/include   -LC:/GTK/lib -lgthread-2.0 -lglib-2.0 -lintl   -o gthre
gcc gmutx.c -Wall -mms-bitfields -IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0
/include   -LC:/GTK/lib -lgthread-2.0 -lglib-2.0 -lintl   -o gmutx
gcc ggtk.c -Wall -mms-bitfields -IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0/
include   -mms-bitfields -IC:/GTK/include/gtk-2.0 -IC:/GTK/lib/gtk-2.0/include -
IC:/GTK/include/atk-1.0 -IC:/GTK/include/cairo -IC:/GTK/include/gdk-pixbuf-2.0 -
IC:/GTK/include/pango-1.0 -IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0/includ
e -IC:/GTK/include -IC:/GTK/include/freetype2 -IC:/GTK/include/libpng14   -LC:/G
TK/lib -lgthread-2.0 -lglib-2.0 -lintl   -LC:/GTK/lib -lgtk-win32-2.0 -lgdk-win3
2-2.0 -latk-1.0 -lgio-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lgdk_pixbuf
-2.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -l
intl   -o ggtk

Все 3 (gthre, gmutx, ggtk) из виденных раньше приложений собрались, файлы кода не правились, т.е. переносимость формально соблюдена.

- запуск:
Код:
C:\MinGW\msys\1.0\home\olej\glib>gthre.exe
╨╜╨░╤З╨░╨╗╨╛ ╨┐╨╛╤В╨╛╨║╨░ :     1365546262
╨║╨╛╨╜╨╡╤Ж ╨┐╨╛╤В╨╛╨║╨░ :       1365546263
╨▓╤А╨╡╨╝╤П ╨╛╨╢╨╕╨┤╨░╨╜╨╕╨╡ ╨╖╨░╨▓╨╡╤А╤И╨╡╨╜╨╕╤П ╨┐╨╛╤В╨╛╨║╨░ = 1

Выполнение многопототочного приложения происходит верно, с ожидаемым результатом, причём ожидаемо отработала служба времени, которые в Linux и Windows принципиально разные. Формат вывода - это "сюрприз №1", о котором уже было сказано.

- запуск GTK+ собранного приложения:
Код:
C:\MinGW\msys\1.0\home\olej\glib>ggtk.exe

Вложение:
gtkerr.JPG
gtkerr.JPG [ 11.5 КБ | Просмотров: 8656 ]


- сюрприз номер 3 ... но это уже, скорее, вопрос сборки установленного пакета GTK+ и поиска DLL ... поскольку их demo замечательно выполняется.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 апр 2013, 01:27 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
- сюрприз номер 1:
...
- сюрприз номер 2:
...
- сюрприз номер 3:
...


Вот такая вот ... кросс-платформенность: она как-бы и есть ... а как-бы над ней ещё работать и работать :-o


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 27 апр 2013, 19:13 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 28 дек 2012, 14:05
Сообщения: 113
Откуда: Самара
Olej писал(а):
Вот такая вот ... кросс-платформенность: она как-бы и есть ... а как-бы над ней ещё работать и работать :-o


Olej, Вам удалось убрать сюрпризы из-за проблем с локализацией?
Можно вместо MinGW использовать clang?


Вернуться к началу
 Профиль Отправить личное сообщение  
 
Непрочитанное сообщениеДобавлено: 28 апр 2013, 00:35 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Виктория писал(а):
Olej писал(а):
Вот такая вот ... кросс-платформенность: она как-бы и есть ... а как-бы над ней ещё работать и работать :-o


Olej, Вам удалось убрать сюрпризы из-за проблем с локализацией?
Можно вместо MinGW использовать clang?


Пока ничего не могу сказать более, не занимался этим вопросом.

Некоторым смягчением проблемы именно с локализацией есть то, что она присутствует только в консольных приложениях. А большинство реальных переносимых проектов (рассчитывающих на переносимость) ориентируются на графику. Графика (текст в графике) отображается средствами и шрифтами избранного фреймворка (GTK, Qt), и не будет зависеть от системы. Я так это понимаю. ;-)


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 27 авг 2013, 10:58 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
Некоторым смягчением проблемы именно с локализацией есть то, что она присутствует только в консольных приложениях. А большинство реальных переносимых проектов (рассчитывающих на переносимость) ориентируются на графику. Графика (текст в графике) отображается средствами и шрифтами избранного фреймворка (GTK, Qt), и не будет зависеть от системы.


Альтернативным вариантом (очень неплохим вариантом) для создания проектов, не зависящих от операционной системы, есть использование языка Python:
- для написания даже очень крупных программных проеектов - подтверждение: проект Open Stack, который сейчас раскручивает RedHat...
- инструмент Python присуитствует во всех операционных системах: Windows, Linux, Solaris, FreeBSD, QNX, ...
- насколько я наблюдал - никаких проблем с локализациями, ни в консольных ни в GUI приложениях (Python по умолчанию использует раскладку Unicode в кодировке UTF-8)
- для GUI интерпретируемость Python - большое преимущество: а). можно на ходу подправить вид и добавить виджеты, б). а ориентация на человека, событийное управление GUI сильно нивелирует некоторое снижение скорости за счёт интерпретируемости.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 9 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB
[ Time : 0.310s | 19 Queries | GZIP : On ]