Windows build with Visual Studio 2005 - some success

Hi all,

first up, big thanks to Dave for doing the hard work of porting
Lucene. I have come to love Lucene through my Java work and was
extremely pleased to find the Ferret project for Ruby.

Now, I am tinkering with building the C extension using Visual Studio
2005.

So far, I have had some success in getting something built and working
in my Rails app (diffs attached). I am also encountering a very
strange problem - described at the bottom of this post.

So far, I have come up with the following:

  1. checked out fresh ferret from svn
  2. ran rake ext:
    … copying stuff…
    helper.c(3) : error C2061: syntax error : identifier ‘inline’
    … some more stuff

Aha. VS2005 does not like the “inline” keyword, that appears to only
apply to C++ code.

  1. Changed the Makefile to the following magical incantation:
    CFLAGS = -MD -Zi -O2b2x /Dinline=__inline /Ob /LTCG /DWIN32
    Also added
    mt.exe -outputresource:$(DLLIB);2 -manifest $(DLLIB).manifest
    to the $(DLLIB): target (this is required for VS2005 to generate
    compatible dlls):
    $(DLLIB): $(DEFFILE) $(OBJS)
    @-$(RM) [email protected]
    $(LDSHARED) -Fe$(@) $(OBJS) $(LIBS) $(LOCAL_LIBS) $(DLDFLAGS)
    mt.exe -outputresource:$(DLLIB);2 -manifest $(DLLIB).manifest

  2. ran nmake in ext dir:
    index_rw.c(192) : error C2275: ‘DocField’ : illegal use of this type
    as an expression

VC also does not like statements before declarations. Changed index.rw
(lines 190-192) to:
DocField **fields = doc->df_arr, *field;
text_buf[MAX_WORD_SIZE - 1] = ‘\0’;

  1. nmake again. Lots of variations on the theme:
    C:\Program Files\Microsoft Visual Studio
    8\VC\PlatformSDK\include\windef.h(154): error C2059: syntax error :
    ‘constant’

This is because q_parser.c redefines “WORD”, which is also defined in
one of the windows include files. Changed “WORD” to “YYWORD” in
q_parser.c on lines 59, 70, 440, and 1774.

  1. nmake now complains about missing symbols:
    str_hash
    exists
    bv_scan_next
    bv_scan_next_from
    tk_set
    is_skip_vints
    is_read_chars

Fixed by adding “extern inline” or “inline” to various function
declarations in header files.

Compiles and links!

Running the tests, however, reveals a segfault:

C:\work\ruby\ferret2\ferret\test>ruby test_all.rb
Loaded suite test_all
Started
…F…E…/unit/…/unit/analysis/…/…/unit/document/…/…/unit/index/tc_index
_reader.rb:539: [BUG] Segmentation fault
ruby 1.8.4 (2006-04-14) [i386-mswin32]

I have managed to trace this to the following line in fs_store.c:201:
if (fclose((FILE *)os->file))

For some reason, fclose() segfaults.
It also segfaults when closing the file when it was just opened, it
segfaults when I add some test code:

FILE * f2;
f2 = fopen(“c:\test.txt”, “wb”);
fprintf(f2, “testing…”);
printf(“closing\n”);
fclose(f2);
printf(“closed\n”);

before the original fclose() call.

I am stumped. Commenting out the two lines makes it work, but this is
obviously not a solution.

With the two lines commented out, I get 8 test failures and 10 errors,
which does not seem too bad compared with 5 failures and 17 errors
when run against the pure ruby version.

If anybody could shed some light on the fclose() problem, I’d be
extremely grateful.

Cheers,
Max

Replying to myself again… ah well.

It seems that Ruby’s win32.h redefines fclose() to rb_w32_fclose().
This leads to all kinds of unforeseen trouble, as the calling
conventions between VC6 and VC2005 have changed.

I managed to get Ferret compiling and running nicely by adding

#undef fclose
#include <stdio.h>

to fs_store.c underneath the rest of the include declarations. That
fixes most of the test errors, although there are still some failures
I suspect are to do with handling of slightly exotic characters.

If somebody wanst to volunteer for some windows testing, let me know.

Max

Hi Max,

I’ve been working on a new version of Ferret in a different repository;

svn co svn://www.davebalmain.com/exp

I got the C code compiling on VC6. I’ve still got to do some work on
the bindings but it should run a lot better on Windows. I’ll be
releasing a windows gem in the next week or so.

Cheers,
Dave

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs