да уж проект h323 в * напроч превратили в каку. Если у меня еще v1.107 худо бедно работала (кривенько-кривенько) то с версии 1.111 уже ек. А жаль.
Я уже бросил ковыряться с h323 времени жалко
поправил кое что ручками - так в другом месте отвалилось

Всем добрый день.
раньше (в 1.0.7 stable) у меня хотя бы собирался и рузился (но не работал) модуль chan_h323.so.
Вчера собрал из CVS (20050606). Теперь он собирается, но не грузится. Вылазят C++'ные наименования функций типа: _ZN12PAsteriskLog6Buffer8overflowEi

Я C++ совсем не знаю. Никак не могу избавится от этих name mangle в сите C++. ;(

При этом в коде присутствует extern "C"!

Что делать?

Заранее сенкс!

если вылетает подобное сообщение _ZN12PAsteriskLog6Buffer8overflowEi
то это скорее всего не может прилинковаться или библиотека openh323.so или pwlib.so тоесть простыми словами в библиотеке нет (_ZN12PAsteriskLog6Buffer8overflowEi ).
Причин сему может быть несколько :
1. не правильно собраны библиотеки, не на том компе
2. в системе уже есть подобные библиотеки (найти и вычистить потом с центра поля)
Поиск простой : заходиш в библиотеку (желательно чтобы библиотека была не striped, если же она всетаки стрипнута то тебе подойдет файл с .a на конце в том же каталоге) по F3 в MC в строке поиска набираеш
на что ругается h323 только точно до последней буквы и смотриш есть или нет .
скорее всего нет, далее выносиш все библиотеки которые туда накачал до этого и береш исходники те которые рекомендует данная версия h323 , пересобираеш их и кладеш в /usr/lib ну или линки далее ldconfig и пересобираеш h323 если будет ругаться то все действия с пункта 1

Что-то мне кажется, что в библиотеках этих не может быть никакого упоминания об _ZN12PAsteriskLog6Buffer8overflowEi -- тут же написано: 'AsteriskLog'...
Это выходит еще до линковки с openh323 и pwlib -- на этапе сборки libchanh323.a.

Собираю так:
g++ -g -c -o ast_h323.o -I/usr/include/ptlib -I/usr/include/openh323 -DPBYTE_ORDER=PLITTLE_ENDIAN -I../../include -DNDEBUG -DDO_CRASH -DDEBUG_THREADS -DP_LINUX -O -pipe -Wall -fPIC -D_REENTRANT -D_GNU_SOURCE -DP_HAS_SEMAPHORES -DP_SSL -DP_PTHREADS -DPHAS_TEMPLATES -DPTRACING -DP_USE_PRAGMA ast_h323.cpp
ast_h323.cpp:1:1: warning: "_GNU_SOURCE" redefined
<command line>:8:1: warning: this is the location of the previous definition
ar cr libchanh323.a ast_h323.o

Потом смотрю strings libchanh323.a | grep _Z
и получаю с десяток экранов этих функций. ;(

openh323 и pwlib в системе _одни_.
Версии:
openh323-1.17.1
pwlib-1.9.1

Раньше такая проблема была с OH323. Поэтому я его так и не собрал, а теперь эта проблема попала и в CVS-HEAD. ;(

Специально собираю поэтапно, чтобы выявить ошибку...

Насколько я понял, g++ преобразовывает вот эту PAsteriskLog:
ast_h323.cpp:class PAsteriskLog : public PObject, public iostream
в _ZN12PAsteriskLog6Buffer8overflowEi, т.е. в виртуальную функцию. Вот она так и остается. ;(
Далее, как я понимаю, для "сопряжения" с C нужно описывать их в 'extern "C"'. Или я совсем поехал не в ту степь? ;(

Забыл добавить: когда я strip'нул libchanh323.a и ast_h323.o, то эти _ZN12PAsteriskLog6Buffer8overflowEi удалились. Точнее они остались, но asterisk при загрузке ругается уже не на них.

НО (!) после этотого он начинается ругаться на отсутствие функций h323_show_codec, к примеру. Она описана в chan_h323.h внутри 'extern "C"'. Т.е. такое впечатление, что удаляется виртуальная функция (я правильно их обзываю?), которая указывала на h323_show_codec.

Ура, заработало несмотря на эти _ZN12PAsteriskLog6Buffer8overflowEi. Стоило только правильно собрать. 8)

;) а какое будет разочарование когда этот oh323 будет МЕГА КРИВО работать с твоим железом.
я к примеру чтобы у меня правильно заработало собрал примерно 50 вариантов
тоесть oh323 v 1.7 , oh323 v 1.6 oh323 v 1.7.1
oh323 v 1.7.2 + естественно все либы 1.13 , 1.15 , 1.17 , 1.19 + 1.3 , 1.5 , 1.7 , 1.9
+ три комбинации фирмвари в железе . Тоесть получиш уйму вариантов пока хотябы на 1/3 заработает.

Не знаю какое железо на другом конце, но у меня все заработало. ;)

P.S. Только у меня не OH323, а H323 из * ( CVS 2005-06-08 )