[root@localhost libtorrent-rasterbar-1.2.0]# make
Making all in include/libtorrent
make[1]: Entering directory `/root/libtorrent-rasterbar-1.2.0/include/libtorrent'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/root/libtorrent-rasterbar-1.2.0/include/libtorrent'
Making all in src
make[1]: Entering directory `/root/libtorrent-rasterbar-1.2.0/src'
CXX libtorrent_rasterbar_la-web_connection_base.lo
In file included from ../include/libtorrent/entry.hpp:76:0,
from ../include/libtorrent/settings_pack.hpp:36,
from ../include/libtorrent/aux_/session_settings.hpp:37,
from ../include/libtorrent/peer_connection.hpp:53,
from ../include/libtorrent/web_connection_base.hpp:42,
from web_connection_base.cpp:38:
../include/libtorrent/string_view.hpp:60:24: error: missing space between ‘""’ and suffix identifier
constexpr string_view operator""_sv(char const* str, std::size_t len)
^
In file included from ../include/libtorrent/settings_pack.hpp:36:0,
from ../include/libtorrent/aux_/session_settings.hpp:37,
from ../include/libtorrent/peer_connection.hpp:53,
from ../include/libtorrent/web_connection_base.hpp:42,
from web_connection_base.cpp:38:
../include/libtorrent/entry.hpp: In member function ‘typename libtorrent::aux::map_string<T>::base::iterator libtorrent::aux::map_string<T>::find(const string_view&)’:
../include/libtorrent/entry.hpp:110:33: error: ‘const string_view’ has no member named ‘to_string’
return this->base::find(key.to_string());
^
../include/libtorrent/entry.hpp: In member function ‘typename libtorrent::aux::map_string<T>::base::const_iterator libtorrent::aux::map_string<T>::find(const string_view&) const’:
../include/libtorrent/entry.hpp:115:33: error: ‘const string_view’ has no member named ‘to_string’
return this->base::find(key.to_string());
^
In file included from ../include/libtorrent/aux_/session_settings.hpp:37:0,
from ../include/libtorrent/peer_connection.hpp:53,
from ../include/libtorrent/web_connection_base.hpp:42,
from web_connection_base.cpp:38:
../include/libtorrent/settings_pack.hpp: At global scope:
../include/libtorrent/settings_pack.hpp:93:18: error: function ‘libtorrent::settings_pack& libtorrent::settings_pack::operator=(libtorrent::settings_pack&&)’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘libtorrent::settings_pack& libtorrent::settings_pack::operator=(libtorrent::settings_pack&&)’
settings_pack& operator=(settings_pack&&) noexcept = default;
^
In file included from ../include/libtorrent/torrent_info.hpp:52:0,
from ../include/libtorrent/torrent.hpp:48,
from ../include/libtorrent/web_connection_base.hpp:43,
from web_connection_base.cpp:38:
../include/libtorrent/file_storage.hpp:64:15: error: function ‘libtorrent::file_entry& libtorrent::file_entry::operator=(libtorrent::file_entry&&) &’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘libtorrent::file_entry& libtorrent::file_entry::operator=(libtorrent::file_entry&&)’
file_entry& operator=(file_entry&&) & noexcept = default;
^
In file included from ../include/libtorrent/aux_/socket_type.hpp:41:0,
from ../include/libtorrent/utp_socket_manager.hpp:39,
from ../include/libtorrent/aux_/session_udp_sockets.hpp:36,
from ../include/libtorrent/aux_/session_interface.hpp:46,
from ../include/libtorrent/ip_voter.hpp:40,
from ../include/libtorrent/peer_list.hpp:47,
from ../include/libtorrent/torrent.hpp:51,
from ../include/libtorrent/web_connection_base.hpp:43,
from web_connection_base.cpp:38:
../include/libtorrent/i2p_stream.hpp: In member function ‘void libtorrent::i2p_stream::set_destination(libtorrent::string_view)’:
../include/libtorrent/i2p_stream.hpp:105:51: error: ‘using string_view = boost::string_ref’ has no member named ‘to_string’
void set_destination(string_view d) { m_dest = d.to_string(); }
^
make[1]: *** [libtorrent_rasterbar_la-web_connection_base.lo] Error 1
make[1]: Leaving directory `/root/libtorrent-rasterbar-1.2.0/src'
make: *** [all-recursive] Error 1
Погуглил, но решений не нашел. Помогите, пожалуйста, разобраться.
В Fedora 29 qbittorrent 4.1.2, а libtorrent — 0.13.7. Думаю, с не меньшим успехом он соберётся и с libtorrent 0.13.6 из EPEL. Так что ставьте libtorrent-devel и забейте на сборку.
Что касается qbittorrent, попробуйте пересобрать федоровский пакет: rpmbuild --rebuild qbittorrent-4.1.2-1.fc29.src.rpm
в Fedora он использует не libtorrent (который, похоже, давно заброшен), а его форк rb_libtorrent. Как раз его вы и пытаетесь собрать. Только, судя по ошибкам, вам нужен компилятор посвежее. А это уже затея кровавая.
нужен компилятор посвежее. А это уже затея кровавая.
Сама по себе — не такая уж и кровавая, есть же SCL. Но вообще, конечно, лучше бы посмотреть на дистрибутивы с более свежим софтом. А то сейчас qbittorrent не устраивает, потом ещё чего-нибудь не хватит.
Ребят, я тут решил добить этот gcc (до этого просто воспользовался devtoolset-8 из SCL) - собрал его, но ОС все равно через gcc -v выдает старую версию. Подскажите, пожалуйста, каким образом возможно активировать мой собранный gcc?
Так-то задачу изначальную я выполнил - собрал libtorrent и qBittorent, но теперь не дает покоя gcc
Ребят, я тут решил добить этот gcc (до этого просто воспользовался devtoolset-8 из SCL) - собрал его, но ОС все равно через gcc -v выдает старую версию. Подскажите, пожалуйста, каким образом возможно активировать мой собранный gcc?
Так-то задачу изначальную я выполнил - собрал libtorrent и qBittorent, но теперь не дает покоя gcc
А чем из SCL не угодил? В пакетных дистрибутивах собирать что-то руками — последнее дело, очень легко запороть систему.
Ответ мой глуп и заключается в неудобстве - SCL надо каждый раз (при необходимости) активировать. А на постоянку его загружать некоторые товарищи не рекомендуют, правда совершенно не поясняю почему - может быть, Вы в курсе?
Ну и тут вопрос, конечно, как часто та необходимость будет возникать. Вообще, я как бы недопрограммист, поэтому она всё же будет.
Так и было. Я забыл отписаться по самому сабжу. В общем, для начала я взял более старшую libttorent - 1.1.12 (именно такая и используется в актуально qBittorent 4.1.5) - попытался её собрать, на что мне сообщили, что компилятора с поддержкой C++14 нема. Тогда я собрал gcc 6.5.0 - ох, это был не быстро. Но система его не увидела - надо как-то с путями работать, но инфы конкретной по этому поводу я не нашел - надо будет всё же залезть внутрь
Тогда я воспользовался devtoolset-8 из SCL (там вообще топовый gcc) и собрал и libtorrent 1.1.12, и qBittorent 4.1.5, который даже заработал в итоге как надо.
Сейчас перехожу к dlna-сервисам... Уже предвкушаю очередные сборки и там
Какой-нибудь из тех, у которых новые версии выходят стабильно раз в пару лет, а не раз в 4-5 лет со всё возрастающим периодом, и которые позволяют безболезненно обновиться на новую версию без переустановки.
Никто же не спорит, что есть промежуточные варианты. Просто у них уже не та степень стабильности.
Так и я про то же: степень стабильности получается более высокая, потому что никакая корпорация не меняет на переправе версии тех пакетов, которые ей (и только ей) вдруг понадобились более свежие, закрыв глаза на косяки этих самых новых версий, и потому что не приходится использовать репозитории, поддерживаемые абы кем и практически не тестируемые, из-за отсутствия в основной репе нужного тебе софта (по той причине, что он не нужен той самой корпорации). Короче, питаться объедками с барского стола вредно для здоровья.
Теоретически я согласен.
Но практически то, что все подразумевают под "стабильностью", выбирая дистрибутив с несвежим софтом, максимально именно у энтерпрайзных дистрибутивов типа CentOS.
То есть, отказываясь " зависеть от корпораций", пользователь начинает "зависеть от дилетантов". Что вряд ли лучше.
то, что все подразумевают под "стабильностью", выбирая дистрибутив с несвежим софтом, максимально именно у энтерпрайзных дистрибутивов типа CentOS.
Я не знаю, кто эти все и что они подразумевают, но лично я подразумеваю, что система работает на протяжении длительного времени одинаково хорошо, и этому не мешает установка обновлений. С CentOS мне такого добиться не удаётся.
Нет, это у вас бред.
Нельзя путать своё личное понятие "стабильности" с общепринятым.
P.S. Если для меня дистрибутив с циклом релизов в один год абсолютно стабилен, я не стану его советовать тем, кто ищет стабильности уровня CentOS, в отличие от вас.
Если для меня дистрибутив с циклом релизов в один год абсолютно стабилен, я не стану его советовать тем, кто ищет стабильности уровня CentOS, в отличие от вас.
Я устал повторять одно и то же. Уровень стабильности CentOS ниже дистрибутивов с циклом релизов 2 года (+ n лет поддержки после выхода следующей версии). Те, кто рассказывает о его стабильности, просто не устанавливают обновления и живут с незакрытыми уязвимостями. Знаю таких, и немало. У них действительно, как правило, всё работает стабильно, особенно если в интранете. Но рекомендовать такой подход я не намерен.
Я думаю стабильность - это способность функционировать без сбоев в том числе после обновлений + закрытие известных уязвимостей.
У меня CentOS 7 именно так и работает. Обновления ставлю все регулярно. Если руками не лезть, не подключать левые репозитории, не заменять системные библиотеки - всё работает идеально. Расплата - старые версии библиотек и ПО.
У меня CentOS 7 именно так и работает. Обновления ставлю все регулярно. Если руками не лезть, не подключать левые репозитории, не заменять системные библиотеки - всё работает идеально.
А у меня — нет. Увы, у меня активно используется libvirt, а это один из тех пакетов, которым шапка спокойно жить не даёт. Регулярно что-нибудь в нём ломается после очередного обновления. Насчёт не подключать левые репозитории — просто смешно, в родных же шаром покати.
Ну левые - я имею в виду те, которые подменяют существующие пакеты, а не расширяют их список. Так EPEL и rpmfusion не относятся к левым.
А если он заменяет gcc - то конечно левый.
А я разве писал, что проблемы ограничиваются одним libvirt? Это просто самый проблемный лично для меня пакет, но проблема им одним не ограничивается — она в самом подходе.
Ну левые - я имею в виду те, которые подменяют существующие пакеты, а не расширяют их список. Так EPEL и rpmfusion не относятся к левым.
А к каким — правым, ультраправым? Даже в EPEL качество пакетов оставляет желать лучшего, мейнтейнеры их толком не тестируют. Кое-как бекпортнулось — и ладно. При этом не факт, что всё работает, а процесс обновления с предыдущей версии и вовсе русская рулетка, потому что совместимость могли где-то поломать и уже об этом забыть (из того, с чем лично сталкивался: взяли и переименовали service-файл, в результате после обновления имеем битые симлинки и не стартующий сервис).