Насколько трудоёмко включить в пакет gdc с arm целью?

Здравствуйте, glap, Вы писали:

G>Насколько трудоёмко включить в пакет gdc с arm целью?
нужно пробовать. иначе — ничего сказать не могу..
но в MinGW-builds это включено не будет, если вдруг Вы об этом думаете.

Здравствуйте, niXman, Вы писали:

X>но в MinGW-builds это включено не будет
точнее: оно возможно когда-то и будет включено, но не с arm целью.

к тому же, несколько месяцев назад, в списке рассылки GCC, поднимался вопрос об интеграции кодов gdc в gcc. но я не следил за тредом, так что не знаю, к чему оно пришло...

Здравствуйте, niXman, Вы писали:

X>к тому же, несколько месяцев назад, в списке рассылки GCC, поднимался вопрос об интеграции кодов gdc в gcc. но я не следил за тредом, так что не знаю, к чему оно пришло...

Мне окружение библиотечное вообще не нужно. Всё будет прокинуто через c++ код.

Так давно хочу применить D в реальном проекте, но вечно какие-то проблемы. Сейчас вот нужно сразу собирать и под 86 и под arm один код под виндой. В общем я особо и не надеюсь, что это получится, но вдруг кого-то это тоже заинтересует.

вчера состоялся релиз gcc-4.8.0.
уже сейчас вы можете скачать сборки MinGW на базе gcc-4.8.0 со страницы проекта.
в 4.8.0 для windows платформы, появилась возможность использовать SEH(1, 2). но, из-за патентных ограничений, эта возможность доступна только в x86_64 сборках.

Если ввести команду perl -MSVN::Core -e'print "ok\n";', то выведется сообщение об ошибке

Can't load '/usr/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core/_Core.dll' for module SVN::_Core: dlopen: Win32 error 126 at /usr/lib/perl5/5.8/msys/DynaLoader.pm
line 230.
at /usr/lib/perl5/site_perl/5.8/msys/SVN/Base.pm line 59
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8/msys/SVN/Core.pm line 5.
Compilation failed in require.
BEGIN failed--compilation aborted.

Примерно такое же сообщение об ошибке выводится при попытке ввести git svn rebase

Если посмотреть зависимости _Core.dll, то выясняется, что она зависит в том числе от файла, которого в сборке нет.
Не подскажете, где взять этот файл для 64 битного Windows?

Здравствуйте, Аноним, Вы писали:

А>Can't load '/usr/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core/_Core.dll'
я, честно говоря, вообще не вижу этой dll`ки %)

А>Примерно такое же сообщение об ошибке выводится при попытке ввести git svn rebase
говорит: "Can't locate Git/SVN.pm"
этого, я тоже не вижу.

попробую разузнать...

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Аноним, Вы писали:

А>>Can't load '/usr/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core/_Core.dll'
X>я, честно говоря, вообще не вижу этой dll`ки %)

Может я как-то не так выразился. Файл _Core.dll находится в архиве
external-binary-packages/msys+7za+wget+svn+git+mercurial+cvs-rev13.7z

Относительно корня архива путь будет msys/lib/perl5/site_perl/5.8/msys/auto/SVN/_Core .

Здравствуйте, Аноним, Вы писали:

А>Может я как-то не так выразился. Файл _Core.dll находится в архиве
А>external-binary-packages/msys+7za+wget+svn+git+mercurial+cvs-rev13.7z
уже понял. у меня rev11.

Я посмотрел Portable Msys git. Там есть этот файл, но переписывание его в директорию bin в msys из mingw-builds ситуацию не исправляет.
Может быть это потому, что в msys из mingw-builds хоть и нет файла LIBAPR-0-0.DLL, но есть файл libapr-1.dll .
Может дело в том, что _Core.dll должен был зависеть именно от файла libapr-1.dll, а при сборке что-то перепуталось?

Здравствуйте, Аноним, Вы писали:

А>Я посмотрел Portable Msys git. Там есть этот файл, но переписывание его в директорию bin в msys из mingw-builds ситуацию не исправляет.

