Версия boost-а -- 1.43.0, собираю под виндоузом, bjam-у задаю конфигурацию minimal. Создаются библиотеки libboost_date_time-mgw44-mt-1_43.a и libboost_date_time-mgw44-mt-d-1_43.a, но при попытке собрать пример, наподобие

линкер ругается на 'undefined reference to `boost::gregorian::greg_month::as_short_string() const''. Я в исходники boost-а полез, так там вообще не нашёл реализации этой самой as_short_string(). Объявления есть, точки использования есть, а реализации -- нет. Самое обидное, что на codepad.org этот пример всё же заводится. Значит, решение есть? Кто сталкивался, подскажите, что можно сделать для исправления ситуации?

Какой у вас компилятор?

Target: mingw32
Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)

EnergoHokum, опцию -lboost_date_time-mgw44-mt-1_43 не забыл указать?

При компиляции? Конечно, не забыл.  Другие функции из date_time-то работают, а вот преобразования вроде to_simple_string -- ругаются.

на лине компилится: http://liveworkspace.org/code/d702d9473b3e...ca5d07f55b08e11

Ну, там-то уже собранные библиотеки. А вот как они собранные? Может, при сборке или bjam-у, или ещё кому, нужно что-то важное сказать?

как обычно:

проверил на венде - тоже гуд. рассказывайте как буст собирали?

Хм... Я вот, только что, собрал в виндоузе boost 1.43.0 как у тебя написано, разве что с флагами --without-python и --without-mpi, чтобы время сборки подсократить -- всё равно происходит ошибка линковки в том примере, что я давал.

EnergoHokum, посмотри, возможно у тебя где-то валяются "левые" библиотеки буста, которые и цепляет компилятор.

я хз как и что ты собирал...
вот ссылка на mingw на базе gcc-4.6.0, с предустановленным boost-1.43.0, которым я пользуюсь: http://rghost.ru/1749023

Это сообщение отредактировал(а) boostcoder - 29.7.2010, 12:59

Подвиндовый MinGW, входящий в Qt 4.6.3.

Добавлено через 2 минуты и 4 секунды

Нестабильной веткой в работе пользуешься?

Добавлено через 5 минут и 28 секунд
Причём проблема эта не только у меня встречается.

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

Добавлено через 1 минуту и 32 секунды

тот пост 2007го года, и буст 1.32.0   

Ну, значит, этот геморрой ещё с 07-го года тянется. Надо будет дома под линуксом собрать, да сравнить с подвиндовой сборкой.

Вопрос закрыт. Виноватым, как обычно, оказался я, а не boost. 

Всего-то надо было прописать -lboost_date_time после -o <exefilename>, как всё отличным образом скомпилировалось, и заработало. 

Ы   естественно!


именно после?

Хм... Получается, даже, что не после -o <exefilename>, а после <sourcefilename>.

я хотел спросить.. имеет ли в вашем случае это значение?
вот я попробовал во всех комбинациях - одинаково.

А вот нехорошо фразы из контекста выдёргивать! Аяяй тебе за это! ;-)


Да вот, отчего-то в данном случае порядок потребовался. Я чего и затупил на столь долгое время -- раньше всякие прекомпилированные библиотеки (которые с MinGW идут, например) подключал в произвольном месте, и всё собиралось.

тебе об этом говорили: http://forum.vingrad.ru/index.php?showtopi...t&p=2189292

Я следующим постом ответил. 

EnergoHokum, ты случаем boost_datetime не в библиотеке используешь? просто в этом случае порядок следования подключаемых библиотек имеет значение:
например, у тебя есть библиотека libx.so, которая используется функции из библиотеки liby.so. если ты будешь собирать проект так: gcc source.c -ly -lx, то получишь ошибку. А если так: gcc source.c -lx -ly, то все соберется. Более того, если эти две библиотеки ссылаются друг на друга (их проектировщик не шибко умный), то нужно компилировать так: gcc source.c -lx -ly -lx

Не, в простом exe-шнике, что и странно.

Не странно - порядок указания библиотек играет роль не только между библиотеками, но и между исходными (объектными) файлами. Линкер (ld) берет из библиотеки только те модули, которые содержат неопределенные в данный момент символы. И берет он их в момент обработки опции -l. Потом к этой библиотеке он не возвращается, даже если появятся новые неопределенные символы, которые в ней были.
Но у линкера есть опция, которая заставляет просматривать библиотеки повторно.