Здравствуйте, Lucky Cat, Вы писали:
LC>Здравствуйте, niXman, Вы писали:
X>>сейчас производится тестирование MSYS2. X>>скачайте лучше его, и опишите свои впечатления/проблемы
LC>Скачал, пробую. LC>Первые впечатления сыроват, зато тулзы свежее, тот же bison. LC>git/svn работает, hg — нет, чтоб заработал пришлось из дистра питоновского версии 2.7 сопировать в папку /include/python2.7 копировать содержимое папки include питоновского дистра.
Исправлено в сегодняшнем снапшоте: http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130613.tar.xz/download http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130613.tar.xz/download
LC>То есть польза от msys2 видна, будем разбираться дальше.
LC>Теперь что касается сборок gcc, пробую на версии 4.8.1 собрать wxWidgets из репозитория. LC>Статичесую библиотеку собирает, динамическую — нет. LC>Причем из под cmd пишет "d:/gcc/mingw4.8.1/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/ld.exe: gcc_mswudll\coredll_msw_textentry.o: bad reloc address 0x4 in section `.data' LC>collect2.exe: error: ld returned 1 exit status" LC>При запуске из под msys/msys2 аналогичная выдача линкера.
LC>Что характерно, TDM 4.7.1-2 динамическую библиотеку собрал. Вот думаю в чем причина. LC>Что посоветуете? Уж очень нехочется на TDM сидеть.
В новом снапшоте в файле /etc/fstab НЕ УДАЛЯЙТЕ строку с дефолтной точкой монтирования. Она предназначена для избавления от префикса /cygdrive
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Lucky Cat, Вы писали:
LC>>Первые впечатления сыроват X>да, есть такое. X>работаем.
LC>>git/svn работает, hg — нет, чтоб заработал пришлось из дистра питоновского версии 2.7 сопировать в папку /include/python2.7 копировать содержимое папки include питоновского дистра. X>это уже известный баг. Алексей поправит на днях.
Попробую рецепт, спасибо.
Не знаю имеет ли это отношению к делу или я шину пинаю, но в ваших сборках binutils 2.23.2, а в TDM — 2.22.
Может тут собака порылась?
В общем пробую
Спасибо, уже качаю.
LC>>То есть польза от msys2 видна, будем разбираться дальше.
LC>>Теперь что касается сборок gcc, пробую на версии 4.8.1 собрать wxWidgets из репозитория. LC>>Статичесую библиотеку собирает, динамическую — нет. LC>>Причем из под cmd пишет "d:/gcc/mingw4.8.1/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/ld.exe: gcc_mswudll\coredll_msw_textentry.o: bad reloc address 0x4 in section `.data' LC>>collect2.exe: error: ld returned 1 exit status" LC>>При запуске из под msys/msys2 аналогичная выдача линкера.
LC>>Что характерно, TDM 4.7.1-2 динамическую библиотеку собрал. Вот думаю в чем причина. LC>>Что посоветуете? Уж очень нехочется на TDM сидеть.
A>В новом снапшоте в файле /etc/fstab НЕ УДАЛЯЙТЕ строку с дефолтной точкой монтирования. Она предназначена для избавления от префикса /cygdrive
Ок. А в fstab так понимаю грозное предупреждение прописано? А то еще не скачал не распаковал
Да, еще тонкий момент, обычно у меня батник прописан с командой cmd /k <путь к msys>/msys.bat
А вот новая запускалка msys2_shell.bat работает только из своей папки, если в батнике прописать
переход в ее папку и запуск cmd /k msys2_shell.bat, запускается окно cmd и окно sh.
Я переписал из старого msys msys.bat в папку к msys2_shell.bat и стал запускать новый шелл из любого места на диске.
хм.. второй — дельный только последний пост. и к тому же, от автора TDM. и вдобавок, я не вижу там никакого призыва юзать TDM в третьем — ответ тот же, что и во втором('windres needs -F pe-i386'). и так же, никакого призыва юзать TDM
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Ну не то чтоб рекомендуют, просто в двух ссылках речь о TDM фраза насчет успешной сборки под TDM малость бесполезны в моей ситуации.
Ну и воспринимаются как реклама
X>хм.. X>второй — дельный только последний пост. и к тому же, от автора TDM. и вдобавок, я не вижу там никакого призыва юзать TDM X>в третьем — ответ тот же, что и во втором('windres needs -F pe-i386'). и так же, никакого призыва юзать TDM
Честно говоря не совсем понял насчет 'windres needs -F pe-i386'.
Я все пытаюсь понять почему линкер глючит, все больше кажется, в нем дело.
В 64битной сборке битые ссылки python.exe и python2.exe на python2.7.exe(если не попутал ничего)
Не хватает tcl, wish с dll-ками, не хватает в /lib папки tcl8.
Если все это добавить, то gitk начинает работать, а то либо не запускается жалуясь на отсутствие wish, либо на отсутствие msgcat.
Я так и решил проблемку
LC>>Не хватает tcl, wish с dll-ками, не хватает в /lib папки tcl8. LC>>Если все это добавить, то gitk начинает работать, а то либо не запускается жалуясь на отсутствие wish, либо на отсутствие msgcat. A>Я не собирал еще tcl/tk под MSYS2.
В наборе программ gitk есть, но не работает.
Тут либо gitk убрать, либо временно добавить tcl/tk из msys
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Lucky Cat.
X>опиши пошагово, как собираешь и что получаешь.
Запускаю оболочку с настроенными на MinGW путями.
Захожу в папку wxWidgets\build\msw.
Запускаю команду mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release
На выходе куча сообщений "Cannot get section contents — auto-import exception"
gcc_mswudll\coredll_msw_textentry.o:textentry.cpp.rdata$_ZTI21wxTextCompleterS
imple[_ZTI21wxTextCompleterSimple]+0x1628e9ce3c012c0): Cannot get section conten
ts — auto-import exception
gcc_mswudll\coredll_msw_textentry.o:textentry.cpp.rdata$_ZTI20wxTextCompleterF
ixed[_ZTI20wxTextCompleterFixed]+0x58a3a738f004aa0): Cannot get section contents
— auto-import exception
gcc_mswudll\coredll_msw_textentry.o:textentry.cpp.rdata$_ZTI11IEnumString[_ZTI
11IEnumString]+0x58a3a738f004a850): Cannot get section contents — auto-import ex
ception
gcc_mswudll\coredll_msw_textentry.o:textentry.cpp.rdata$_ZTI13wxIEnumString[_Z
TI13wxIEnumString]+0x1d39c7802541b930): Cannot get section contents — auto-impor
t exception
gcc_mswudll\coredll_msw_textentry.o:textentry.cpp.rdata$_ZTI20wxEventFunctorMe
thodI14wxEventTypeTagI10wxKeyEventE22wxTextAutoCompleteDataS1_S3_E[_ZTI20wxEvent
FunctorMethodI14wxEventTypeTagI10wxKeyEventE22wxTextAutoCompleteDataS1_S3_E]+0x3
a738f004a837240): Cannot get section contents — auto-import exception d:/gcc/gcc64_4.9.0/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w6
4-mingw32/bin/ld.exe: gcc_mswudll\coredll_msw_textentry.o: bad reloc address 0x1
0 in section `.data'
collect2.exe: error: ld returned 1 exit status
makefile.gcc:9780: recipe for target '..\..\lib\gcc_dll\wxmsw295u_core_gcc_custo
m.dll' failed
mingw32-make: *** [..\..\lib\gcc_dll\wxmsw295u_core_gcc_custom.dll] Error 1
PS Msys явно ни при чем, тут чистый MinGW используется.
PPS При сборке статической библиотеки все нормально собирается.
mingw32-make -f makefile.gcc SHARED=0 UNICODE=1 MONOLITHIC=1 BUILD=release
Здравствуйте, Lucky Cat, Вы писали:
LC>Здравствуйте, niXman, Вы писали:
X>>Здравствуйте, Lucky Cat, Вы писали:
LC>>>gcc version 4.9.0 20130615 (experimental) (Built by MinGW-builds project)
X>>а с версией 4.7.2-4.7.3, как обстоят дела?
LC>На версии 4.7.2 не проверял, а версии 4.7.3, 4.8.0 и 4.8.1 так же. LC>Грешу на линкер. Во всех пробованных сборках одна и та же версия бинутилза
Более того, собранная статически либа не может использоваться, так как линкер при компоновке wx проги с статической либой выдает точно такую же ошибку, что и при сборке динамической либы.
Это проверял на 4.9.0 только. ИЧСХ с динамической либой собранной TDM нормально линкует.
популярность MinGW-builds растет, и кол-во пользователей тоже.
в связи с этим, есть желание переименовать MinGW-builds в нечто более осмысленное и запустить для него отдельный сайт.
предлагайте.
благодарен.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>популярность MinGW-builds растет, и кол-во пользователей тоже. X>в связи с этим, есть желание переименовать MinGW-builds в нечто более осмысленное и запустить для него отдельный сайт. X>предлагайте.
X>благодарен.
А там по прежнему не работает ни одна std::locale кроме "C"? ) Кстати, феерическая ситуация с учётом того, что в C библиотеке того же MinGW все локали работают нормальное... )))
Здравствуйте, alex_public, Вы писали:
_>А там по прежнему не работает ни одна std::locale кроме "C"? )
даже не знаю, никогда не использовал std::locale. и, похоже, никто из юзеров.
_>Кстати, феерическая ситуация с учётом того, что в C библиотеке того же MinGW все локали работают нормальное... )))
приведи пример, который работает с MinGW и не работает с MinGW-builds.
и, версии используемых компиляторов и командные строки, пожалуйста.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>приведи пример, который работает с MinGW и не работает с MinGW-builds. X>и, версии используемых компиляторов и командные строки, пожалуйста.
Не о том речь. Я имел в виду что setlocale(LC_ALL, "Russian_Russia.866") работает полностью корректно, а std::locale("Russian_Russia.866") посылает очень далеко. Фееричность ситуации в том, что в итоге в скомпилированном приложение находится необходимый код, но он при этом как бы недоступен из C++.
X>даже не знаю, никогда не использовал std::locale. и, похоже, никто из юзеров.
Очаровательно... А ничего что например после вызова setlocale(LC_ALL, "Russian_Russia.866") функции printf("%g\n", 0.12345) и cout<<0.12345<<endl будут выдавать разные результаты? ) И с учётом этой "фичи" mingw это фиг изменишь...
Ну точнее теоретически то это исправляется, подключением boost.locale, работающей через icu. Но с учётом размеров icu это выглядит мягко говоря ненормально для обычных ситуаций. Тем более что в других компиляторах (и gcc под линух и msvc и т.д.) std::locale работает вполне нормально.
Здравствуйте, alex_public, Вы писали:
_>Не о том речь. Я имел в виду что setlocale(LC_ALL, "Russian_Russia.866") работает полностью корректно, а std::locale("Russian_Russia.866") посылает очень далеко.
так это известная проблема. правда, пока не вникал, почему она существует...
если есть желание полечить — велкам.
_>Очаровательно... А ничего что например после вызова setlocale(LC_ALL, "Russian_Russia.866") функции printf("%g\n", 0.12345) и cout<<0.12345<<endl будут выдавать разные результаты?
всего однажды приходилось использовать локали, и использовал — boost.locale. не потому, что std::locale не работает, а потому что дока к boost.locale оказалась понятней.
и да, дело было в линуксе.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
.rdata$_ZTI21wxTextCompleterS
