LINUX.ORG.RU

libpython27.a, Google, MinGW64 и MS Visual C++


1

3

Пишу кросс-платформенное приложение (под Linux, Windows 32-bit, 64-bit). Под Линуксом всё замечательно - всё компилируется. Под виндой тоже всё было замечательно под WinXP 32-bit, Python-2.5.4 (для сборки питоновского модуля на Си используется libpython25.a). Попробовал собрать под Win7 Professional 64-bit, Python-2.7.3. Оказалось, что среди файлов Python 2.7 нет библиотеки libpython27.a Погуглил. И нашел такое фразу разработчиков Python: http://stackoverflow.com/questions/7492416/building-64bit-libpython27-a-using...

Do not use MinGW-w64. As you will notice, the MinGW
 import library for Python (e.g. libpython27.a) is omitted
 from the AMD64 version of Python. This is deliberate. Do not
 try to make one using dlltool. There is no official
 MinGW-w64 release yet, it is still in "beta" and considered
 unstable, although you can get a 64-bit build from e.g.
 TDM-GCC. There have also been issues with the mingw runtime
 conflicting with the MSVC runtime; this can happen from
 places you don't expect, such as inside runtime libraries
 for g++ or gfortran. To stay on the safe side, avoid
 MinGW-w64 for now.

Почему разработчики Python так уважительно относятся к Linux'у и Microsoft Visual Studio, и так пренебрежительно - к MinGW-GCC и исправлению багов в виндовых версиях Питона? http://www.python.org/download/releases/2.5.4/

Python 2.5.4
  We are pleased to announce the release of Python 2.5.4
 (final), a bugfix release of Python 2.5, on December 23rd,
 2008.
  Python 2.5.4 has been replaced by a newer bugfix release of
 Python. Please download Python 2.5.6 instead, unless you
 need to use the Windows and OS X binaries provided
 here.
Microsoft Visual C++ и CLang - наше фсьо?

★★★★★

Видимо эти маргиналы, как и милионы других, считаю что для венды надо обязательно компилить MSVC. Имхо крайне дерьмовый компилятор...

erfea ★★★★★ ()

я недавно пробовал разные вещи под MinGW собирать, в том числе и питон. Это жуткое глюкавое поделие, и собирать что-то под MinGW тот еще секс. Насчет питона нагуглилось такое решение - можно взять готовую libpython.a, скомпиленную MSVC и с помощью какой-то специальной тулзы переконвертировать её в формат, понятный MinGW и потом слинковаться с ней. Или линковаться с libpython.DLL динамически, через LoadLibrary() -> GetProcAddress()

Harald ★★★★★ ()
Ответ на: комментарий от Harald

я недавно пробовал разные вещи под MinGW собирать, в том числе и питон. Это жуткое глюкавое поделие, и собирать что-то под MinGW тот еще секс.

Я им компилил тону разного кода, включая такого монстра как Qt со всеми его 3rdPatry компонентами. Всё собирается, всё работает ЧЯДНТ?

erfea ★★★★★ ()
Ответ на: комментарий от erfea

кроме питона еще сборка еще целой кучи программ падает с ошибками на разных этапах, начиная от configure и до линковки, при этом под линуксом все зашибись

Harald ★★★★★ ()
Ответ на: комментарий от Gorthauer

Да ладно раза в два может медленее, в моем случае Qt собирается меньше 2 часов. Дык не каждый же день его собирать.

erfea ★★★★★ ()
Ответ на: комментарий от Harald

кроме питона еще сборка еще целой кучи программ падает с ошибками на разных этапах

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

начиная от configure

MSYS должен содержать ВСЁ необходимое для сборки. ВАШ КО. ЗЫ Студия вообще configure не съест.

до линковки

На фоне не рабочего configure, не удивляет что ему чего-то не хватает чтоб слинковаться.

при этом под линуксом все зашибись

Ну под линухом тебе готовое окружение для сборки дают, а в венде его нужно правильно приготовить.

erfea ★★★★★ ()
Ответ на: комментарий от erfea

окружение как раз есть, только кривое и глючное :)

Например, часто в стандартных заголовочных файлах от MinGW чего-то не хватает, или что-то бывает не определено

Harald ★★★★★ ()
Ответ на: комментарий от Harald

окружение как раз есть, только кривое и глючное :)

MinGW - компилятор. А вот окружение MSYS ты можешь как скачать один из over9000 вариантов, так и собрать сам (частично или полностью).

Например, часто в стандартных заголовочных файлах от MinGW чего-то не хватает, или что-то бывает не определено

