[sword-devel] Sword SVN Compile Issues

[Greg Hellings]

Troy

On 9/22/06, Troy A. Griffitts <scribe at crosswire.org> wrote:
> Greg,
>         What awesome debug information!  Thank you for being so detailed and
> more so, for your persistence!
>
>         I've heard we have cygwin compile problems and was hoping someone
> familiar with autotools and cygwin might have a look and fix things.

Yes, the compile under Cygwin has not worked since 1.5.7a.  The
changes from 1.5.7a to 1.5.8 had seemed insignificant enough for me to
work with 1.5.7a, but the changes from there to 1.5.9 put me back on
the path of desiring to get it working.  Unfortunately my knowledge of
autotools is more acquaintance than it is familiar.  But the current
autotools setup is astoundingly excellent.

One thing I noticed is that passing the options --without-icu and
--without-lucence should be unnecessary, because the documentation
that I get from ./configure is that the defaults are --with-icu=no and
--with-lucene=no - so somewhere along the lines that seems to have
changed in the internals of the configure script and the internal
documentation was never updated?

>         I might be able to help with the last error.  SWORD conditionally
> compiles utilstr.cpp to include an appropriate string comparison,
> ignoring case, function.  Can you confirm that
> sword/src/utilfuns/utilstr.cpp is being compiled?

Yes, utilstr.cpp is compiled and linked into the library.  The odd
thing is that the compile only seems to fail under the buildtest.exe -
which must be calling that method.  Testing 1.5.7a in the same
environment, it produces an error at the same point in the compile -
when compiling testlib.exe - but it complains about a missing lib.
The command is

/bin/sh ./libtool --mode=link g++ -g3 -O0 -Werror -DCURLAVAILABLE  -o
testlib-exe testlib.o -L./lib -lsword -lz

and the error message is:

libtool: link: cannot find library `'

It appears to be searching for a library that does not exist.  As this
did not seem to affect wxSword, I proceeded along happily at that
time.  1.5.9 dies after the following, seemingly functionally
identical, commands:

/bin/sh ./libtool --tag=CXX --mode=link g++ -O2 -DCURLAVAILABLE    -o
buildtest.exe  buildtest.o ./lib/libsword.la -lz
g++ -O2 -DCURLAVAILABLE -o buildtest.exe buildtest.o
./lib/.libs/libsword.a -L/usr/local/lib /usr/local/lib/libcurl.a -lz

Both 1.5.7a and 1.5.9 are compiling utilstr.cpp and linking the
utilstr.o into the library.  It seems a bafflement to me that gcc/g++
seem to just lose libraries or symbols that they are searching for :-?
 The problems appear slightly different, but related.  1.5.7a was
surmountable just by linking in the proper libraries to my program -
this 1.5.9 bug might prove to be a bit more tricky.

>
>         -Troy.
>
>
>
>
> Greg Hellings wrote:
> > Fellow swords(wo)men,
> >
> > I have been trying to compile the latest SVN (as of this morning - I
> > believe it's revision 1979) under Cygwin in Windows XP Pro.  I've
> > noticed the following oddities:
> >
> > 1) When configured with the command:
> > CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin" ./usrinst.sh
> > --target=i686-pc-mingw32
> > and then executing the make results in errors in curlftpt.cpp
> > complaining about missing curl.h files.  Those files are included, but
> > they are in /usr/include/curl - right where they ought to be.
> >
> > 2) I then add CXXFLAGS=" -I/usr/include/ " to the environment variables
> > at the beginning of the userinst.sh execution and it brings up lots of
> > errors about the STL being undefined.  So I execute the configure script
> > with the --without-curl option and with the CXXFLAGS=" -I/usr/include "
> > still there.
> >
> > 3) Now the system complains about missing sys/socket.h, netinet/in.h ,
> > netdb.h, arpa/inet.h in ftplib.o ... these files are also in /usr/include
> >
> > 4) So I go back and trace through the lib/Makefile and observe that
> > maybe CPPFLAGS is a better place to put the -I/usr/include and I rerun
> > the command
> > CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin" CPPFLAGS=" -I/usr/include "
> > ./usrinst.sh --target=i686-pc-mingw32
> > so that I can see if it will pick up the curl headers.  It proceeds much
> > further than before but fails in file curlftpt.cpp still complaining
> > about undeclared parts of the stl vector class.
> >
> > 5) I then tried reconfiguring to tell system to compile with
> > /usr/include in the CPPFLAGS and with --without-curl enabled.  Now the
> > build fails in ftplib.c complaining about hundreds of redefined
> > functions, macros and variables within what appears to be a problem with
> > recursively included headers.
> >
> > 6) So I tried to compile it with just the native Cygwin tools by calling:
> > CPPFLAGS=" -I/usr/include " ./usrinst.sh
> > Now the compile fails in swmgr.cpp by calling
> > ../include/utf8transliterator.h, which includes unicode/unistr.h and
> > unicode/translit.h - which it cannot find, as they are part of ICU,
> > which I cannot find available for Cygwin.
> >
> > 7) So then I tried to compile it with the native Cygwin tools but
> > without icu support by configuring wit
> > CPPFLAGS=" -I/usr/include " ./usrinst.sh --without-icu
> > Now the compile dies in swmodule.cpp because I am missing CLucene.h and
> > its attendant headers.
> >
> > 8) Then I tried to compile after configuring with the following options:
> > CPPFLAGS=" -I/usr/include " ./usrinst.sh --without-icu --without-lucene
> > This time the compile dies in the linking stage - probably because I had
> > not been doing a clean make inbetween my compilations, since they were
> > all dying in the compile stage.  So I re-pulled the SVN source and
> > reconfigured and compiled with the same options and the compile ran
> > cleanly, but the link returned a single message complaining about
> > swobject.cpp having an undefined reference to sword::stricmp(char
> > const*, char const*) when attempting to compile buildtest.exe
> >
> > Any ideas where to proceed from here?
> >
> > --Greg Hellings
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > sword-devel mailing list: sword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>