Новая сборка СТГ 2.4

[madf 279]

Я не использую при сборке указание путей библиотек. -l<name> работает с /etc/ld.so.cache, а его содержимое зависит от настроек конечной системы.

[Ork Yason 8]

взлетел

 

а конвертер малчит - как русишь партизанен

[Drool 0]

Я не использую при сборке указание путей библиотек. -l<name> работает с /etc/ld.so.cache, а его содержимое зависит от настроек конечной системы.

Makefile:

LDFLAGS += -Wl,-E -L$(DIR_LIB) -Wl,-rpath,$(PREFIX)/usr/lib/stg -Wl,-rpath,$(DIR_LIB)

 

И так далее и не только в Makefile. Я знаю на примере сборки проигрывателя qmmp даже собранные нормально либы положенные на x86_64 в папку /usr/lib потом у меня валили унресолведы. Было достаточно уже бинарные *.so переложить в /usr/lib64. Я это имел ввиду.

 

P.S. Сборочная среда для 64 бит возможна. Ы? :-|<

[Ork Yason 8]

а сообщения классно отправляются:

 

# ./sgconf -s localhost -p 4444 -a хххххххх -w хххххххх -u юзер -m kiso_ku-ku

*** glibc detected *** ./sgconf: free(): invalid next size (fast): 0x0858a090 ***

======= Backtrace: =========

/lib/libc.so.6[0xad2f5d]

/lib/libc.so.6(cfree+0x90)[0xad65b0]

/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x2e8ef1]

/usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0x2e8f4d]

./sgconf(_Z13CreateRequestP7REQUESTPc+0x85)[0x804a635]

./sgconf(_Z7ProcessP7REQUEST+0x83)[0x804b383]

./sgconf(main+0x808)[0x804bc18]

/lib/libc.so.6(__libc_start_main+0xdc)[0xa82dec]

./sgconf(__gxx_personality_v0+0x9d)[0x8049bb1]

======= Memory map: ========

00235000-00315000 r-xp 00000000 16:01 537546 /usr/lib/libstdc++.so.6.0.8

00315000-00318000 r-xp 000e0000 16:01 537546 /usr/lib/libstdc++.so.6.0.8

00318000-0031a000 rwxp 000e3000 16:01 537546 /usr/lib/libstdc++.so.6.0.8

0031a000-00320000 rwxp 0031a000 00:00 0

00422000-00423000 r-xp 00422000 00:00 0 [vdso]

00557000-0055a000 r-xp 00000000 16:01 918103 /usr/lib/stg/libstg_common.so

0055a000-0055b000 rwxp 00003000 16:01 918103 /usr/lib/stg/libstg_common.so

005be000-005c2000 r-xp 00000000 16:01 918102 /usr/lib/stg/libstg_crypto.so

005c2000-005c3000 rwxp 00003000 16:01 918102 /usr/lib/stg/libstg_crypto.so

0068c000-00692000 r-xp 00000000 16:01 918105 /usr/lib/stg/libconffiles.so

00692000-00693000 rwxp 00005000 16:01 918105 /usr/lib/stg/libconffiles.so

006f0000-0070f000 r-xp 00000000 16:01 461026 /lib/libexpat.so.0.5.0

0070f000-00711000 rwxp 0001e000 16:01 461026 /lib/libexpat.so.0.5.0

0088f000-0089a000 r-xp 00000000 16:01 917610 /usr/lib/stg/libsrvconf.so

0089a000-0089b000 rwxp 0000b000 16:01 917610 /usr/lib/stg/libsrvconf.so

00a4b000-00a64000 r-xp 00000000 16:01 461007 /lib/ld-2.5.so

00a64000-00a65000 r-xp 00018000 16:01 461007 /lib/ld-2.5.so

00a65000-00a66000 rwxp 00019000 16:01 461007 /lib/ld-2.5.so

00a6d000-00ba4000 r-xp 00000000 16:01 461008 /lib/libc-2.5.so

00ba4000-00ba6000 r-xp 00137000 16:01 461008 /lib/libc-2.5.so

00ba6000-00ba7000 rwxp 00139000 16:01 461008 /lib/libc-2.5.so

00ba7000-00baa000 rwxp 00ba7000 00:00 0

00bac000-00bae000 r-xp 00000000 16:01 461014 /lib/libdl-2.5.so

00bae000-00baf000 r-xp 00001000 16:01 461014 /lib/libdl-2.5.so

00baf000-00bb0000 rwxp 00002000 16:01 461014 /lib/libdl-2.5.so