Ага и я о том же, у тебя чего-то в msys не хватает, а ты всё на компилятор валишь, это от глубочайших блин познаний )))

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Ага и я о том же, у тебя чего-то в msys не хватает, а ты всё на компилятор валишь, это от глубочайших блин познаний )))

вообще-то заголовочные файлы как раз в состав дистрибутива компилятора входят

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Ты укуренный? Там только базовый набор. Загаловки stdlib, офтопиковые (windows.h тот же). Ты же жалуешься что сначала configure не отрабатывает.. А это уже говорит об отсутсвии чего-то в MSYS. Дальше у тебя заголовков не хватает, вернись назад, в MSYS какой-то либы нету!!! И на финише у тебя не линкуется, дык если ты тупа накидал куда-то заголовков, зависимость не будет разрешена, нужны ещё и либы, ваш КО!

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Там только базовый набор. Загаловки stdlib, офтопиковые (windows.h тот же).

вот я как раз про заголовки stdlib и говорю

Harald ★★★★★ ()
Ответ на: комментарий от erfea

Имхо крайне дерьмовый компилятор...

В чем дерьмовость заключается? По эффективности оптимизации и скорости компиляции он рвет гнутое говно как тузик грелку.

Reset ★★★★★ ()
Ответ на: комментарий от erfea

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

если не быдлокодить и не увлекаться гну-экстеншенами, то msvc собирает всё замечательно

Reset ★★★★★ ()

А тебе точно нужна «AMD64 version of Python» ? Приложение кушает более 2х гигов оперативы?

Reset ★★★★★ ()
Ответ на: комментарий от Reset

А тебе точно нужна «AMD64 version of Python» ?

Я предполагаю, что 64-битный Питон будет работать под AMD64 быстрее, чем 32-битный.
Поэтому поставил Python 2.7.3 (64-bit).
А libpython27.a там нет.

pacify ★★★★★ ()
Ответ на: комментарий от Reset

В чем дерьмовость заключается?

Ну я уже указывал, что эта тварь даже материться не умеет. Будешь спорить?

По эффективности оптимизации и скорости компиляции он рвет гнутое говно как тузик грелку.

Ну на скорость компиляции мне посрать, Qt менее 2-ух часов собирается на моем проце. А вот по оптимизации я б ещё поспорил бы. Мои приложения компиленные gcc грузили проц меньше.

если не быдлокодить и не увлекаться гну-экстеншенами, то msvc собирает всё замечательно

Мой код прекрасно компилится обоими компиляторами. Вот только ваять велосипеды я не люблю, потому «гнутый быдлокод» приходится компилить.

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Ну я уже указывал, что эта тварь даже материться не умеет. Будешь спорить?

Буду. У меня ни разу не возникало проблем с пониманием выхлопа cl.exe

Qt менее 2-ух часов собирается на моем проце.

cl.exe собрал бы его за 15 минут максимум

Мои приложения компиленные gcc грузили проц меньше.

Доооо, это конечно офигенный тест на производительность скомпиленного кода.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Буду. У меня ни разу не возникало проблем с пониманием выхлопа cl.exe

Я за тебя рад.

cl.exe собрал бы его за 15 минут максимум

Мне от этого ни холодно ни жарко.

Доооо, это конечно офигенный тест на производительность скомпиленного кода.

Приложение (для которого сие было актуально) производило ряд операций, ставило таймер и спало до сигнала (QTimer), работало в фоне. Нахожу для него сей показатель значительным. ЗЫ фразу в твоём посте «он рвет гнутое говно как тузик грелку» видимо стоит считать убедительным доводом в пользу анально огороженного MSVC, и достаточным для того чтобы тратить over9000 времени на запил патчей для гнутых либ, лиж бы блеть оно собралось cl.exe?! Ага уже бегу убивать на сей фарс время, аж трусы раздулись :D

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Нахожу для него сей показатель значительным.

А ты смотрел как оно это делало? И ты кстати как собирал? В Debug режиме код откомпилированный cl работает в 10 раз медленнее.

убедительным доводом в пользу анально огороженного MSVC

В чем заключается анальная огороженность ?

времени на запил патчей для гнутых либ

Гнутые либы без проблем собираются cl.exe Не собирается только гнутый быдлокод, который гвоздями прибит к gcc, но, слава богам, такого говна не много.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

А ты смотрел как оно это делало? И ты кстати как собирал?

Что именно? Дизаесемблировал?! Дебажил?! Читал исходники либ под копотом?!

В Debug режиме код откомпилированный cl работает в 10 раз медленнее.

Все тарары кроме я?! Жирно врасываешь...

В чем заключается анальная огороженность ?

