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

Steam захотел GLIBC 2.15 - ну не стали Valve компилировать его в CentOS 6. Обновляюсь - ошибка. Оказалось что binutils старой версии были с багом, который препятствует компиляции glibc 2.16, обновил binutils, и glibc успешно обновился до версии 2.16. Отвалился boost. Emerge сказал что с glibc 2.16 работает только boost 1.52, так что выбирай, или старый glibc, или новый boost.

Вот именно это Линус Торвальдс и называет плохим кодом. Он как-то ссорился с разработчиками nouveau за то что они намертво прибивали libdrm для nouveau к текущей версии ядра Linux и иксов, ни новее, ни старее. При этом разработчики nouveau считали, что это нормально.

Хорошо что у меня от Boost ровно 5 приложений зависят.

Emerge сказал что с glibc 2.16 работает только boost 1.52

поговори еще раз с emerge - он не прав

Я могу путать версию, может быть не 1.52, а 1.50. Суть в том что boost, оказывается, критичен к версии glibc.

Boost.Multiprecision

Надеюсь, умеет GMP или MPIR в качестве бэкенда.

а что за проблемы?

Суть в том что boost, оказывается, критичен к версии glibc.

это генту-проблемы, а не буста

Если под MPIR ты имел в виду MPFR, то умеет оба варианта.

boost не привязывается к glibc, это проблема твоего дистрибутива

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

на самом деле там есть конфликт связанный с поддержкой C11? в новом glibc и константой TIME_UTC в бусте, но в нормальных дистрибутивах просто добавили патч для буста

Хо-хо-хо, отличная новость! Как я понимаю Lockfree - это реализация неблокирующих структур данных, которые тем не менее потокобезопасны?

Как я понимаю Lockfree - это реализация неблокирующих структур данных, которые тем не менее потокобезопасны?

Если верить документации по ссылке, то именно так.

Интересно, а есть какая-нибудь библиотека для работы с числами в quote notation (которую придумал Eric Hehner)?

В смысле чтобы безболезненно конвертировать в p-adic представление и обратно и работать не боясь ошибок округления?

По идее в бусте такому было бы самое место.

При первом появлении boost-1.51 с ним не собиралось несколько пакетов вроде exiv2 и еще чего-то.

Надеюсь, умеет GMP или MPIR в качестве бэкенда.

Буст? Щас! Весь буст ориентирован на включение в стандарт С++, потому там только велосипеды:) А то не хватало еще, чтобы libstdc++ от чего-то зависело.

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

Эт у тебя butt не разработанный. Как разработчик, я заюзаю сабж при первом намеке на облегчение моей работы. И мне будет глубоко насрать на горстку неадекватов, которым очень важен вопрос соответствия зависимостей курсу КПСС.

boost-way это линковать статически или таскать свой буст со своим приложением.

Проблем нет, если tools не нужны.

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

С какой версией буста?

В отличие от тебя, люди будут.

Boost.Numeric.Odeint

В чём смысл сей библиотеки? Для быстрых поделок есть maple/mathematica/... , для сложных задач всё равно велосипеды писать.

1.53.0

http://perestoroniny.ru/site/software

http://portage.perestoroniny.ru/dev-libs/boost/ http://portage.perestoroniny.ru/dev-util/boost-build/

получены простым переименованием имеющихся в portage 1.53.0_beta1

При сборке USE="-tools"

и затем как обычно

lafilefixer --justfixit

revdep-rebuild -i

boost, оказывается, критичен к версии glibc.

Ну не может быть такой херни. Boost же кроссплатформенный.

Это косяки гентоводов.

>>> Steam захотел GLIBC 2.15 - ну не стали Valve компилировать его в CentOS 6. Обновляюсь - ошибка. Оказалось что binutils старой версии были с багом, который препятствует компиляции glibc 2.16, обновил binutils, и glibc успешно обновился до версии 2.16. Отвалился boost. Emerge сказал что с glibc 2.16 работает только boost 1.52, так что выбирай, или старый glibc, или новый boost.

>> boost не привязывается к glibc, это проблема твоего дистрибутива

> на самом деле там есть конфликт связанный с поддержкой C11? в новом glibc и константой TIME_UTC в бусте, но в нормальных дистрибутивах просто добавили патч для буста

Не всё так просто. Я стал обновлять систему и выяснилось, что те несколько программ, зависящие от boost, не могут пересобраться! То есть Boost 1.42 после обновления glibc с 2.12 до 2.16 работать перестал.

