[Kamailio-Users] kam 1.5 syslog on solaris 10

[Robert McGilvray]

-----Original Message-----
From: Daniel-Constantin Mierla [mailto:miconda at gmail.com] 
Sent: Wednesday, October 28, 2009 5:41 AM
To: Robert McGilvray
Cc: Henning Westerholt; users at lists.kamailio.org
Subject: Re: [Kamailio-Users] kam 1.5 syslog on solaris 10



On 28.10.2009 9:51 Uhr, Henning Westerholt wrote:
> On Mittwoch, 28. Oktober 2009, Robert McGilvray wrote:
> > so it is working with 1.3 but not with 1.5, right? IIRC, some
changes
> > were added when introducing async logging and running under
daemontools.
> >
> > The log you pasted at the end is what you get not in syslog file?
> >
> > Cheers,
> > Daniel
> >
> > --
> >
> >
> > Right - works with 1.3 but not 1.5.2 The log at the bottom actually
does
> > show up in syslog but that's the last I ever see if I set fork=yes.
If I
> > set fork=no (with log_stderror=no) then everything shows up as
expected.
> >
> >
> > On 1.3 and with fork=no on 1.5 I see a bunch of open file entries
for
> > xlog pointing at my log device that aren't there when it daemonizes.
> > Example:
> >
> > openser 23192 openser txt VREG 85,3 55156 104971
> > /usr/local/openser-1.3.2/lib64/openser/modules/xlog.so
> > openser 23192 openser 3w VCHR 21,3289 11010052
> > /devices/pseudo/log at 0:conslog->LOG
> >
> > I was looking at the commits earlier and noticed the changes you're
> > talking about. There was some work done moving the openlog() stuff
from
> > daemonize.c to main.c - looks like some kind of solaris bug was
> > introduced in one of them.
>
>
> Hello Robert,
>
>
> with regards to the async logging, its not enabled by default, so i 
> guess the changes you talking about are guilty.

this is the commit mentioned:
http://openser.svn.sourceforge.net/viewvc/openser?view=rev&revision=5142

and seems to be the last one to these files. Robert, can you get and 
test revision before this commit (probably works to get just the three 
files and copy them in your source tree)? Would help to identify if this

is the problem since I have no solaris 10.

Thanks,
Daniel

--

I wasn't able to compile by just switching out the three files, there
were unresolved symbols related to pv_free_extra_list();. I finally got
around the firewalls here to checkout revision 5141 but it won't
compile. The file it bails on is exactly the same as in 1.5.2 release so
I'm not sure why.

Compiling db/db_ut.c
/usr/sfw/bin/gcc  -g -O9 -funroll-loops   -Wall  -mcpu=ultrasparc
-mtune=ultrasparc      -DNAME='"kamailio"' -DVERSION='"1.5.0-dev9-tls"'
-DARCH='"sparc64"' -DOS='"solaris"' -DCOMPILER='"/usr/sfw/bin/gcc
3.4.3"' -D__CPU_sparc64 -D__OS_solaris -D__SMP_no
-DCFG_DIR='"/usr/local/kamailio-1.5.2/etc/kamailio/"' -DPKG_MALLOC
-DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE
-DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC
-DSVNREVISION='"2:5141"'  -DUSE_TLS -DFAST_LOCK -DADAPTIVE_WAIT
-DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H
-DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION
-D_POSIX_PTHREAD_SEMANTICS -DHAVE_DEVPOLL -DHAVE_SELECT -I/ssl/include
-I/include -I/usr/include/openssl -c db/db_ut.c -o db/db_ut.o

In file included from db/db_ut.c:41:
/usr/include/stdlib.h:144: error: conflicting types for 'swab'
/usr/include/unistd.h:496: error: previous declaration of 'swab' was
here
/usr/include/stdlib.h:144: error: conflicting types for 'swab'
/usr/include/unistd.h:496: error: previous declaration of 'swab' was
here
db/db_ut.c: In function `db_str2longlong':
db/db_ut.c:75: warning: implicit declaration of function `strtoll'
db/db_ut.c: In function `db_int2str':
db/db_ut.c:114: warning: implicit declaration of function `snprintf'
gmake: *** [db/db_ut.o] Error 1

Unrelated question - I've tried changing the tuning options specified in
Makefile.defs to use the proper cpu arch and kept with -m32 since it has
to link against 32 bit libaries but even with that it builds the object
files as 64 bit. It then fails when linking kamailio. What's the proper
way to optimize the binary but keep all aspects of it 32? I tried

-mcpu=ultrasparc3 -m32 -threads -Wa,-xarch=v9b

It's an UltraSPARC-IIIi chip. 

ykt1sipprd2# ls -1 *.o | xargs -n1 file
action.o:       ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
blacklists.o:   ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
cfg.tab.o:      ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
cmpapi.o:       ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
core_stats.o:   ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
crc.o:          ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
daemonize.o:    ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
data_lump.o:    ELF 64-bit MSB relocatable SPARCV9 Version 1,
UltraSPARC3 Extensions Required
<snip>

Thanks!

Bob


--------------------------------------------------------------------------
This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.