Добрый день!
Пользуюсь MSVC2005. Студия сама определяет название lib-файла и почему-то всегда ей требуются библиотеки с подобными названиями (libboost_thread-vc80-mt-gd-1_35.lib). В предыдущих версиях буста библиотеки так и назывались, но в новой версии (1.35) они почему-то стали называться по-другому (boost_thread-vc80-mt-1_35.lib). Причем, что самое интересное, если библиотеку переименовать в старое имя, все замечательно собирается.
В чем проблема? Может буст как-то неправильно установлен? Или может как-то студию надо настроить? Подскажите пожалуйста.
Здравствуйте, silart, Вы писали:
S>Добрый день! S>Пользуюсь MSVC2005. Студия сама определяет название lib-файла и почему-то всегда ей требуются библиотеки с подобными названиями (libboost_thread-vc80-mt-gd-1_35.lib). В предыдущих версиях буста библиотеки так и назывались, но в новой версии (1.35) они почему-то стали называться по-другому (boost_thread-vc80-mt-1_35.lib). Причем, что самое интересное, если библиотеку переименовать в старое имя, все замечательно собирается. S>В чем проблема? Может буст как-то неправильно установлен? Или может как-то студию надо настроить? Подскажите пожалуйста.
Вот здесь про именование библиотек.
On Windows, only ordinary static libraries use the lib prefix; import libraries and DLLs do not
Вот здесь про автолинковку, что проиходит в твоем случае . Как ей управлять я не знаю — раньше вроде для некоторых библиотек в бусте дефайн был — линковать статически, попробуй явно подключить библиотеку через
Здравствуйте, silart, Вы писали:
S>В чем проблема? Может буст как-то неправильно установлен? Или может как-то студию надо настроить? Подскажите пожалуйста.
Собери boost с параметром link=static (например: bjam --toolset=msvc-8.0 release --without-math --without-python debug threading=multi link=static stage
) (см. здесь
Удалось решить эту проблему. Просто у меня были скомпилированы только shared-версии библиотек. Перекомпиляция помогла, библиотеки стали занимать почти 2 Гб.
Получается что библиотеки начинающиеся с libboost- это static, а начинающиеся с boost- это shared.
Компилировал буст я следующим образом:
Здравствуйте, silart, Вы писали:
S>Удалось решить эту проблему. Просто у меня были скомпилированы только shared-версии библиотек. Перекомпиляция помогла, библиотеки стали занимать почти 2 Гб.
Выкинь директорию с объектными файлами и замени копии библиотек на хардлинки, этот объем уменьшится в 4 раза :-)
Здравствуйте, silart, Вы писали:
S>Добрый день! S>Пользуюсь MSVC2005. Студия сама определяет название lib-файла и почему-то всегда ей требуются библиотеки с подобными названиями (libboost_thread-vc80-mt-gd-1_35.lib). В предыдущих версиях буста библиотеки так и назывались, но в новой версии (1.35) они почему-то стали называться по-другому (boost_thread-vc80-mt-1_35.lib). Причем, что самое интересное, если библиотеку переименовать в старое имя, все замечательно собирается. S>В чем проблема? Может буст как-то неправильно установлен? Или может как-то студию надо настроить? Подскажите пожалуйста.
я б за #pragma comment(lib,"bla bla bla") отрывал бы руки
простите если кого задел...
но терпеть не могу когда за меня неявно что то линкуют...
хочу видеть что линкуется... и почему...
особенно достает такой случай как у вас... там не версия буста сменилась
просто вы собрали буст с другой конфигурацией — соответственно либы — по другому называются — а какой то умник в сорцах прохардкодил библиотеку определенной конфигурации — он почему то решил, что вы соберете именно нужную ему конфигурацию буста...
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Dj.ValDen, Вы писали:
DV>Здравствуйте, silart, Вы писали:
S>>Добрый день! S>>Пользуюсь MSVC2005. Студия сама определяет название lib-файла и почему-то всегда ей требуются библиотеки с подобными названиями (libboost_thread-vc80-mt-gd-1_35.lib). В предыдущих версиях буста библиотеки так и назывались, но в новой версии (1.35) они почему-то стали называться по-другому (boost_thread-vc80-mt-1_35.lib). Причем, что самое интересное, если библиотеку переименовать в старое имя, все замечательно собирается. S>>В чем проблема? Может буст как-то неправильно установлен? Или может как-то студию надо настроить? Подскажите пожалуйста.
DV>я б за #pragma comment(lib,"bla bla bla") отрывал бы руки DV>простите если кого задел... DV>но терпеть не могу когда за меня неявно что то линкуют... DV>хочу видеть что линкуется... и почему... DV>особенно достает такой случай как у вас... там не версия буста сменилась DV>просто вы собрали буст с другой конфигурацией — соответственно либы — по другому называются — а какой то умник в сорцах прохардкодил библиотеку определенной конфигурации — он почему то решил, что вы соберете именно нужную ему конфигурацию буста...
Ага, а лучше всего вообще использовать Boost.Build для сборки сообственных библиотек и проектов. Тогда вообще никаких проблем с линковкой нет. Использую для сборки своих домашних проектов. Есть библиотека, а от неё зависит другая, а от другой третья, а от третье несколько исполняемых файлов. и всё это кучей зависит от filesystem, system, thread, date_time, serialization и ещё чего-то там. Boost.Build всем рулит собирает библиотеки и программы с нужными мне опциями компилятора, отслеживает зависимости библиотек и файлов. Всё это кроссплатформенно. Лёгким движением руки я собираю 32 и 64 битные версий, дебажные или релизные, формирую папку в которую копируются нужные мне файлы. Трудозатрат по довалению новых библиотек или программ зависящих от других моих и бустовых библиотек минимум. Помимио этого там есть интегрированные юнит тесты. Большее всего ушло времени на вникание в эту систему и осознание некоторых её тонкостей
На работе система кроссплатформенной сборки написана на GNUMake. В ней чёрт ногу сломит (хотя в Boost.Build наверно тоже ) при этом частенько приходится исправлять вылезающие баги. Зависимости между исходниками и заголовочными файлами отслеживаются криво, особенно актуально это для винды. для юникс тоже надо не забывать звать make depend.
Вообщем я пребывал и до сих пор пребываю в эйфории от Boost.Build. Про неё почему-то крайне редко упоминают, в основном на слуху С++ библиотеки из boost. Да я начал ковырять её случайно от нечего делать правда через пару часов оценил мощь
Здравствуйте, Roman Odaisky, Вы писали:
RO>Выкинь директорию с объектными файлами и замени копии библиотек на хардлинки, этот объем уменьшится в 4 раза
Роман, расскажите поподробнее как это сделать, плиз... Было бы замечательно, если бы вы привели опции командной строки, с которыми вы компилируете буст.
Здравствуйте, TarasKo, Вы писали: TK>Ага, а лучше всего вообще использовать Boost.Build для сборки сообственных библиотек и проектов. Тогда вообще никаких проблем с линковкой нет. Использую для сборки своих домашних проектов. Есть библиотека, а от неё зависит другая, а от другой третья, а от третье несколько исполняемых файлов. и всё это кучей зависит от filesystem, system, thread, date_time, serialization и ещё чего-то там. Boost.Build всем рулит собирает библиотеки и программы с нужными мне опциями компилятора, отслеживает зависимости библиотек и файлов. Всё это кроссплатформенно. Лёгким движением руки я собираю 32 и 64 битные версий, дебажные или релизные, формирую папку в которую копируются нужные мне файлы. Трудозатрат по довалению новых библиотек или программ зависящих от других моих и бустовых библиотек минимум. Помимио этого там есть интегрированные юнит тесты. Большее всего ушло времени на вникание в эту систему и осознание некоторых её тонкостей
TK>На работе система кроссплатформенной сборки написана на GNUMake. В ней чёрт ногу сломит (хотя в Boost.Build наверно тоже ) при этом частенько приходится исправлять вылезающие баги. Зависимости между исходниками и заголовочными файлами отслеживаются криво, особенно актуально это для винды. для юникс тоже надо не забывать звать make depend.
TK>Вообщем я пребывал и до сих пор пребываю в эйфории от Boost.Build. Про неё почему-то крайне редко упоминают, в основном на слуху С++ библиотеки из boost. Да я начал ковырять её случайно от нечего делать правда через пару часов оценил мощь
Можно несколько вопросов, уважаемый ТарасКо?
Случайно этот Boost.Build не поможет скрестить boost и STLPort? Просто я пробовал (правда без использования Boost.Build) в предыдущей версии буста 1.34 так сделать, но у меня ничего не вышло...
А если я помимо буста использую Qt? Можно пользоваться Boost.Build?
И каким образом все происходит? Наверное нужно все делать в командной строке? Можно ли использовать Boost.Build с MSVC?
TarasKo пишет:
> На работе система кроссплатформенной сборки написана на GNUMake. В ней > чёрт ногу сломит (хотя в Boost.Build наверно тоже ) при этом частенько > приходится исправлять вылезающие баги. Зависимости между исходниками и > заголовочными файлами отслеживаются криво, особенно актуально это для > винды. для юникс тоже надо не забывать звать make depend. > > Вообщем я пребывал и до сих пор пребываю в эйфории от Boost.Build. Про > неё почему-то крайне редко упоминают, в основном на слуху С++ библиотеки > из boost. Да я начал ковырять её случайно от нечего делать правда через > пару часов оценил мощь
Попробуйте например собрать boost::serialization (dll-версии) со
включенным макросом BOOST_SPIRIT_THREADSAFE, и эйфория скорее всего
пройдет
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, silart, Вы писали:
S>Случайно этот Boost.Build не поможет скрестить boost и STLPort? Просто я пробовал (правда без использования Boost.Build) в предыдущей версии буста 1.34 так сделать, но у меня ничего не вышло...
Не доводилось делать этого, набор в гугле строки "Boost.Build STLPort" показал что с этим есть проблемы, однако наличие макроса _STLP_USE_BOOST_SUPPORT наталкивает на мысль что возможность должна быть. Вот кстати одна ссылка может это то что надо?
S>А если я помимо буста использую Qt? Можно пользоваться Boost.Build?
Использовать Boost.Build для сборки Qt или для линковки с уже собранными библиотеками? Насчёт первого, ничего не могу сказать Qt пользовался давно и мало, а со вторым не представляю какие могут быть проблемы. Чем это отличается от линковки обычной внешней библиотеки?
S>И каким образом все происходит? Наверное нужно все делать в командной строке? Можно ли использовать Boost.Build с MSVC?
Ага, я делаю в командной строке. MSVC использую как редактор и отладчик. Но вроде как-то можно сказать чтоб MSVC использовал bjam при сборке. Ведь можно же со студией использовать nmake, думаю вместо nmake можно использовать и bjam
Здравствуйте, Sergey, Вы писали:
S>TarasKo пишет:
>> На работе система кроссплатформенной сборки написана на GNUMake. В ней >> чёрт ногу сломит (хотя в Boost.Build наверно тоже ) при этом частенько >> приходится исправлять вылезающие баги. Зависимости между исходниками и >> заголовочными файлами отслеживаются криво, особенно актуально это для >> винды. для юникс тоже надо не забывать звать make depend. >> >> Вообщем я пребывал и до сих пор пребываю в эйфории от Boost.Build. Про >> неё почему-то крайне редко упоминают, в основном на слуху С++ библиотеки >> из boost. Да я начал ковырять её случайно от нечего делать правда через >> пару часов оценил мощь
S>Попробуйте например собрать boost::serialization (dll-версии) со S>включенным макросом BOOST_SPIRIT_THREADSAFE, и эйфория скорее всего S>пройдет
Ок, попробую, я не говорил что система безгрешна, но какие у неё есть альтернативы если мне нужно быстро собрать свои проекты использующие boost для винды и юникса.
Ведь придётся писать свою систему сборки тогда
Здравствуйте, Sergey, Вы писали:
S>TarasKo пишет:
>> На работе система кроссплатформенной сборки написана на GNUMake. В ней >> чёрт ногу сломит (хотя в Boost.Build наверно тоже ) при этом частенько >> приходится исправлять вылезающие баги. Зависимости между исходниками и >> заголовочными файлами отслеживаются криво, особенно актуально это для >> винды. для юникс тоже надо не забывать звать make depend. >> >> Вообщем я пребывал и до сих пор пребываю в эйфории от Boost.Build. Про >> неё почему-то крайне редко упоминают, в основном на слуху С++ библиотеки >> из boost. Да я начал ковырять её случайно от нечего делать правда через >> пару часов оценил мощь
S>Попробуйте например собрать boost::serialization (dll-версии) со S>включенным макросом BOOST_SPIRIT_THREADSAFE, и эйфория скорее всего S>пройдет
Кстати может быть вы имеете ввиду хитрую property threadapi у библиотеки thread.
И что её надо явно указывать при сборке зависимых проектов? При этом если не указать то вылазят совершенно непонятные ошибки
Или там что — то другое? Вечером дома обязательно попробую
TarasKo пишет:
>> > На работе система кроссплатформенной сборки написана на GNUMake. В ней >> > чёрт ногу сломит (хотя в Boost.Build наверно тоже ) при этом частенько >> > приходится исправлять вылезающие баги. Зависимости между исходниками и >> > заголовочными файлами отслеживаются криво, особенно актуально это для >> > винды. для юникс тоже надо не забывать звать make depend. >> > >> > Вообщем я пребывал и до сих пор пребываю в эйфории от Boost.Build. Про >> > неё почему-то крайне редко упоминают, в основном на слуху С++ библиотеки >> > из boost. Да я начал ковырять её случайно от нечего делать правда через >> > пару часов оценил мощь > > S>Попробуйте например собрать boost::serialization (dll-версии) со > S>включенным макросом BOOST_SPIRIT_THREADSAFE, и эйфория скорее всего > S>пройдет > > Кстати может быть вы имеете ввиду хитрую property threadapi у библиотеки > thread. > И что её надо явно указывать при сборке зависимых проектов? При этом > если не указать то вылазят совершенно непонятные ошибки > Или там что — то другое? Вечером дома обязательно попробую
Я имею в виду, что (под виндой, по крайней мере) оно просто не слинкуется.
Как это починить по-человечески, я не понял — собираю в два приема,
благо что не часто это делать приходится.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, silart, Вы писали:
RO>>Выкинь директорию с объектными файлами и замени копии библиотек на хардлинки, этот объем уменьшится в 4 раза :-)
S>Роман, расскажите поподробнее как это сделать, плиз... Было бы замечательно, если бы вы привели опции командной строки, с которыми вы компилируете буст.
Я его не компилирую, я его из пакетов ставлю.
А если речь об MS Windows и сборке вручную, то там при сборке образуется директория то ли bin, то ли build, в которой под гиг объектных файлов. А когда подходит очередь собственно библиотек, то инсталлятор должен создать libboost_something-много_букв.lib и libboost_something-много_букв_1_35.lib, которые суть одно и то же. В Юниксе для этого используются симлинки, а в MS Windows, поскольку их может не быть, инсталлятор просто копирует файлы. Красивым решением было бы отыскать в недрах jamфайлов место, где действие hardlink выражается через copy, и поставить туда настоящий hardlink — «fsutil hardlink create». Я пробовал, но не нашел :-). Это только для NTFS, естественно.
Вот. Еще не надоело? Если надоело, то в Debian стоит только сказать apt-get install libboost-dev, и всё готово. Кстати, полный дистрибутив Boost в Debian занимает 18 МБ — в бинарниках. (Без учета дебажных библиотек, их 44 МБ.)
Файлы получившихся библиотек имеют правильные имена (присутствует суффикс p в названии файла), например libboost_signals-vc-mt-sgdp-1_35.lib.
После этого я решил собрать простой пример с потоками, который прекрасно компилировался, когда не было STLport. Но при этом вылезла куча ошибок:
D:\Development\boost_1_35_0\boost/mpl/integral_c_tag.hpp(22) : error C2061: syntax error : identifier 'value'
D:\Development\boost_1_35_0\boost/mpl/integral_c_tag.hpp(22) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
D:\Development\boost_1_35_0\boost/mpl/integral_c_tag.hpp(22) : warning C4183: 'BOOST_STATIC_CONSTANT': missing return type; assumed to be a member function returning 'int'
D:\Development\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(45) : error C2061: syntax error : identifier 'value'
D:\Development\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(81) : see reference to class template instantiation 'boost::mpl::int_<N>' being compiled
D:\Development\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(45) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
D:\Development\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(45) : warning C4183: 'BOOST_STATIC_CONSTANT': missing return type; assumed to be a member function returning 'int'
D:\Development\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(72) : error C2065: 'value' : undeclared identifier
D:\Development\boost_1_35_0\boost/mpl/aux_/integral_wrapper.hpp(85) : error C2039: 'value' : is not a member of 'boost::mpl::int_<N>'
.............
Пробовал компилировать еще простой пример с сигналами. Тут все компилится, но при линковке возникают такие ошибки:
Здравствуйте, silart, Вы писали:
S>В чем же проблема? Подскажите кто-нибудь, пожалуйста. Вроде же все сделал правильно, может дефайн какой поставить надо или еще что?
Не использую stlport. Когда-то пробовал и собирал как советовал Экселенцздесь
, вроде как hello world`ы работали, но это было давно. Ты точно не забыл в VS добавить пути к хидерам и либам stlport`а?
Ну конечно же не забыл... причем их поставил в самое начало списка, как было написано в доках к STLPort-у. Что странно, предыдущий буст (1.34) не собирался так, как я описал, а вот 1,35-й собрался. Если при компиляции примеров убрать всякое упоминание о STLPort-е, все хорошо компилится, только либ требует другой, без суффикса -p, ставишь на место пути к STLPort-у — та же хрень. Уж не знаю прям что и делать... Все-таки STLPort полезная штука, и как-то к бусту ее надо прикрутить.