[boinc] Ошибка при сборке примера генератора заданий

Выложи исходники string3.h sample_work_generator.cpp & вывод после препроцессора.

sample_work_generator.cpp, string3.h, после препроцессинга. Вообще смутно представляю себе назначение string3.h, выглядит как какой то сервисный заголовок, относящийся к gcc или libc.

Упс, я невнимательно посмотрел вывод компилятора.

Ты неправильно линкуешь статические библиотеки, это раз.

Правильно - это сначала указать путь до дирки с либами, используя ключ -L <path>, а потом передать имя библиотеки через -l, префикс lib нужно опустить, пример -lboinc_api заместо libboinc_api.a

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

Указывать библиотеки нужно после объектников

Дальше, ты пытаешься использовать библиотеки с одинаковыми файлами (boinc & sched). Попробуй убрать sched

Заменил libfoo.a на -Lbar -lfoo, вывод компилятора не изменился:

$ g++ sample_work_generator.cpp -pthread -Wall  -I ../libs/api-x86_64 -I ../libs/lib-x86_64  -I ../libs/db-x86_64 -I ../libs/tools-x86_64 -I ../libs/sched-x86_64 -I /usr/include/mysql/ -L../libs/api-x86_64/ -lboinc_api -L../libs/lib-x86_64/ -lboinc -L../libs/sched-x86_64/ -lsched -L../libs/lib-x86_64/ -lboinc_crypt -L/usr/lib/ -lmysqlclient -lz -lssl  -o sample_work_generator
../libs/sched-x86_64//libsched.a(libsched_la-boinc_db.o): In function `WORKUNIT::clear()':
/usr/include/bits/string3.h:86: multiple definition of `WORKUNIT::clear()'
../libs/lib-x86_64//libboinc.a(libboinc_la-gui_rpc_client_ops.o):/usr/include/bits/string3.h:107: first defined here
../libs/sched-x86_64//libsched.a(libsched_la-boinc_db.o): In function `RESULT::clear()':
/usr/include/bits/string3.h:86: multiple definition of `RESULT::clear()'
../libs/lib-x86_64//libboinc.a(libboinc_la-gui_rpc_client_ops.o):/usr/include/bits/string3.h:107: first defined here
../libs/sched-x86_64//libsched.a(libsched_la-boinc_db.o): In function `APP_VERSION::clear()':
/usr/include/bits/string3.h:86: multiple definition of `APP_VERSION::clear()'
../libs/lib-x86_64//libboinc.a(libboinc_la-gui_rpc_client_ops.o):/usr/include/bits/string3.h:107: first defined here
../libs/sched-x86_64//libsched.a(libsched_la-boinc_db.o): In function `APP::clear()':
/usr/include/bits/string3.h:86: multiple definition of `APP::clear()'
../libs/lib-x86_64//libboinc.a(libboinc_la-gui_rpc_client_ops.o):/usr/include/bits/string3.h:107: first defined here
collect2: ld returned 1 exit status

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

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

Если ты уверен, что ты всё делаешь правильно - то могу предложить окрыть gui_rpc_client_ops.cpp и закоменнтить методы clear() для классов WORKUNIT/APP/APP_VERSION/RESULT.

Самое интересное вот где: так выглядит сборка этого исходника в самом боинке:

$ make sample_work_generator | grep sample_work_generator
g++ -DHAVE_CONFIG_H -I. -I..  -I../lib -I../api -I../db -I../client -I../tools -I../sched -I../lib/mac -pthread -I/usr/include/mysql  -DBIG_JOINS=1  -fno-strict-aliasing   -DUNIV_LINUX -DUNIV_LINUX -pthread   -g -O2 -Wall -MT sample_work_generator.o -MD -MP -MF .deps/sample_work_generator.Tpo -c -o sample_work_generator.o sample_work_generator.cpp
mv -f .deps/sample_work_generator.Tpo .deps/sample_work_generator.Po
/bin/bash ../libtool --tag=CXX   --mode=link g++  -g -O2 -Wall -static  -o sample_work_generator sample_work_generator.o ../sched/libsched.la ../lib/libboinc_crypt.la ../lib/libboinc.la -Wl,-Bsymbolic-functions -rdynamic -L/usr/lib/mysql -lmysqlclient  -lcrypto -lssl -lcrypto   
libtool: link: g++ -g -O2 -Wall -o sample_work_generator sample_work_generator.o -Wl,-Bsymbolic-functions -rdynamic  ../sched/.libs/libsched.a -L/usr/local/lib ../lib/.libs/libboinc_crypt.a ../lib/.libs/libboinc.a -ldl -L/usr/lib/mysql /usr/lib/libmysqlclient.so -lpthread -lcrypt -lnsl -lm -lz -lssl -lcrypto -pthread

Оставил только строчки, где он непосредственно упоминается, полный лог тут. В самом конце объектник линкуется с обоими библиотеками, и с sched, и с boinc, но конфликт как то разруливается.

Здесь нет, например, boinc_api

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

Поменял порядок библиотек, поставил sched перед boinc и все собралось. Есть ли способ сделать поведение gcc независимым от порядка библиотек? А то выходит неприятная ситуцация с мейкфайлами: бинарники собираются по правилу $(CXX) $^ $(CXXFLAGS) $(CXXFLAGS-EXTRA) $(INCLUDES) $(INCLUDES-EXTRA) $(LIBS) $(LIBS-EXTRA) -o $@ Где $(CXXFLAGS) и $(INCLUDES) - общие для всех, а -EXTRA - специфичные для каждого. В данном случае $(LIBS) и $(LIBS-EXTRA) выглядят так:

LIBS = 		$(API_DIR)/libboinc_api.a \
			$(LIB_DIR)/libboinc.a \


LIBS-EXTRA = 	$(SCHED_DIR)/libsched.a \
			$(LIB_DIR)/libboinc_crypt.a \
			/usr/lib/libmysqlclient.a \
			-lz \
			-lssl \

То есть sched оказывается после boinc и я сразу не вижу красивого и правильного способа решить проблему.

И в догонку вопрос: меняя порядок либ мы только меняем порядок, в котором линкер напорется на разные определения одних и тех же методов, но не избавит нас от самого факта их существования.
Каким образом порядок либ избавляет меня от проблемы?

> И в догонку вопрос: меняя порядок либ мы только меняем порядок, в котором линкер напорется на разные определения одних и тех же методов

Верно.

но не избавит нас от самого факта их существования.

То же верно.

Каким образом порядок либ избавляет меня от проблемы?

Линкер прекращает поиск и обработку библиотек, указанных в command line, как только он находит нужный символ. Дальше библиотеки не просматриваются. Плюс, каждая секция с определением чего-либо попадает в результатирующий elf только если на неё ссылаются. Поэтому, если линкер нашёл все символы и не добрался до объектника с дублирующими определениями - то эти дублирующие определения не попадают в результатирующий файл и конфликтов не будет.

> Поменял порядок библиотек, поставил sched перед boinc и все собралось. Есть ли способ сделать поведение gcc независимым от порядка библиотек?

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

>Поэтому, если линкер нашёл все символы и не добрался до объектника с дублирующими определениями - то эти дублирующие определения не попадают в результатирующий файл и конфликтов не будет.

То есть картина такая:
1) линкер дошел до libsched.a, нашел все уникальные для этой либы символы, прилинковал
2) нашел там все символы, которые дублируются в libboinc.a, прилинковал их
3) «вышел» из libsched.a
4) дошел до libboinc.a, залинковал все уникальные до нее символы
5) проигнорировал дублирующиеся символы, т.к. они уже прилинкованы

Если все происходит так, то я не вижу ничего, что мешает происходить процессу в обратном порядке, сначала libboinc, потом libsched. В том, что линкер доходит до libboinc удостоверился.

Нет, не так. На пальцах происходит так:

1) Есть объектник, символы которого нужно зарезовлить.

2) Пусть {Un} - множество неопределённых символов в объектнике из #1. ЕСли оно пустое - то процесс завершён.

3) Теперь, для каждой библиотеки, указанной в командной строке, пока {Un} /= {Ф} (пустому множеству):

3а) Определяем объектники из просматриваемой библиотеки, которые экспортируют символы с именами из множеста {Un}.

3б) Линкуем эти объектники к объектнику-результату

3в) Теперь объектник содержит множество неопределённых символов, равное {Un \ T } U {Un2}, где Т - это множество определённых символов из #3а Un2 - это множество неопределённых символов из только что прилинкованных объектников.

Оффтопик: сделаешь - присоединюсь к проекту.

Врят ли проект далеко уползет за пределы моего универа из-за своей специфики. Это будет скорее вычислительная сеть по требованию, нежели какое то постоянное сканирование звездного неба или моделирования сворачивания белков.
Суть проблемы такова: в Карелии огромное количество озер и имеется необходимость мониторить их экологическое состояние. Одним из показателей служит содержание планктона на единицу объема воды. Руками это делается так:
1) научный сотрудник берет командировку, едет на озеро
2) набирает там склянку воды, везет в лабораторию
3) там её исследуют и делают выводы

Объехать сразу кучу озер и набрать кучу склянок нельзя, за это время планктон «испортится».

Был предложен вариант по автоматизации:
1) делается девайс, представляющий собой камеру с GPS модулем, который опускается в воду, производится съемка
2) девайс отправляет видео на сервер
3) сотрудник едет с девайсом на следующее озеро.

На сервере видео некоим образом обрабатывается на видяхе, на выходе получается другое видео+результат анализа. Обсчет одного кадра занимает 5-30 секунд, по этому обработка видео минут этак в 10 заеймет приличное время.

Тут то и начался мой курсач. Я предложил резать видео по ключевым кадрам и через боинк рассылать на несколько машин.
Собственно по этому проект будет мало привлекателен сторонним кранчерам:
1) непостоянный поток заданий
2) большой траффик: входные и выходные файлы - видео
3) локальная и прикладная цель проекта, никаких лекарств от рака и проверки фундаментальных теорий физики