madf

Конечно, было бы неплохо форкнуть тему (или использовать ЖЖ), но в условиях форума довольно сложно. --no-as-needed нужно пихать в ключи сборки сервера (в корневой Makefile stargazer), а не в сборку библиотек или модулей. Потому что --no-as-needed относится именно к серверу. Warnings по поводу сборки модулей (undefined symbol) - результат неявного указания зависимостей от различных библиотек и объектных файлов сервера. Тоесть, это издержки системы сборки - зависимости разрешаются при компоновке сервера. Выход один - кардинально менять систему сборки сервера, что сейчас и происходит.

2Drool: По поводу логов компиляции. Я так понимаю, эта подстановка - работа автоматизированной системы сборки. Так вот, для библиотек и модулей обязательно нужно указывать -fPIC для генерации позиционно-независимоого кода. Сообщения: как раз об этом и предупреждают. PS: судя по бинарникам в rpm'ке у вас не пофикшен install_bin. Поправьте как указано тут: http://local.com.ua/forum/index.php?showto...indpost&p=66146

2Drool: Так, я думаю, проблема связанная с решена. Это либо фича дистрибутива, либо Вашей системы сборки. При компоновке по умолчанию используется ключ --as-needed компоновщика. Ситуация следующая: некоторые библиотеки (в частности, libstg_common.so) используют функции других библиотек (шифрование из libstg_crypto.so для функций EncryptString/DecryptString). При компоновке библиотек не указывается зависимость друг от друга - она разрешается при компоновке сервера. При этом, сам stargazer в явном виде libstg_crypto.so не использует - только в модулях и через функции libstg_common.so. Таким образом, линковка stargazer с libstg_crypto.so является избыточной. Но она необходима для использования libstg_common.so. Выход 1: Использовать ключ --no-as-needed при сборке (-Wl,--no-as-needed для g++) - он должен быть указан ДО списка библиотек Выход 2: Глобально изменить систему сборки библиотек и модулей и указывать в них зависимости от других библиотек через -l<name> С моей точки зрения, второй выход значительно более правильный, но вызывает некоторые затруднения, связанные со спецификой системы каталогов дистрибутива (необходимость копирования библиотек и модулей после компиляции в один каталог). Внятного решения этой проблемы я так и не нашел (столкнулся с ней несколько ранее в процессе перевода системы сборки stg на autotools). PS: ошибку компиляции удалось повторить именно с ключем --as-needed:

2Drool: Как я уже писал выше, поддержка BlowFish - это задача библиотеки libstg_crypto.so. То есть линковка libstg_common.so с объектником из libstg_crypto.so - это как раз та проблема, которая описана тут: http://www.freesource.info/wiki/AltLinux/S...earch=as-needed Быстрое и простое решение - вынос функций EncodeString и DecodeString в библиотеку linstg_crypto.so. Но при этом останется неизвестной причина, почему компоновщик не видит символов Blowfish_Init, Blowfish_Encrypt и Blowfish_Decrypt, хотя библиотека libstg_crypto.so указана при сборке stargazer. Опять же, не могу повторить эту ошибку ни на SuSE 10.0, ни на Gentoo 2007 для компиляторов веток 3.* и 4.*. Интересно было бы посмотреть на вывод команды objdump -t libstg_crypto.so | grep Blowfish И еще, совершенно непонятно, откуда у Вас взялась строчка g++ -pipe -Wall -O2 -I ../../include/ -I ./ -DLINUX -DSTG_TIME -c stg_logger.cpp Стандартный Makefile.in должен генерировать такой код: g++ -g3 -Wall -fPIC -I ../../include/ -I ./ -DLINUX -DSTG_TIME -c stg_logger.cpp При сборке Stargazer оптимизация не используется, зато отладочная инормация всегда включается. Там неоткуда было взяться ключу -O2. В то-же время ключ -fPIC совершенно необходим для генерации динамически компонуемых библиотек (указание на генерацию позиционно-независимого кода). Сборка проводилась из "чистых" исходников? Там небыло результатов предыдущих компиляций?

Это очень ПЛОХОЕ решение Странно что вобще собирается...

Его там и не должно быть. Шифрование BlowFish - это часть библиотеки libstg_crypto.so Избыточной линковки тут тоже нет, т.к. при сборке библиотек зависимости не учитываются, а разрешаются именно при сборке сервера. Возможно, в этом проблема.

_ДОЛЖЕН_ работать и на ветке 1.5 Вкусностей версии 2 не использовалось, хоть и очень хотелось

и все... не запускается. Этот символ должен быть определен в libdotconfpp.so. Проверял на FreeBSD 5.3 - не смог вызвать повторение ошибки. Если Вас не затруднит - предоставьте лог компиляции по адресу faust@stg.dp.ua

Если Вы имеете в виду сообщения вида "Broken pipe!" - то это довольно занятная проблема. Есть подозрение, что это результат работы функции printfd, которая используется для вывода лога в консоль. При работе в режиме дэмона эта функция все равно выводит лог, хотя stdout закрыт. Возможно, при этом происходит переполнение какого-то внутреннего буфера функции printf, что вызывает сигнал обрыв сокета связи с БД и, как следствие - SIG_PIPE. Как вариант - попробуйте закомментировать код этой функции (он находится в файле stglibs/common.lib/common.cpp).

Проблема изучается. Воспроизвести ошибку не удалось, по этому не могу указать точного решения. Попробуйте переставить местами строки -lstg_common и -lstg_crypto в projects/stargazer/Makefile Библиотека libstg_common.so использует функции шифрования из libstg_crypto.so. Однако, на сегодня, библиотеки собираются без указания зависимостей - они разрешаются при линковке сервера. Возможно, для вашей версии компоновщика важен порядок линковки библиотек.

Кстати, без крупнозернистого рашпиля и тяжелой кувалды старгайзер не соберется на линухе x86_64, в котором нет биарча (ALT относится именно к таким) именно из-за гвоздей-сотки в виде явкого указания /lib или /usr/lib На самом деле, если взглянуть на Makefile, который лежит в projects/stargazer, все внешние библиотеки (вроде expat или pthread) указаны вполне корректно: -lexpat -lpthread К сожалению, под рукой нету машины x86_64 чтобы тестировать на ней сборку и работоспособность, по этому пока нельзя сказать, почему у Вас -lpthread разрешается как /usr/lib/libpthread.so