# emerge -av =boost-1.49.0-r2

 * IMPORTANT: 16 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies ... done!
[ebuild     UD ] sys-libs/glibc-2.15-r3:2.2 [2.16.0:2.2] USE="(multilib) -debug -gd (-hardened) -profile (-selinux) -vanilla (-systemtap%)" 10,568 kB
[ebuild     UD ] dev-util/boost-build-1.49.0 [1.52.0-r1] USE="python -examples (-test%)" 47,364 kB
[ebuild     UD ] dev-libs/boost-1.49.0-r2 [1.52.0-r5] USE="mpi python -debug -doc -icu -static-libs -tools (-nls%*) (-threads%*)" PYTHON_TARGETS="(-python2_5%) (-python2_6%) (-python2_7%*) (-python3_1%) (-python3_2%*) (-python3_3%)" 0 kB

Total: 3 packages (3 downgrades), Size of downloads: 57,931 kB

Would you like to merge these packages? [Yes/No]

ну кому-то нужны быстрые поделки на си-плюс-плюсе

те несколько программ, зависящие от boost, не могут пересобраться!

весьма вероятно, что как раз из-за добавления TIME_UTC, в новом бусте его переименовали в TIME_UTC_, в убунте обновили старый буст (вероятно тоже переименовали в TIME_UTC_) и соот-но пропатчили софт на предмет этого исправления, у тебя в генте этим никто не озаботился

В чём смысл сей библиотеки? Для быстрых поделок есть maple/mathematica/... , для сложных задач всё равно велосипеды писать.

We aim to establish «existing practice» and provide reference implementations so that Boost libraries are suitable for eventual standardization.

We aim to establish «existing practice» and provide reference implementations so that Boost libraries are suitable for eventual standardization.

Один я недоумеваю, нафига в стандарте языка нужны решалки диффуров?

Пригодицца!

Посмотрел на Boost.Coroutine - это какая-то наркомания на марше.

Под MPIR я имел в виду MPIR. Но оно все равно пока еще вроде совместимо с GMP по API.

Ах, да, по стопам Кармака. Недавно увидел на домашних штанах надпись Boost — чуть удар не хватил.

Посмотрел на Boost.Coroutine - это какая-то наркомания на марше.

Весь буст такой в кишках.

какая-то наркомания на марше.

Весь буст такой в кишках.

Я посмотрел пример использования :)

Буст? Щас! Весь буст ориентирован на включение в стандарт С++, потому там только велосипеды:) А то не хватало еще, чтобы libstdc++ от чего-то зависело.

Это не совсем так. У буста есть опциональные зависимости. Например, boost.locale может собираться как с ICU, так и без неё.

Я посмотрел пример использования :)

За примеры им порой хочется пожать руку... кусачками...

ну кому-то нужны быстрые поделки на си-плюс-плюсех

Ну только если поделки. Все вменяемые процедуры для численного интегрирования ОДЕ уже написаны на Фортране.

было что-то с C++11 подобное, правда для для uid_t, для http://portage.perestoroniny.ru/media-gfx/djv/, пришлось применить в ebuild-е:

sed -e 's/uid_t /__uid_t /' \
		-e 's/uid_t)/__uid_t)/' \

Конфликты и проблемы в основном из-за C++11, из-за ненужности нововведений и самого С++. Но поскольку софт уже написан, то используем что есть и радуемся.

Посмотрел на Boost.Coroutine - это какая-то наркомания на марше.

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

А мне понравилось. Похоже можно будет цепочку asio-колбеков превратить в один плоский код, который хорошо просматривается и осознается. Попробую заюзать в своем приложении.

Boost.Coroutine

Наконец-то передрали из C#

при первом намеке на облегчение моей работы

Нну... Это полумеры. При первом намеке на облегчение работы я, конечно же, выберу более другой ЯП.

Эти проблемы должны разрабы дистрибутива решать?

Эти проблемы должны разрабы дистрибутива решать?

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

надмозги

решений обыкновенных дифференциальных уравнений, удовлетворяющих начальным условиям.

Это называется задача Коши.

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

Хммм, я ждал от тебя камента по поводу того, что boost давно пора переписать так, чтобы он интегрировался с systemd. Какое разочарование...

Иногда использование буста оказывается более удобным для пользователей решением, чем c++11.