madf

Внимание! В последнюю сборку вкралась очень неприятная ошибка. В скрипт build в строку 167 попало вот это: CHECK_FBCLIENT=no Эту строчку нужно просто удалить - она приводит к тому, что плагин для Firebird не собирается, даже если либа libfbclient.so найдена.

Несовместимая версия? По логу вроде как нету ни дефиниции ни реализации методов класса.

ОС, версия компилятора, модуль хранилища. Желательно сделать корку и отдать ее мне (ulimit -c 10000, после этого ждем падения и ищем в каталоге из которого запускался файл вида core.XXXX для Linux или stargazer.core для FreeBSD).

Судя по ошибке make install Вы не делали, а после сборки КК либо почистили сборочный каталог либо собрали еще что-то другое. Запуск без установки поддерживается, в основном, для тестирования и отладки. Так что или пересобрать КК или сделать установку.

Скоро будет вместе с релизом на официальном сайте. Думаю, еще неделька-две.

так и сделано: оригинал /usr/local/include/expat.h на него симлинк /usr/include/expat.h до последнего билда это проканывало, щас ошибка Нужен не только заголовочный файл, но и сама библиотека. То есть, если expat установлен в /usr/local, то нужно или переконфигурировать ld.so (/etc/ld.so.conf), либо сделать симлинк на /usr/local/lib/libexpat.so в /usr/lib.

Да, это я глянул в CVS'ную версию, где я вынес уже эти переменные на "передний план". Лучше вставить перед блоком echo примерно в 178 строке. stg собирается с помощью g++, т.к. проект написан на С++. Однако, в отличие от Autotools, где для g++ используется CXXFLAGS тут этой переменной нету. Компилятору передается переменная CFLAGS, с которой и надо работать. Можно закоментировать последнюю строчку скрипта, в которой запускается сборка вызовом gmake и проконтролировать его работу: все сборочные переменные будут определены в файле Makefile.conf, находящемся в самом корневом каталоге stg.

А, ну это просто. 7 и 8 строка скрипта build Там стоят по умолчанию пустые значения, к которым в процессе настройки билда цепляются необходимые ключи (-g3 для отладочного билда, -O2 для рабочего билда, -fPIC и -Wl,-rpath,<путь> и т.д.). Туда и нужно прописать -march=athlon -mtune=athlon

-fPIC указывает компилятору генерировать позиционно-независимый код. Это абсолютно необходимо для динамический библиотек aka .so-файлов. Собственно, в stglibs и в плагинах он везде есть. В приведенном кусочке лога он совершенно не нужен, т.к. admin.cpp - это часть ядра Stg, а не кусок библиотеки. Ворнинг /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object говорит о том, что в .so при компоновке попадает не позиционно-независимый код. Хотелось бы увидеть предыдущую строчку лога, в которой указывается, что это собирается и из чего.

Отлично! Жду отзывов

Почитал про verify-elf. Подумал. Может, включать сборочный каталог в RPATH только для отладочных билдов? Кто-нибуть запускает рабочий сервер без установки?

Для .so-шек я добавляю два элемента RPATH: сборочный каталог для возможности запуска из места сборки и каталог установки (дабы не заморачиваться с конфигурированием ld.so-кэша). Я так понимаю, оно ругается на то, что RPATH содержит нестандартные пути расположения библиотек. Интересно, почему...

О, отлично! Так, 00-base-00.sql точно последний? Там на каком-то из старых это наблюдалось. Это какое-то из булевых полей.

unresolved'ы плагинов не могут не быть. Это, фактически, API сервера. Функции импортируемые из ядра. Там только в mod_cap_ipq.so несколько незаконных unresolved - см. решение тут.

stglibs/common.lib/common.cpp:78 Замените 1024 на, скажем, 4096, соберите заново и еще раз получите эту ошибку. fbclient очень многословен - не влазит в буфер

Версии клиента и сервера Firebird совпадают?

Дело в том, что конвертор по умолчанию собирается в DEBUG-режиме и только в нем. Но динамический компоновщик при запуске конвертора вместо вновь собранных библиотек загружает уже установленные. Так что повторная пересборка может не помочь. Можно попробовать в Makefile конвертора заменить LDFLAGS += -Wl,-E -L$(DIR_LIB) -Wl,-rpath,$(PREFIX)/usr/lib/stg -Wl,-rpath,$(DIR_LIB) на LDFLAGS += -Wl,-E -L$(DIR_LIB) -Wl,-rpath,$(DIR_LIB) После такого компоновщик уже не выкрутится

Эммм... Кажется допер. Вот это: libstg_common.so => //usr/lib/stg/libstg_common.so (0x008e2000) - причина молчания. Я так понимаю, это либа от установленного и скомпиленного старгейзера с отключенным DEBUG-режимом? Соответственно, она "говорить" не умеет. Конвертор запускается из каталога сборки или еще откуда? Если я прав - это легко фиксится.

Хотелось бы увидеть вывод команд uname -a gcc --version ldd ./convertor Я пока не вижу вариантов, при которых конвертор молчал бы.

Хак, позволяющий собирать с оптимизацией под x86_64: --- user.cpp 2007-05-05 20:02:40.000000000 +0300 +++ user.cpp.new 2007-10-17 12:28:36.000000000 +0300 @@ -1299,7 +1299,7 @@ if (msg->header.repeat > 0) { msg->header.repeat--; - msg->header.lastSendTime = stgTime; + msg->header.lastSendTime = time(NULL); if (store->AddMessage(msg, login)) { errorStr = store->GetStrError(); @@ -1378,7 +1378,7 @@ } else { - msg.header.lastSendT

Для сборки под платформу x86-64 оптимизацию нужно отключить (в файле build). Похоже что это действительно баг компилятора.

2All: Внутренняя ошибка компилятора на user.cpp вызывается оптимизацией. Проверено на -O1, -O2 и -O3. Без оптимизации собирается нормально.

Лог сборки можете предоставить?

Вот эта штука -Wl,-rpath,$(PREFIX)/usr/lib/stg добавляет в пути посика библиотек указанный каталог. И устанавливаются они тоже туда. Снаружи берется только -lexpat, -lpthread, -ldl, -lfbclient. Так что если у Вас в /usr/lib64 или /usr/lib не валяется каких-нибуть старых библиотек/модулей - все должно работать. В противном случае оно сперва будет искать по стандартным путям, найдет старые и... Дальше все зависит от фантазии динамического компоновщика

Как это молчит?! Последний не может молчать - он не умеет молчать! В первой же строке он выводит что-то вроде main.cpp > 15:55:15 > Start У Вас точно последний конвертор?