bug-gift
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-GIFT] Several patches for 0.1.8


From: Tim TimeWaster
Subject: [bug-GIFT] Several patches for 0.1.8
Date: Mon, 22 Jul 2002 18:59:25 +0200
User-agent: Mutt/1.5.1i

Hello,

I was trying to compile Gift on FreeBSD, and of course it did not compile
out of the box. Here's what I found:

First of all, getopt on FreeBSD is not GNU getopt. Most FreeBSD ports solve
this by including the files getopt.c, getopt.h and getopt1.c in the source
tar ball. A portable program should have these. I made the following quick
patch, but it should be integrated with Automake:


--- libMRML/cc/Makefile.in.orig Sat Mar  2 14:05:48 2002
+++ libMRML/cc/Makefile.in      Tue Jun 18 16:33:19 2002
@@ -175,7 +175,7 @@
 bin_PROGRAMS =  libMRML-config$(EXEEXT)
 PROGRAMS =  $(bin_PROGRAMS)
 
-libMRML_config_OBJECTS =  libMRML-config.$(OBJEXT)
+libMRML_config_OBJECTS =  libMRML-config.$(OBJEXT) getopt.$(OBJEXT) 
getopt1.$(OBJEXT)
 libMRML_config_LDADD = $(LDADD)
 libMRML_config_DEPENDENCIES = 
 libMRML_config_LDFLAGS = 
@@ -186,13 +186,16 @@
 CXXLINK = $(LIBTOOL) --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) 
$(LDFLAGS) -o $@
 DIST_COMMON =  Makefile.am Makefile.in
 
+CFLAGS = @CFLAGS@
+COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) 
$(CFLAGS)
+
 
 DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
 
 TAR = tar
 GZIP_ENV = --best
-SOURCES = $(libMRML_la_SOURCES) $(libMRML_config_SOURCES)
-OBJECTS = $(libMRML_la_OBJECTS) $(libMRML_config_OBJECTS)
+SOURCES = $(libMRML_la_SOURCES) $(libMRML_config_SOURCES) getopt.c getopt1.c
+OBJECTS = $(libMRML_la_OBJECTS) $(libMRML_config_OBJECTS) getopt.o getopt1.o
 
 all: all-redirect
 .SUFFIXES:
@@ -957,7 +960,9 @@
        ../../libMRML/include/uses-declarations.h
 GIFTExceptions.lo GIFTExceptions.o : GIFTExceptions.cc \
        ../../libMRML/include/GIFTExceptions.h
-libMRML-config.o: libMRML-config.cc
+libMRML-config.o: libMRML-config.cc getopt.c getopt1.c
+getopt.o: getopt.c getopt.h
+getopt1.o: getopt1.c getopt.h
 mrml_const.lo mrml_const.o : mrml_const.cc \
        ../../libMRML/include/mrml_const.h
 safePopen.lo safePopen.o : safePopen.cc \




Second, dl_error returns a const char *, instead of a char *. The following
two patches will solve this:

--- libMRML/cc/CAFPlugin.cc.orig        Tue Jun 11 16:35:27 2002
+++ libMRML/cc/CAFPlugin.cc     Tue Jun 11 16:35:41 2002
@@ -20,7 +20,7 @@
   mName("no name given"),
   mIsSane(0){
   
-  char* lError;
+  const char* lError;
   string lLibraryPath=inLibraryDirName+"/"+inLibraryFileName;
   string 
lStringGetClassName(inLibraryFileName.substr(0,inLibraryFileName.size()-3)+"_getClassName");
   string 
lStringMakeAccessor(inLibraryFileName.substr(0,inLibraryFileName.size()-3)+"_makeAccessor");

--- libMRML/cc/CQueryPlugin.cc.orig     Tue Jun 11 16:36:47 2002
+++ libMRML/cc/CQueryPlugin.cc  Tue Jun 11 16:37:13 2002
@@ -43,7 +43,7 @@
   mName("no name given"),
   mIsSane(0){
 
-  char* lError;
+  const char* lError;
   string lLibraryPath=inLibraryDirName+"/"+inLibraryFileName;
   string 
lStringGetClassName(inLibraryFileName.substr(0,inLibraryFileName.size()-3)+"_getClassName");
   string 
lStringMakeQuery(inLibraryFileName.substr(0,inLibraryFileName.size()-3)+"_makeQuery");


The there was a problem with networking, a header file was missing:

--- GIFTServer/CTCPSocket.h.orig        Tue Jun 18 16:45:17 2002
+++ GIFTServer/CTCPSocket.h     Tue Jun 18 16:51:40 2002
@@ -38,6 +38,7 @@
 //to be more specific: internet sockets
 #include <arpa/inet.h>
 #include <netinet/tcp.h>
+#include <netinet/in.h>
 
 #include <string>
 #include <assert.h>


Furthermore, if you want to check for pthreads on FreeBSD, the current check
in the configure script does not work. This is because on Linux, the -lpthread
is used to compile and link, while on BSD, the -pthread option is used (pthread
on FreeBSD is implemented in libc_r, which is linked by default). There is a
check available in the Autoconf macro archive that does this correctly.


I also have a compiled version on Linux, and I have written some GTK front-ends
in Python to connect to a MRML server, and one front-end to organize
collections.
In the latter, I had to use some utilities which were shipped with gift, but
unfortunately they segfaulted with a core dump. I had a quick look and found
a problem in FeatureExtraction/extract_block_features.c. Here, a picture is
traversed, but there are cases where values outside of the buffer are
inspected. I added a quick fix, but it would be better to write the loop
correctly from scratch:

--- FeatureExtraction/extract_block_features.c.orig     Sun Jul 21 14:59:58 2002
+++ FeatureExtraction/extract_block_features.c  Sun Jul 21 15:02:36 2002
@@ -141,8 +141,8 @@
                        for (y = 0; y < im_hsv->height; y += gabor_block_size) {
                        for (x = 0; x < im_hsv->width; x += gabor_block_size) {
                                gabor_mean = 0;
-                               for (i = 0; i < gabor_block_size; i++) {
-                               for (j = 0; j < gabor_block_size; j++) {
+                               for (i = 0; (i < gabor_block_size) && (y+i < 
im_hsv->height); i++) {
+                               for (j = 0; (j < gabor_block_size) && (x+j < 
im_hsv->width); j++) {
                                        gabor_mean += square((filtered_image[(y 
+ i)*im_hsv->width + (x + j)]));
                                }
                                }
@@ -204,8 +204,8 @@
                for (n = 0; n < colmap_size; n++) {
                        col_counts[k][n] = 0;   
                }
-               for (i = 0; i < block_size; i++) {
-               for (j = 0; j < block_size; j++) {
+               for (i = 0; (i < block_size) && (y+i < im->height); i++) {
+               for (j = 0; (j < block_size) && (x+j < im->width); j++) {
                        colour = im->pixel[(y + j)*im->width + (x + i)];
                        col_counts[k][colour]++;
                }



This was not the only crash, in gift-generate-inverted-file there was another
core dump, which was less obvious. A null-pointer was dereferenced in one of
the operators. Since the code that causes the core dump is only to verify if
everything went OK, I simply disabled it:

--- GIFTServer/generateInvertedFile.cc.orig     Sun Jul 21 22:28:38 2002
+++ GIFTServer/generateInvertedFile.cc  Sun Jul 21 22:29:54 2002
@@ -72,6 +72,8 @@
 
     CAcIFFileSystem lAccessor(lElement);
     
+#if 0
+       /* This causes a core dump... */
     if(lAccessor){
       cout << "GENERATED inverted file" 
           << endl
@@ -80,6 +82,7 @@
     }else{
       cout << "ERROR in generating inverted file";
     }
+#endif
   }else{
     
     cout << "USAGE: "


Hopefully some of these patches are useful to improve the program.

Tim


-- 
Zen Microsystems: we're the om in .commmmmmmmm...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]