В том, что его без гемора можно использовать только с такими же пропиетарными гадостами как он сам в абсолютном большинстве гвоздями прибитыме к венде, а лучше вообще winapi обходиться. Как только начинаешь тащить гнутые либы (и не только гнутые) в проект, начинается полный здец.

Гнутые либы без проблем собираются cl.exe Не собирается только гнутый быдлокод, который гвоздями прибит к gcc, но, слава богам, такого говна не много.

Практика показывает обратное... Быдлокод, не быдлокод, один хрен эти запары со сборкой либ решаются элементарной сменой компилятора. Что в разы быстрее и проще отдирания их от gcc. ЗЫ тот же qxt с MSVC в своё время у меня собрался молча, вот только в рантайме он сегфолтился. Мне блин что надо было дебажить его сидеть?!

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Что именно? Дизаесемблировал?! Дебажил?! Читал исходники либ под копотом?!

Время работы функций замерял?

Все тарары кроме я?! Жирно врасываешь...

Так собирал как? Оптимизацию включал или ниасилил?

В том, что его без гемора можно использовать только с такими же пропиетарными гадостами как он сам в абсолютном большинстве гвоздями прибитыме к венде, а лучше вообще winapi обходиться.

лютое, наглое 4.2

Практика показывает обратное...

Моя многолетняя практика кроссплатформенной разработки говорит мне, что ты либо нагло 3.1415здишь либо вопиюще некомпетентен, скорее верно второе, ибо остальные твои комментарии говорят об этом.

ЗЫ тот же qxt с MSVC в своё время у меня собрался молча, вот только в рантайме он сегфолтился. Мне блин что надо было дебажить его сидеть?!

Уверен, что рантайм отличался от того с которым был слинкован qt, но это не msvc виноват, а незвание матчасти и кривые руки.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Время работы функций замерял?

Если бы я измерил время выполнения функций это бы повлияло на поведение программы?! Оо

Так собирал как? Оптимизацию включал или ниасилил?

Ты про эту печаль?

лютое, наглое 4.2

Это мой опыт общения с MSVC.

Моя многолетняя практика кроссплатформенной разработки говорит мне, что ты либо нагло 3.1415здишь либо вопиюще некомпетентен, скорее верно второе, ибо остальные твои комментарии говорят об этом.

О простите ваше высочество, мне нельзя было рот раскрывать :D

Уверен, что рантайм отличался от того с которым был слинкован qt, но это не msvc виноват, а незвание матчасти и кривые руки.

Чего, чего?! Отсюда попдробнее...

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Если бы я измерил время выполнения функций это бы повлияло на поведение программы?! Оо

Это бы дало понимание происходящего. «Меньше грузит проц» это ламерство.

Ты про эту печаль?

да

Чего, чего?! Отсюда попдробнее...

читать

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Это бы дало понимание происходящего. «Меньше грузит проц» это ламерство.

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

да

Игрался, существенной разницы не заметил...

читать

эмм, ну почитал. Что же я мог сделать по твоему не так?!

erfea ★★★★★ ()
Ответ на: комментарий от erfea

эмм, ну почитал. Что же я мог сделать по твоему не так?!

Например, Qt слинкована с MSVCRT, а qxt - с MSVCRTD или наоборот. В результате выделяем память одним аллокатором в одной dll и освобождаем другим в другой dll и как результат — сегфолт.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

ЗЫ я в своё время гуглил тесты mingw vs msvc, увы не сохранил ссылочек (ака закладочек, к сожалению). Дык суть в том что из всего этого я для себя вынес одно: утверждения в стиле «рвет ... как тузик грелку» по отношению к рантайму в сравнениях этих компиляторов налое 4.2 по определению. Разный код может выдать разные результаты, но разница в них не существенная. Если нужно где-то выжимать производительность, то либо icc (вендорлок емнип) или таки старая добрая оптимизация, под тот компилятор (ассемблер, етц), которым будешь пользоваться. Потому выбор компилятора в случае «обычного» ПО скорее нужно производить исходя из его юзабельности. Если ты кодишь опираясь на гнутые компоненты, gcc очевидный выбор. Хотя бы по той причине, что он работает на многих платформах. Писать один проект, проще под один компилятор, а не сотни.

erfea ★★★★★ ()
Ответ на: комментарий от erfea

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

Мне он не очевиден

Хотя бы по той причине, что он работает на многих платформах.

И что? Если писать код правильно, то привязки к компилятору не будет. Разработка под MSVC быстрее в разы чем под mingw как минимум из-за скорости компиляции и наличии удобного отладчика. Да и вообще, я считаю, что собирать код под платформу лучше компилятором от производителя платформы.

