Dear list,

After looking at it on or off I was able to find out the culprit:

In the Makefile of the cvs snapshot:

CC = gcc -std=gnu99

This causes the cvs build on Solaris to crash. CC = gcc in the gateway-1.4.1 
Makefile.

Can someone tell me why this changed in the first place? Is it required for the 
build?
I have made a patch in configure for Solaris and added also -liconv in the 
standard libs.

How do I submit it?

BR,
Nikos
  ----- Original Message ----- 
  From: Nikos Balkanas 
  To: [email protected] 
  Sent: Tuesday, October 28, 2008 10:49 PM
  Subject: Re: Problem with CVS source


  Hi,

  After looking at it a bit longer, I think I need some help with it. In 
Solaris 10.5 the cvs is broken. The build failes in wmlscript/wlexer.c (1037):

  if (*result == *HUGE_VAL || *result == -(*HUGE_VAL)>.>..>..// NIKOS!!
          || ws_ieee754_encode_single(*result, buf) != WS_IEEE754_OK)
          ws_src_error(compiler, 0, "floating point literal too large");

  Are these lines really important? We are talking for a 64bit build here (of 
course the same lines will affect 32bit builds as well). HUGE_VAL is undefined 
in the CVS version:

  Undefined                       first referenced
   symbol                             in file
  __builtin_huge_val                  libwmlscript.a(wslexer.o)
  ld: fatal: Symbol referencing errors. No output written to wmlscript/wmlsc

  This is after I commented out the relevant code in wslexer.c and filled in 
for a simple printf. Of interest is that in the CVS version HUGE_VAL is a 
undefined pointer, whereas in the 1.4.1 version it is a float(correct).

  Source, includes and dependencies are exactly the same:

  gateway-1.4.1/.depend:
  wmlscript/wslexer.o: wmlscript/wslexer.c wmlscript/wsint.h ./gw-config.h \
    ./gwlib/gwassert.h ./gwlib/log.h wmlscript/ws.h wmlscript/wsutf8.h \
    wmlscript/wserror.h wmlscript/wsieee754.h wmlscript/wsbuffer.h \
    wmlscript/wsencode.h wmlscript/wsalloc.h wmlscript/wsfalloc.h \
    wmlscript/wsstream.h wmlscript/wshash.h wmlscript/wsbc.h \
    wmlscript/wsstree.h wmlscript/wsasm.h wmlscript/wsopt.h \
    wmlscript/wsstdlib.h wmlscript/wsgram.h

  CVS/.depend:
  wmlscript/wslexer.o wmlscript/wslexer.i: wmlscript/wslexer.c \
    wmlscript/wsint.h ./gw-config.h ./gwlib/gwassert.h ./gwlib/log.h \
    wmlscript/ws.h wmlscript/wsutf8.h wmlscript/wserror.h \
    wmlscript/wsieee754.h wmlscript/wsbuffer.h wmlscript/wsencode.h \
    wmlscript/wsalloc.h wmlscript/wsfalloc.h wmlscript/wsstream.h \
    wmlscript/wshash.h wmlscript/wsbc.h wmlscript/wsstree.h \
    wmlscript/wsasm.h wmlscript/wsopt.h wmlscript/wsstdlib.h \
    wmlscript/wsgram.h

  Where is wmlscript invoked? I have some issues right now with the client, so 
I cannot run a debugger on it.

  Any help would be appreciated.

  Thanks,
  Nikos


    ----- Original Message ----- 
    From: Nikos Balkanas 
    To: Stipe Tolj 
    Cc: [email protected] 
    Sent: Monday, October 27, 2008 9:43 PM
    Subject: Re: Problem with CVS source


    Dear Stipe,

    It seems that the problem is not what I first suspected. You see the file 
wslexer.c is exactly the same in both cases (gateway-1.4.1 and cvs gateway). 
Therefore it is not a HUGE_VAL problem I first suspected. 

    This is strange. I am using exactly the same environment, gcc, 