да, я вчера тоже понял что этой dll`ки не хватает. в добавок, LIBAPR-0-0.DLL тянет с собой еще несколько dll`ок, я их тоже скопировал, и в результате получаю сегфолт:
MSYS-1.0.17 Build:2011-04-24 23:39
Exception: STATUS_ACCESS_VIOLATION at eip=66DB13DD
eax=00000000 ebx=104D2144 ecx=10020370 edx=01011007 esi=000016B8 edi=ADADEDFE
ebp=0028EB78 esp=0028EB60 program=D:\msys\bin\perl.exe
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028EB78 66DB13DD (104D2144, 0028EBA4, 66DF00D4, 00000000)
0028EBA8 66DEDAC0 (104D2144, 104DBB88, 10020370, 10020370)
0028EBD8 56C58D86 (104D2144, 1048C9EC, 00000002, 10571C48)
0028EC08 56C6414A (103EB108, 103EB108, 0028EDA8, 56C044C5)
0028EC18 56C538C8 (0028ED70, 00000000, 00000000, 00000000)
0028EDA8 56C044C5 (1048C89C, 00000006, 00000000, 00000000)
0028EDC8 56C07CBB (1048C89C, 00000000, 0028EEC8, 00000000)
0028EEE8 56C07989 (0000000B, 1048C848, 10067808, 10067808)
0028EFB8 56C3A2FA (0000020D, 10492108, 00000000, 00000000)
0028F008 56C35AE4 (00000001, 0000020D, 00000000, 104921C8)
0028F088 56C2E865 (103D86C8, 00000006, 0028F0B8, 56C79216)
0028F0B8 56C993D7 (00000000, 00000000, 00000000, 00000C6E)
0028F188 56C9A743 (103E9708, 103E9708, 0028F328, 56C044C5)
0028F198 56C538C8 (0028F2F0, 00000000, 00000000, 00000000)
0028F328 56C044C5 (103E19A4, 00000006, 00000000, 00000000)
0028F348 56C07CBB (103E19A4, 00000000, 0028F448, 00000000)
End of stack trace (more stack frames may be present)

и тут мои идеи заканчиваются %)

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Аноним, Вы писали:

А>>Я посмотрел Portable Msys git. Там есть этот файл, но переписывание его в директорию bin в msys из mingw-builds ситуацию не исправляет.

X>да, я вчера тоже понял что этой dll`ки не хватает. в добавок, LIBAPR-0-0.DLL тянет с собой еще несколько dll`ок, я их тоже скопировал, и в результате получаю сегфолт:
X>MSYS-1.0.17 Build:2011-04-24 23:39
X>Exception: STATUS_ACCESS_VIOLATION at eip=66DB13DD
X>eax=00000000 ebx=104D2144 ecx=10020370 edx=01011007 esi=000016B8 edi=ADADEDFE
X>ebp=0028EB78 esp=0028EB60 program=D:\msys\bin\perl.exe
X>cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
X>Stack trace:
X>Frame Function Args
X>0028EB78 66DB13DD (104D2144, 0028EBA4, 66DF00D4, 00000000)
X>0028EBA8 66DEDAC0 (104D2144, 104DBB88, 10020370, 10020370)
X>0028EBD8 56C58D86 (104D2144, 1048C9EC, 00000002, 10571C48)
X>0028EC08 56C6414A (103EB108, 103EB108, 0028EDA8, 56C044C5)
X>0028EC18 56C538C8 (0028ED70, 00000000, 00000000, 00000000)
X>0028EDA8 56C044C5 (1048C89C, 00000006, 00000000, 00000000)
X>0028EDC8 56C07CBB (1048C89C, 00000000, 0028EEC8, 00000000)
X>0028EEE8 56C07989 (0000000B, 1048C848, 10067808, 10067808)
X>0028EFB8 56C3A2FA (0000020D, 10492108, 00000000, 00000000)
X>0028F008 56C35AE4 (00000001, 0000020D, 00000000, 104921C8)
X>0028F088 56C2E865 (103D86C8, 00000006, 0028F0B8, 56C79216)
X>0028F0B8 56C993D7 (00000000, 00000000, 00000000, 00000C6E)
X>0028F188 56C9A743 (103E9708, 103E9708, 0028F328, 56C044C5)
X>0028F198 56C538C8 (0028F2F0, 00000000, 00000000, 00000000)
X>0028F328 56C044C5 (103E19A4, 00000006, 00000000, 00000000)
X>0028F348 56C07CBB (103E19A4, 00000000, 0028F448, 00000000)
X>End of stack trace (more stack frames may be present)

X>и тут мои идеи заканчиваются %)