Reset ★★★★★ ()
Ответ на: комментарий от erfea

Это у тебя надо спрашивать. Ты стек падения вообще смотрел? Может быть ты срал где-то в память и до сих пор продолжаешь срать, но версия либы поменялась, адреса поменялись и падать оно вдруг перестало.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Мне он не очевиден

Видимо у тебя основная платформа таки офтопик. И от юзанья гнутых либ ты весьма далёк.

И что? Если писать код правильно, то привязки к компилятору не будет.

Я ещё раз повторюсь, не фанат писанины велосипедов. Как это не странно для посетителя ЛОРа ВНЕЗАПНО предпочитаю опираться на гнутые либы. Дык вот они в основном разрабатываются для и под gcc.

Разработка под MSVC быстрее в разы чем под mingw как минимум из-за скорости компиляции и наличии удобного отладчика.

Скорость компиляции мало влияет на скорость разработки. А вот на счёт отладчика спорный вопрос, это таки дело привычки. Я им вообще редко пользуюсь.

Да и вообще, я считаю, что собирать код под платформу лучше компилятором от производителя платформы.

Ны дык КО подсказывает, что в таком случае стоит смотреть в сторону компиляторов от производителей процессоров. icc по крайней мере реально рвёт в клочья оба обсуждаемых нами сабжа.

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Видимо у тебя основная платформа таки офтопик. И от юзанья гнутых либ ты весьма далёк.

Я ничего оффтопик-специфичного никогда не использовал.

Я ещё раз повторюсь, не фанат писанины велосипедов.

Все велосипеды уже написаны в boost, qt и еще 100500 либах.

Дык вот они в основном разрабатываются для и под gcc.

Перечисли эти либы.

Скорость компиляции мало влияет на скорость разработки.

Ты не прав. Влияет существенно.

Я им вообще редко пользуюсь.

Потому что в mingw нет нормального отладчика.

icc по крайней мере реально рвёт в клочья оба обсуждаемых нами сабжа.

Не рвет, я сравнивал.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Я сейчас должен как Ъ детектив вспомнить блеать все детали события произошедшего где-то пол года назад?! Остынь, факт остался фактом, гнутая либа под gcc завелась с полпинка. С msvc возникли трудности, что именно пошло не так не помню уже, был сегфолт в рантайме. Это факт. Решением оказалось заюзать предыдущую версию либы, это тоже факт. Всё, почему именно она сегфолтилась я не помню, я не 1 программу в год собираю, у меня памяти на всё не хватит. Можешь пыжиться и строить из себя кого угодно и дальше. ЗЫ это мы мусолим только один из примеров, так хоть немного мне запомнившийся. Я очевидно ламер и у меня msvc чудесит, видимо это компилятор для труъ крутыхъ анальныхъ рабов мелкософта, готовых трахаться сколько угодно лишь бы в собрать именно им... сори не подхожу под это определение...

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Я сейчас должен как Ъ детектив вспомнить блеать все детали события произошедшего где-то пол года назад?

Вспомнить не можешь, то значит стек не смотрел. В 99.99% случаев проблема ясна при беглом просмотре стека.

Остынь, факт остался фактом, гнутая либа под gcc завелась с полпинка. С msvc возникли трудности, что именно пошло не так не помню уже, был сегфолт в рантайме. Это факт.

Да, этот факт показывает кривость твоих рук.

Я очевидно ламер и у меня msvc чудесит, видимо это компилятор для труъ крутыхъ анальныхъ рабов мелкософта, готовых трахаться сколько угодно лишь бы в собрать именно им... сори не подхожу под это определение...

Ога, ты ламер с анальным вендор-локом к gcc.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Я ничего оффтопик-специфичного никогда не использовал.

молодец, пирожок там на полке.

Все велосипеды уже написаны в boost, qt и еще 100500 либах.

именно что их ещё 100500...

Перечисли эти либы.

Я тебе список должен составить был?! Оо На вскидку, сборка zxutils под msvc меня хорошо развлекла. Такого барахла много, в MSYS собирается за 2 минуты. configure;make;make install.

erfea ★★★★★ ()
Ответ на: комментарий от Reset

Вспомнить не можешь, то значит стек не смотрел. В 99.99% случаев проблема ясна при беглом просмотре стека.

Ах ну да, просмотр стека мне должен был на всю жизнь запомниться :D Да ты упоротый :D

Да, этот факт показывает кривость твоих рук.

В каком месте?!

Ога, ты ламер с анальным вендор-локом к gcc.