configuration as with the gateway-1.4.1 version. Yet make fails on exactly the 
same file. I will have to look more into it. Meanwhile if you have seen this 
before, pls let me know. 


    Nikos
    On Mon, Oct 27, 2008 at 9:26 PM, Nikos Balkanas <[EMAIL PROTECTED]> wrote:

      Thanks, Stipe, for the fast reply. Please see my comments inlined.


      Regards,

      Nikos



      On Mon, Oct 27, 2008 at 8:10 PM, Stipe Tolj <[EMAIL PROTECTED]> wrote:

        Nikos Balkanas schrieb:

        > Hi,
        >
        > I am rather new to the list. I tried to download and compile the 
latest
        > CVS source and I got the following error:
        >
        > gcc -std=gnu99 -D_REENTRANT=1 -I. -Igw -O6 -s -m64 -D_LARGE_FILES=
        > -I/usr/include/libxml2 -I/usr/local/include -Wall -Wmissing-prototypes
        > -Wmissing-declarations -Wnested-externs -Winline -Wformat
        > -Wformat-security -Wmissing-format-attribute -Wall
        > -I/usr/local/ssl/include -o wmlscript/wslexer.o -c wmlscript/wslexer.c
        > wmlscript/wslexer.c:222: warning: no previous prototype for 
'ws_yy_lex'
        > wmlscript/wslexer.c: In function `read_float_from_exp':
        > wmlscript/wslexer.c:1037: error: invalid operands to binary ==
        > wmlscript/wslexer.c:1038: error: wrong type argument to unary minus
        > make: *** [wmlscript/wslexer.o] Error 1


        there is something wrong with your local CVS checkout tree. Make sure 
you

         $ make clean
         $ make

      To be sure I rm -rf gateway and restored from CVS again.

        in order to remove any previously build objects. The configure run was 
clean?

      Yes. Apart from docbook support which I don't particular care (This is a 
minimal server for security/performance reasons)
       CFLAGS="-O6 -s -m64 -DSunOS" CPPFLAGS="-I/usr/local/ssl/include" 
configure --build=ia64-pc-solaris2.10 --libdir=/usr/local/lib/64 --enable-ssl 
--enable-cookies --enable-debug --enable-warnings --enable-docs 
--mandir=/usr/local/man --with-ssl=/usr/local/ssl --enable-pcre


      gateway-1.4.1 compiled with the same configuration with no problems.
      The issue seems to be with HUGE_VAL and Solaris. I don't have a linux in 
front of me to check, but in solaris 10.5 in /usr/include/iso/math_iso.h:
      #define HUGE_VAL __huge_val._d
        > Any ideas? How safe is it to use cvs source in production? By the 
looks
        > of it, it doesn't look tested.


        it is... in fact the CVS HEAD branch is a 1.4.2RC and is the most 
stable version
        you can get. We tend to be very "pessimistic" with commits and tend to 
be very
        careful to preserve the CVS HEAD quality.

        A lot of companies use either pure CVS HEAD or a patched CVS HEAD 
branch in
        production.
      Good to know. Thanx.


        > Another minor request: Daily snapshots do not have any indication of 
the
        > date. This could lead to an invalid snapshot if crontab or the server
        > goes down at the time of the snapshot.


        ???

      In the web download site, under daily development downloads. The sources 
tarball could have a day stamp in the name. I use a minimal server without cvs. 
I downloaded the daily snapshot and couldn't figure out when it was built. The 
last date in RELEASES was back in 2004. I installed CVS and got the tree, just 
to be sure.
        Stipe

        --
        -------------------------------------------------------------------
        Kφlner Landstrasse 419
        40589 Dόsseldorf, NRW, Germany

        tolj.org system architecture      Kannel Software Foundation (KSF)
        http://www.tolj.org/              http://www.kannel.org/

        mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
        -------------------------------------------------------------------




Reply via email to