У меня в зависимостях LIBAPR-0-0.DLL только MSYS-1.0.DLL. Остальное — майкрософтовские dll, которые в системе уже есть.
Но MSYS-1.0.DLL в msys из mingwg builds отличается от MSYS-1.0.DLL из portable git по размеру.

Я не очень хорошо ориентируюсь в теме, но повторю свои подозрения, что в сборке из mingwg builds
используется набор библиотек libapr* другой (новой) версии, а _Core.dll слинкован с dll старой версии.

И по идее надо пересобрать _Core.dll .

Скажите, как собирается msys из mingw builds? Есть исходники?

Здравствуйте, Аноним, Вы писали:

А>У меня в зависимостях LIBAPR-0-0.DLL только MSYS-1.0.DLL. Остальное — майкрософтовские dll, которые в системе уже есть.
упс, сорри, напутал %)
зависимости у _Core.dll

А>Но MSYS-1.0.DLL в msys из mingwg builds отличается от MSYS-1.0.DLL из portable git по размеру.
там еще и версии %)

А>Я не очень хорошо ориентируюсь в теме, но повторю свои подозрения, что в сборке из mingwg builds
А>используется набор библиотек libapr* другой (новой) версии, а _Core.dll слинкован с dll старой версии.
git и svn комплектовал другой человек, сопроектник. сейчас зареквестирую его в тред.

А>Скажите, как собирается msys из mingw builds? Есть исходники?
нет.
git и svn входящие в msys от mingw-builds, это не собранные нами программы. мы просто скопировали exe`шки и dll`ки.

Мы выпустили он-лайн инсталлятор для mingw-builds, который вы можете <b>скачать</b> на странице нашего проекта.
Ждем ваших замечаний и предложений.

P.S.: неделю назад был выпущен GCC-4.8.1, сборки которого также <b>доступны</b> на странице проекта. и на странице проекта.

P.S.P.S : В течение некоторого времени занимаюсь созданием MSYS2 на основе последнего Cygwin. Выложил <b>alpha</b> сборки, если кого интересует.

добавлю: инсталлятор получает всю необходимую информацию из этого файла. так что обновлять инсталлятор при выходе новых сборок — не нужно.

Здравствуйте, niXman:

Во первых гранмерси за сборки MinGW под винду, избавляете от кучи проблем.
Во вторых использую выложенный на вашем сайте msys, который в архиве msys+7za+wget+svn+git+mercurial+cvs-rev13.7z.
Так там gitk неработает. Если подсунуть в папку lib папку tcl8 от msysgit, что предлагается к установке с TortoiseGit, все начинает работать.
MsysGit брал тут https://code.google.com/p/msysgit/downloads/list

сейчас производится тестирование MSYS2.
скачайте лучше его, и опишите свои впечатления/проблемы

Здравствуйте, niXman, Вы писали:

X>сейчас производится тестирование MSYS2.
X>скачайте лучше его, и опишите свои впечатления/проблемы

Скачал, пробую.
Первые впечатления сыроват, зато тулзы свежее, тот же bison.
git/svn работает, hg — нет, чтоб заработал пришлось из дистра питоновского версии 2.7 сопировать в папку /include/python2.7 копировать содержимое папки include питоновского дистра.
То есть польза от msys2 видна, будем разбираться дальше.

Теперь что касается сборок gcc, пробую на версии 4.8.1 собрать wxWidgets из репозитория.
Статичесую библиотеку собирает, динамическую — нет.
Причем из под 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'
collect2.exe: error: ld returned 1 exit status"
При запуске из под msys/msys2 аналогичная выдача линкера.

Что характерно, TDM 4.7.1-2 динамическую библиотеку собрал. Вот думаю в чем причина.
Что посоветуете? Уж очень нехочется на TDM сидеть.

Здравствуйте, Lucky Cat, Вы писали:

LC>Первые впечатления сыроват
да, есть такое.
работаем.

LC>git/svn работает, hg — нет, чтоб заработал пришлось из дистра питоновского версии 2.7 сопировать в папку /include/python2.7 копировать содержимое папки include питоновского дистра.
это уже известный баг. Алексей поправит на днях.

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"

тоже известный баг, правда я не вникал в его причину.
все эти три темы посвящены этой и/или схожей проблеме. там, вроде даже решение есть.
http://sourceforge.net/mailarchive/message.php?msg_id=30931493
http://sourceforge.net/mailarchive/message.php?msg_id=30917383
http://sourceforge.net/mailarchive/message.php?msg_id=30930861