00bb2000-00bd7000 r-xp 00000000 16:01 461012 /lib/libm-2.5.so

00bd7000-00bd8000 r-xp 00024000 16:01 461012 /lib/libm-2.5.so

00bd8000-00bd9000 rwxp 00025000 16:01 461012 /lib/libm-2.5.so

00bdb000-00bee000 r-xp 00000000 16:01 461010 /lib/libpthread-2.5.so

00bee000-00bef000 r-xp 00012000 16:01 461010 /lib/libpthread-2.5.so

00bef000-00bf0000 rwxp 00013000 16:01 461010 /lib/libpthread-2.5.so

00bf0000-00bf2000 rwxp 00bf0000 00:00 0

00cbd000-00cc8000 r-xp 00000000 16:01 461015 /lib/libgcc_s-4.1.1-20070105.so.1

00cc8000-00cc9000 rwxp 0000a000 16:01 461015 /lib/libgcc_s-4.1.1-20070105.so.1

08048000-0804e000 r-xp 00000000 16:03 754389 /var/install/stg-2.4-2007.10.12-15.36.05/projects/sgconf/sgconf

0804e000-0804f000 rw-p 00006000 16:03 754389 /var/install/stg-2.4-2007.10.12-15.36.05/projects/sgconf/sgconf

0858a000-085ab000 rw-p 0858a000 00:00 0

b7e00000-b7e21000 rw-p b7e00000 00:00 0

b7e21000-b7f00000 ---p b7e21000 00:00 0

b7fb8000-b7fbb000 rw-p b7fb8000 00:00 0

b7fc5000-b7fc6000 rw-p b7fc5000 00:00 0

bfb36000-bfb4b000 rw-p bfb36000 00:00 0 [stack]

Аварийный останов

[madf 279]

а конвертер малчит - как русишь партизанен

Как это молчит?! Последний не может молчать - он не умеет молчать!

В первой же строке он выводит что-то вроде

         main.cpp > 15:55:15 > Start

У Вас точно последний конвертор?

[Ork Yason 8]

тихо молчит

 

ни единой строчки нема

 

указал в одном файле путь к старгазеру

в другом пусть к базе

и тихо...

 

подумал чего и - фсе...

[madf 279]

Makefile:

LDFLAGS += -Wl,-E -L$(DIR_LIB) -Wl,-rpath,$(PREFIX)/usr/lib/stg -Wl,-rpath,$(DIR_LIB)

 

И так далее и не только в Makefile. Я знаю на примере сборки проигрывателя qmmp даже собранные нормально либы положенные на x86_64 в папку /usr/lib потом у меня валили унресолведы. Было достаточно уже бинарные *.so переложить в /usr/lib64. Я это имел ввиду.

 

P.S. Сборочная среда для 64 бит возможна. Ы? :-|<

Вот эта штука

-Wl,-rpath,$(PREFIX)/usr/lib/stg

добавляет в пути посика библиотек указанный каталог. И устанавливаются они тоже туда. Снаружи берется только -lexpat, -lpthread, -ldl, -lfbclient.

Так что если у Вас в /usr/lib64 или /usr/lib не валяется каких-нибуть старых библиотек/модулей - все должно работать. В противном случае оно сперва будет искать по стандартным путям, найдет старые и... Дальше все зависит от фантазии динамического компоновщика

[madf 279]

тихо молчит

 

ни единой строчки нема

 

указал в одном файле путь к старгазеру

в другом пусть к базе

и тихо...

 

подумал чего и - фсе...

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

[Drool 0]

-Wl,-rpath,$(PREFIX)/usr/lib/stg

[/code]

добавляет в пути посика библиотек указанный каталог. И устанавливаются они тоже туда.

Не, ну это-то понятно. Я имею ввиду что на 64-х битах либы нужно ложить в /usr/lib64/stg

[Ork Yason 8]

http://www.slav.net.ua/download/111

[madf 279]

2All:

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

[Ork Yason 8]

так делать-то чего?

[Drool 0]

2All:

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

Насколько мне известно - на _всех_ rpm-based дистрибутивах (за другие не скажу) сборка происходит с оптимизацией, так как rpm-build передает компилятору опции компилирования плюс переменная $RPM_OPT_FLAGS (или как-то так). Т.е. если как-то собрать это руками в src.rpm пакет, то у другого пользователя штатная операция rpm --rebuild не пройдет. Нужно лечить.

[stg34 0]

Насколько мне известно - на _всех_ rpm-based дистрибутивах (за другие не скажу) сборка происходит с оптимизацией, так как rpm-build передает компилятору опции компилирования плюс переменная $RPM_OPT_FLAGS (или как-то так). Т.е. если как-то собрать это руками в src.rpm пакет, то у другого пользователя штатная операция rpm --rebuild не пройдет. Нужно лечить.

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

