LINUX.ORG.RU

Проблема с makefile при сборке проекта.

 , ,


0

1

Добрый день! Нужно собрать проект github.com/galkinvv/gb_algs. В директории есть makefile, пробую собрать, вылетает следующее:

configure: error: expected an absolute directory name for --prefix: build/tmp/gmp_install

Makefile:109: recipe for target '3rd/gmp/include/gmp.h' failed

make: *** [3rd/gmp/include/gmp.h] Error 1

Подскажите, пожалуйста, в чем может быть дело? Первая строка ошибки ругается на 114 строку в makefile.

Пишет же, что в --prefix нужен полный путь, но там ещё и имя компилятора с жёстко заданой версией 4.8. Должно быть достаточно запускать как-то так:

make BUILDDIR=$PWD/build CXX11=g++ CC_FORCXX=gcc

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

С такой командой запуска сборки проект несколько минут собирался, но потом вылетает очередная ошибка:

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

Сообщение об ошибке неинформативно. И проект какой-то мутный, видимо, узко специализированный. Может, попробуй пообщаться с Галкиным В. В?

JaneDoe ()
Ответ на: комментарий от Aspromist

С такими правками собирается:

diff --git a/libtests/cross_ring_info.cpp b/libtests/cross_ring_info.cpp
index 56a4138..cdadf47 100644
--- a/libtests/cross_ring_info.cpp
+++ b/libtests/cross_ring_info.cpp
@@ -263,7 +263,7 @@ TEST_F(CrossRingInfoTest, IOForMonomialListListWithCoef)
 .       CrossRingInfo::MonomialListListWithCoef<DegRevLex, IntField> local_int_field_basis_info{order_, int_field_};
 
 .       std::istringstream in("{((42)), (), ((-2 x_1^3*x_4^2)+(-2)+(333 x_3^1))}");
-.       in >> local_int_field_basis_info;
+.       // in >> local_int_field_basis_info;
 .       //TODO: add expects
 }
 
diff --git a/utils.h b/utils.h
index 71cda93..5156268 100644
--- a/utils.h
+++ b/utils.h
@@ -807,7 +807,7 @@ DECLARE_FUNCTOR_TEMPLATE_T(std::size_t, SmallCollectionHash, const T& collection
 .       std::size_t result = 0;
 .       if (collection.size() != 0)
 .       {
-.       .       const int rotation_per_value = std::max(1, signed_cast(BIT_SIZEOF(result) / collection.size()));
+.       .       const int rotation_per_value = std::max(signed_cast(static_cast<std::size_t>(1)), signed_cast(BIT_SIZEOF(result) / collection.size()));
 .       .       for(auto i : collection)
 .       .       {
 .       .       .       result = RotateBitsRight(result, rotation_per_value) ^ CallStdHash(i);
Но вообще поддерживаю JaneDoe, issue можно делать. Правка в тестах не должна вредить, но всё же это гадание и автору кода может быть полезно знать о проблеме.

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

Большое спасибо за правки! Исправил 2 строчки, проект собрался, но есть варнинг: make: warning: Clock skew detected. Your build may be incomplete.

Это не серьезная проблема?

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

Время в системе не менялось? Что-то с часами произошло, или файлы редактировал удаленно. Для полной уверенности можешь сделать make clean и пересобрать.

JaneDoe ()
Ответ на: комментарий от Aspromist

Добрый. Первая просто убирает чтение из потока, так как там не было необходимого оператора (может он есть в каком-то заголовке или ещё по какой-то причине не виден в тесте). Вторая пропускает первый аргумент max через то же, через что проходит второй аргумент, чтобы типы параметров наверняка совпадали, так как иначе не сработает автоматический вывод типа параметра шаблона для max.

xaizek ★★★★★ ()
Последнее исправление: xaizek (всего исправлений: 1)
Ответ на: комментарий от xaizek

Спасибо за разъяснение, у меня остается еще вопрос - мне надо использовать большие числа, которые влезут только в 128-битную арифметику, как её можно «подключить»? http://pastebin.com/tx339Hzp вот файл, в котором упоминается LONG_DOUBLE_128.

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

Возможно, надо поменять здесь int на __int128 (плюс toInt() и подобное, где оно используется). Вообще, я слабо понимаю, что это за проект, так что если не везде используется этот класс модулярной арифметики, то надо будет менять в других местах. Так чтобы это просто конфигурировалось, я не вижу.

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

Спасибо большое за помощь, но я внезапно пришел в тупик, нужна конечная характеристика поля для данной реализации алгоритма, а в задаче поле рациональных дробей. Не могли бы вы подсказать, что можно в данном проекте «улучшить», чтобы хотя бы немного быстрее работало, пусть даже миллисекунды. Или что-то где-то оптимизировать. В общем, любая помощь сейчас кстати.

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

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

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

Ну замеры я проводил, метод гаусса жрет 90%+ всего времени, в частности прямой ход метода гаусса много ест. Он описан в cmatrix.cpp и называется forwardGaussElimination (backGaussElimination). Думал перевести вектора на массивы, но не знаю, уместно ли тут это.

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

Думал перевести вектора на массивы, но не знаю, уместно ли тут это.

Что-то это может дать, но вряд ли много (в push_back() проверки на размер разве что, ну и выделение памяти уберёт если VLA массив использовать, но только небольшой).

метод гаусса жрет 90%+ всего времени

Вообще код там нормальный, reserve() (правда, не везде), объекты вне циклов, всё такое. Но много всего вызывается, где-то есть new[]/delete[], другие вектора, может стоит глянуть в сторону замены аллокатора (хотя как-то сомневаюсь, что оно большой вклад даёт). Какое-нибудь разворачивание циклов можно попробовать поагрессивнее включить при компиляции или даже вручную. Может ещё представление матрицы подкачало, как я понимаю это разряжённая матрица типа вектор-векторов; кто знает, может в какой-нибудь Eigen это работало бы быстрее (они вроде как в Фортране хранят по столбцам, для лучшей производительности).

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

Спасибо большое за советы. А почему здесь (github.com/galkinvv/gb_algs/blob/master/cmatrix.cpp#L110) нужно использовать reserve(), ведь там res(msz) уже выделяет память, или я что-то не уловил?

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

Тот конструктор инициализирует все элементы нулями и сразу после этого все эти нули перезаписываются в цикле. Конечно, ещё вопрос что быстрее: записать N нулей, а потом из перезаписать или ничего не записывать и потом N раз вызвать push_back(), это уже надо проверять.

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

Спасибо, понятно, подскажите пожалуйста, как приостановить выполнение на указанное количество наносекунд? Микросекунды не помогают, что 70 мксек, что 2 мксек, результат один и тот же, хотя должен быть разным, ведь с приостановкой на 1000 мксек увеличивается работа программы в 2 раза, значит 70 мксек должны увеличить на 7%, но увеличивается на 37%, 2 мксек тоже на где-то на 35% увеличивают.

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

70 мксек должны увеличить на 7%

Только млсек для 7%, или 70000 мксек.

как приостановить выполнение на указанное количество наносекунд?

Есть nanosleep(), но он не поможет. Все задержки на t гарантированно выполняются минимум t, но чаще всего больше. Т.е. это всегда минимальное время зареджки и ниже частоты переключения задач (10 или 1 мс., зависит от конфигурации ядра) оно не опустится и будет округляться + время переключения задач. Можно попробовать сделать активный цикл ожидания с gettimeofday() и поднять процессу приоритет, но идеальных результатов не будет всё равно.

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