Re: Gnumeric 1.1.14

[Etsushi Kato <ekato ees hokudai ac jp>]

On 2002.12.30, at 01:44  PM, Jody Goldberg wrote:

> On Mon, Dec 30, 2002 at 12:59:13PM +0900, Etsushi Kato wrote:
> > First gnumeric cannot compile with -D_POSIX_SOURCE on Mac OS X, so I
> > deleted -Werror from configure script when checking -D_POSIX_SOURCE.
>
> I don't understand.  The -Werror is only for the test to see if
> -D_POSIX_SOURCE is necessary.

According to config.log,

configure:9863: checking whether -D_POSIX_SOURCE is needed for fdopen
configure:9884: gcc -c -g -O2 -Wall -Wunused -Wmissing-prototypes 
-Wmissing-declarations  -Wsign-promo -Wsign-compare -Wpointer-arith 
-Wnested-externs -Wchar-subscripts -Wwrite-strings -Werror  conftest.c 
>&5
cc1: warnings being treated as errors
configure: In function `main':
configure:9892: warning: unused variable `f'
configure:9887: $? = 1
configure: failed program was:
| #line 9867 "configure"
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "gnumeric"
| #define PACKAGE_TARNAME "gnumeric"
| #define PACKAGE_VERSION "1.1.14"
| #define PACKAGE_STRING "gnumeric 1.1.14"
| #define PACKAGE_BUGREPORT 
"http://bugzilla.gnome.org/enter_bug.cgi?product=gnu
meric"
| #define PACKAGE "gnumeric"
| #define VERSION "1.1.14"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define STDC_HEADERS 1
| /* end confdefs.h.  */
| #include <stdio.h>
| int
| main ()
| {
| FILE *f = fdopen(1, "r")
|   ;
|   return 0;
| }
configure:9904: result: yes

So, I deleted -Werror.  If -D_POSIX_SOURCE is there, many undefined 
type and parse error come up.  Here is a example of 
dialog-autocorrect.c.

gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-DGNOMELOCALEDIR=\""/sw/share/locale"\"    
-DGNUMERIC_DATADIR=\""/sw/share/gnumeric/1.1.14"\"                      
        -I../..                                                         
 -I../../src    -I../../src/tools                                       
         -I../../src/cut-n-paste-code/foocanvas                         
 -DORBIT2=1 -D_REENTRANT -I/sw/include/glib-2.0 
-I/sw/lib/glib-2.0/include -I/sw/include/libgsf-1 -I/sw/include/libxml2 
-I/sw/include -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include 
-I/sw/include/atk-1.0 -I/sw/include/pango-1.0 -I/usr/X11R6/include 
-I/sw/include/freetype2 -I/sw/include/libglade-2.0 
-I/sw/include/libgnomecanvas-2.0 -I/sw/include/libart-2.0 
-I/sw/include/gal-2-0 -I/sw/include/libgnomeprint-2.0 
-I/sw/include/libbonobo-2.0 -I/sw/include/orbit-2.0 
-I/sw/include/bonobo-activation-2.0 -I/sw/include/linc-1.0 
-I/sw/include/libgnome-2.0 -I/sw/include/gconf/2 
-I/sw/include/gnome-vfs-2.0 -I/sw/lib/gnome-vfs-2.0/include 
-I/sw/include/libgnomeui-2.0 -I/sw/include/libbonoboui-2.0 
-I/sw/include/libgnomeprintui-2.0      -g -O2 -Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations  -Wsign-promo 
-Wsign-compare -Wpointer-arith -Wnested-externs -Wchar-subscripts 
-Wwrite-strings -D_POSIX_SOURCE -D__EXTENSIONS__ -D_BSD_SOURCE -c 
dialog-autocorrect.c
/usr/include/sys/socket.h:77: undefined type, found `u_char'
/usr/include/sys/socket.h:212: undefined type, found `u_char'
/usr/include/sys/socket.h:213: undefined type, found `u_char'
/usr/include/sys/socket.h:223: undefined type, found `u_short'
/usr/include/sys/socket.h:224: undefined type, found `u_short'
/usr/include/sys/socket.h:237: undefined type, found `u_char'
/usr/include/sys/socket.h:373: undefined type, found `u_int'
/usr/include/sys/socket.h:375: undefined type, found `u_int'
/usr/include/sys/socket.h:377: undefined type, found `u_int'
/usr/include/sys/socket.h:406: undefined type, found `u_int'
/usr/include/sys/socket.h:469: undefined type, found `u_short'
...

> > Second, python-loader plugin cannot compile because of multiple
> > definitions of symbol _py_Boolean_object_type and so on.
> sounds dicey.  Ignore the python plugin for now.

I see.

> > Third, segfault occurred when saving file as Excel format on Mac OS X.
> > I found two glitches.  One is that p != NULL check is needed for
> > excel_write_string_len().
> Hmm, I'll add the sanity check, but NULL should never arrive there.

Not sure.  It only occurs on Mac OS X.  Without NULL check, gdb shows 
like that.

Program received signal EXC_BAD_ACCESS, Could not access memory.
excel_write_string_len (str=0x0, bytes=0xbfffe920) at 
ms-excel-write.c:92
92                      for (; *p ; i++)
(gdb) where
#0  excel_write_string_len (str=0x0, bytes=0xbfffe920) at 
ms-excel-write.c:92
#1  0x02c12608 in excel_write_string (bp=0x2b23700, txt=0x0, 
flags=STR_TWO_BYTE_LENGTH) at ms-excel-write.c:114
#2  0x02c19bc0 in excel_write_WRITEACCESS (bp=0x2b23700) at 
ms-excel-write.c:3857
#3  0x02c19dfc in write_workbook (ewb=0x2b1d770) at 
ms-excel-write.c:3922
...

> > The other is, because Mac OS X with Fink
> > uses libiconv,  it is needed to use "UTF-16LE" for g_iconv_open in
> > ms_biff_put_new() on ms-biff.c.  It seems "UTF16LE" is not assigned as
> > alias of "UTF-16LE" on libiconv.
> glibc has UTF-16LE as the primary name too.  I'll switch.

Thank you.

> > With these modifications, I enjoyed gnumeric very much on Mac OS X.  I
> > can read and write Japanse Excel file.  Also Japanese XIM works fine.
> Lovely.
>
> I could actually use a few more test cases of japanese XLS files.
> I'd like to validate
>     - autofilters
>     - input messages
>     - data validation
>
> If you have some time I'll post the details.

I would like to :)

Thanks,