1. Бинарный пакет можно собрать на gcc 3.x

2. Бинарный пакет можно собрать с неполной оптимизацией, отключив именно ту опцию которая приводит к падению компилятора.

3. А в srpm наверное можно переопределить переменную $RPM_OPT_FLAGS тогда будет всё ок.

 

По поводу п.3 точно не знаю, никогда не делал.

[madf 279]

так делать-то чего?

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

 

Похоже что это действительно баг компилятора.

[stg-34 0]

Выше был я

Не стого логина зашел

[Drool 0]

так делать-то чего?

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

 

Похоже что это действительно баг компилятора.

Drool Срд Окт 17 2007 11:52:10

Ты сейчас на x86_64?

 

opponent Срд Окт 17 2007 11:53:44

я везде на 64 )

 

[skip]

 

opponent Срд Окт 17 2007 11:56:19

я с -O2 все собираю

 

opponent Срд Окт 17 2007 11:56:47

у нас ж вроде -O2 прибит по умолчанию не?

 

opponent Срд Окт 17 2007 12:08:02

ща дам те вывод flac123

 

[skip]

x86_64-alt-linux-gcc -pipe -Wall -O2 -I/usr/local/include -L/usr/local/lib -o flac123 flac123.o remote.o vorbiscomment.o -lFLAC -logg -lm -lpopt -L/lib -lao -ldl

make: Leaving directory `/usr/src/RPM/BUILD/flac123-0.0.11'

+ exit 0

[stg-34 0]

Похоже нашли как обойти багу

[madf 279]

Хак, позволяющий собирать с оптимизацией под 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.lastSendTime = stgTime;
+                    msg.header.lastSendTime = time(NULL);
                    if (store->EditMessage(msg, login))
                        {
                        printfd(__FILE__, "EditMessage Error %s\n", store->GetStrError().c_str());

 

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

[Ork Yason 8]

так делать-то чего?

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

 

Похоже что это действительно баг компилятора.

да я не про 64бит

 

я про конвертер, который молчит и ничего не делает

[madf 279]

Хотелось бы увидеть вывод команд

uname -a

gcc --version

ldd ./convertor

Я пока не вижу вариантов, при которых конвертор молчал бы.

[Ork Yason 8]

gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52)

 

Linux router.slav.net.ua 2.6.18-8.el5 #1 SMP Thu Mar 15 19:57:35 EDT 2007 i686 i686 i386 GNU/Linux

 

linux-gate.so.1 => (0x005d7000)

libstg_logger.so => //usr/lib/stg/libstg_logger.so (0x0083f000)

libstg_common.so => //usr/lib/stg/libstg_common.so (0x008e2000)

libscript_executer.so => //usr/lib/stg/libscript_executer.so (0x0079c000 )

libdotconfpp.so => //usr/lib/stg/libdotconfpp.so (0x00dfa000)

libexpat.so.0 => /lib/libexpat.so.0 (0x006f0000)

libpthread.so.0 => /lib/libpthread.so.0 (0x00bdb000)

libdl.so.2 => /lib/libdl.so.2 (0x00bac000)

libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00235000)

libm.so.6 => /lib/libm.so.6 (0x00bb2000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00cbd000)

libc.so.6 => /lib/libc.so.6 (0x00a6d000)

libstg_crypto.so => //usr/lib/stg/libstg_crypto.so (0x00110000)

/lib/ld-linux.so.2 (0x00a4b000)

 

 

может я чего в файлах конфигурации перепутал...

 

фаерберд:

<StoreModule store_firebird>

server = 192.168.хххх

database = /хххххх.gdb

user = SYSDBA

password = хххххххххх

</StoreModule>

 

файлы:

<StoreModule store_files>

WorkDir = /var/stargazer

[madf 279]

Эммм... Кажется допер.

Вот это:

libstg_common.so => //usr/lib/stg/libstg_common.so (0x008e2000)

- причина молчания. Я так понимаю, это либа от установленного и скомпиленного старгейзера с отключенным DEBUG-режимом?

Соответственно, она "говорить" не умеет. Конвертор запускается из каталога сборки или еще откуда?

Если я прав - это легко фиксится.

[Ork Yason 8]

да

 

мне включить дебаг режим и откомпилить конвертер заново?

[madf 279]

Дело в том, что конвертор по умолчанию собирается в 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)

 

После такого компоновщик уже не выкрутится