Ещё раз повторюсь, мой код всегда легко собирается любым компилятором, при условии уже собраных зависимотсей.

Потому что в mingw нет нормального отладчика.

gdb нормальный отладчик. У меня нету привычки отлаживать рабочий код. И писать нерабочий тоже нету. Я ж ламер, мне проще сразу написать рабочее, чем дебажить сидеть часами. ЗЫ может потому у тебя и скорость компиляции сильно на скорость разработки не сильно влияет что ты не ламер и ьеюе после каждых 5 строчек кода нужно пересобирать и дебажить весь проект, ты же не ламер :D

Не рвет, я сравнивал.

И этот человек мне будет про компиляторы рассказывать...

erfea ★★★★★ ()
Ответ на: комментарий от Reset

Да ладно?! Это только что не виндовс совместимо и элементарно лечится MSYS. ЗЫ лично сам предпочитаю cmake, вот это не вендор лок.

erfea ★★★★★ ()
Ответ на: комментарий от erfea

Ах ну да, просмотр стека мне должен был на всю жизнь запомниться :D Да ты упоротый :D

Не просмотр стека, а суть проблемы, если ты её не помнишь, то это говорит о том, что ты вообще ничего не делал.

В каком месте?!

В том, что ты даже не знаешь суть проблемы, а уже обвиняешь компилятор от ms.

gdb нормальный отладчик.

Нормальный, но до отладчика из msvc ему как раком до китая.

Я ж ламер, мне проще сразу написать рабочее, чем дебажить сидеть часами.

Часами это про gdb.

И этот человек мне будет про компиляторы рассказывать...

Мнение остальных мне не интересно, на моих задачах он был на уровне с cl.exe где-то чуть хуже где-то чуть лучше, «рвет» я не увидел и воспроизвести не смог.

Reset ★★★★★ ()
Ответ на: комментарий от erfea

В совсем запущенных случаях, если либа Си-only, то можно собрать mingw и линковать её в студии. Я знаю только одну такую упоротую либу — ffmpeg.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Мнение остальных мне не интересно

Так вот как можно 5 звёзд на lor-е получить... ;)

anonymous ()
Ответ на: комментарий от Reset

В том, что ты даже не знаешь суть проблемы, а уже обвиняешь компилятор от ms.

Я пока пытался этот проект собрать msvc, возникло вагон и маленькая тележка. Несколько часов ковыряний привели к успеху, ВНЕЗАПНО, я же ламер :D Но вот детали на фони этого ***ца как-то уж не отложились. После проект был собран в mingw без каких либо затыков вообще. ЗЫ (упреждение сваливания на всего на то что нужно писать «правильно») все проблемы были так или иначе связаны с гнутыми либами, от меня ну никак не зависит их собираемость в msvc.

Нормальный, но до отладчика из msvc ему как раком до китая.

Ну да, дебагер не ламерам нужен после каждых пяти строк кода, я иногда забываю что сам виноват что такой ламер и очень редко берусь дебажить...

Мнение остальных мне не интересно

ну да тебе нужно всем воткнуть своё мнение и заодно всех ламерами обозвать, ты же тру каждые 5 строчек пересобираешь проект и дебажишь и только такие крутые перцы знают что есть круто :D

он был на уровне с cl.exe где-то чуть хуже где-то чуть лучше, «рвет» я не увидел и воспроизвести не смог

зато gcc был порван виликим и ужасным cl.exe ну-ну... ага охотно верю.

В совсем запущенных случаях, если либа Си-only, то можно собрать mingw и линковать её в студии. Я знаю только одну такую упоротую либу — ffmpeg.

Она кстати крайне популярна в вендовых тру крутых и координально более крытух чем другие на том же ffmpeg приложениях ;)

ЗЫ ты мне наскучил...

erfea ★★★★★ ()
Ответ на: комментарий от Reset

В тех тестах, что имелись у меня (параметры msvc и mingw задавал не я, а организаторы NEERC) mingw на вводе-выводе рвал msvc в 2,5 раза. Но это офк зависит от библиотеки виндовой, да и вообще на объективность не претендую. Скажу одно - если чуваки разрабатывают что-то сложное в msvc-онли, то они и профайлер будут гонять только в нём, и фиксить только его проблемы производительности - и, конечно, у них этот компилятор будет выдавать более быстрый код.

quiet_readonly ★★★★ ()
Ответ на: комментарий от quiet_readonly

Например в книге Мак-Коннела «Совершенный код» половина советов по ручной оптимизации делается gccшкой автоматически по дефолту на -o2. А вот в msvc возможно что и нет.

quiet_readonly ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.