Drool

Если есть возможность пересобрать - пересобери с дебагом - в спеке ./build заменить на ./build debug Запусти его не через инти-скрипт, а сам бинарник и перенаправь вывод в файл stargazer.bin &> /stg.debug.log Логи потом запости или сюда, или в основную ветку разработки Если нет возможности пересобрать - я щяс выложу пересобранную с дебагом

Это уже радует! :00: Тогда ждем релиза и я пакую его. Если в течении месяца не будет критичных боков - рискну закинуть в репозиторий. А там уже можно будет подчищать и шлифовать, типа неудаляющиеся папки и просую мелочь.

Брат, это ты погорячился - я тебе честно говорю. Я много лет юзаю stg - ставил его и на ALM2.4 в том числе. Нормально он себя там чувстовал. Нафига было что-то менять? Вот после таких мантейнеров я и не буду использовать подобные сборки. Ну, брат, каждый волен в своей системе делать как ему больше нравится. А вот если паковать софт в официальном виде в дистрибутив - нужно соответствовать установленному полиси. В альте - так. А для себя - да как душе угодно. Но если я хочу видеть старгайзер в коробке на диске - я обязан следовать стандарту.

И как себя чувствует сборка? :rrr:

Я старался добиться чтоб файлы в /usr/share/stargazer при _обновлении_ не удалялись, возможно неудаление /usr/share/stargazer вылезло из этого. Попробуй сделать именно обновление/реинсталляцию. Если файлы улетят - свисни, буду курить дальше. А если будет помощь в плане совершенствования секции ======================================= %files %_sbindir/* %dir %_initdir/%name %dir %_sysconfdir/%name %dir %_datadir/%name %config(noreplace,missingok) %_initdir/%name %config(noreplace,missingok) %_sysconfdir/%name/* %config(noreplace,missingok) %_datadir/%name/tariffs/* %config(noreplace,mi

http://fly.osdn.org.ua/~drool/stargazer/ Выложил. Относительно падения - я же говорил, что сборка девелоперская. Ее сейчас активно насилуют. Но и гарантии что это не мои кривые ручки при сборке дать не могу :-) В моей сборке все данные перемещены из /var/stargazer в /usr/share/stargazer, там где обычно лежат в альте такие вещи. Так что нужно будет это учесть в конфиге. Кроме того, в конфиге нужно будет подправить путь в модулям - /usr/lib64, если у тебя x86_64

Да, когда я добрался проверить его в 64-битном хашере - получил то же самое. После общения с духами в онлайне (спасибо Legion-у) проблема была решена. Через часок-другой на http://fly.osdn.org.ua/~drool/stargazer/ выложу stargazer-2.4-alt0.2007.12.21.M40.2 с исправлением

http://fly.osdn.org.ua/~drool/stargazer/ Выложена сборка старгайзера от 2007.12.21 под ALT Linux 4.0, за что отдельное спасибо Madf-у ;-) Наконец-то мне удалось собрать его под x86_64. Но тестить мне не на чем. Так что если у кого есть возможность проверить эту сборку под нагрузкой и на x86_64 - будет просто отлично! Прошу учесть что сборка девелоперская :halloween:

http://fly.osdn.org.ua/~drool/stargazer/ Выложена сборка старгайзера от 2007.12.21 под ALT Linux 4.0, за что отдельное спасибо Madf-у ;-) Наконец-то мне удалось собрать его под x86_64. Но тестить мне не на чем. Так что если у кого есть возможность проверить эту сборку под нагрузкой и на x86_64 - будет просто отлично!

stg-2.4-2007.10.28-22.18.50 gentoo: stage3-amd64-2007.0 - чистая установка, биарч=multilib? стоит (/lib32 не пустая), в ядре поддержка есть (IA32 Emulation, IA32 a.out support). Вот тут и порылась собака :argh: В ALT Linux нет биарча. Это облегчает систему, уменьшает объем и снижает возможные нестыковки/глюки на переходе двух архитектур. Но вызывает иногда вот такие вот проблемы со сборкой. Вроде собираются сделать биарч, но, имхо, это затыкать дырки тряпочками вместо нормально законопатить. Лучше код подправить.

Может потому и не собирается для 64? :-) К сожалению имею доступ к сборочному роботу на x86_64 только под ALT Linux. У кого-то есть возможность проверить? Gentoo Linux localhost 2.6.22-gentoo-r8 #1 SMP Thu Nov 8 18:40:06 x86_64 AMD Athlon™ 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux Собралось и поставилось без ошибок. Работу буду тестить... пока в не боевовом режиме... В системе присутствует биарч? Или чистый x86_64? Это важно. И какой снапшот старгайзера?

Нужен более точный вывод лога сборки

Старшие товарищи на альтовском irc сделали вот такой финт ушами перед сборкой: find -name 'Makefile*' -print0 | xargs -r0 -- sed -i 's@-rpath.*@-rpath,%_libdir/%realname -Wl,-rpath-link,'`pwd`'/lib@' И заметили, что применение -rpath-link сильно облегчит "чтоб ld находил либы" Чуть не забыл: ========================================================= [22:25:44] <Lost> |Drool|: и еще расскажи что за запуска сервера из дерева сборки можно использовать LD_LIBRARY_PATH, а не вписывать rpath [22:26:01] <Lost> и еще расскажи что при такой схеме при установке не надо будет произ

Брр.. У меня лыжи не едут... 7 и 8 строки скрипта build совсем не похожи на нужные :-) Может в районе 57? Там, где определяется CFLAGS? P.S. Кстати, по сборочным зависимостям вылез не только gcc, но и gcc++. А определения ключа CXXFLAGS я не нашел.

Да это мои кривые попытки ввести оптимизацию под архитектуру процессора. Существующая на данный момент система сборки не реагирует на это дело, и собранный rpm-пакет с ключем --target (например --target athlon) даст на выходе bla-bla.athlon.rpm, но это будет ложно, так как бинарники собирались без -march=athlon -mtune=athlon. Мне нужно только понять куда именно вставить переменную, передающую в CFLAGS ключи оптимизации под конкретную архитектуру. То, куда и как подставляю сейчас я дает это дело во все выражения g++, мне так кажется...

Все! Сам дурак! Это CFLAGS="%optflags" подменяет это дело. Значит нужно именно CFLAGS="%optflags -fPIC"

Кстати, я заметил отсутствие -fPIC, о которых когда-то мне поясняли что оно и зачем. Я их добавляю в спеке при сборке таким образом: subst 's|gmake|gmake CFLAGS="%optflags -fPIC"|g' ./build Получается вроде такого: g++ -c admin.cpp -pipe -Wall -O2 -march=i686 -mtune=i686 -fPIC Или не нужно? Что с ним, что без - "RPATH entry contains" сыпятся щедро, только без -fPIC еще наблюдаю такое: /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object.

Такое чаще бздяшники практикуют... Я лично сразу делаю rpm-пакет - проще управлять/удалять/обновлять.

А откуда десятки "RPATH entry contains" ?

А баба Яга против ;-) Не все так просто: http://fly.osdn.org.ua/~drool/stargazer/stg-build.log

Для сборки под платформу 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 -lo

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

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

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 бит возможна. Ы? :-|<

Нужно еще не забывать, что в x86_64 либы лежат не в /usr/lib а в /usr/lib64. Нужно вставлять какой-то механизм проверки. В rpm-based дистрибутивах встречается переменная %_lib которая равна либо /lib либо /lib64. А вот как сделать не на rpm-based - не знаю. Но как-то делают.