Paul, Try installing the libcurl-dev package (I think that's its name) and building with that instead. SWORD _ought_ to compile fine without it. That is why we have ftplib included in SWORD, but we recommend use of libcurl.
--Greg On Sat, Dec 10, 2011 at 3:59 PM, Paul A. Martel <pmarte...@gmail.com> wrote: > I'm trying to build sword according to the instructions @ > > http://www.crosswire.org/sword/develop/swordapi/ > > After checking out trunk and running autogen and usrinst, > I get the following error from the "make" command: > > /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I../include -I../include -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix > -D__unix__ -DSWICU_DATA=\"/usr/lib64/sword/1.6.2_icu_4.4.2\" > -D_FTPLIB_NO_COMPAT -MT ftplib.lo -MD -MP -MF .deps/ftplib.Tpo -c -o > ftplib.lo `test -f '../src/utilfuns/ftplib.c' || echo > './'`../src/utilfuns/ftplib.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -I../include > -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix -D__unix__ > -DSWICU_DATA=\"/usr/lib64/sword/1.6.2_icu_4.4.2\" -D_FTPLIB_NO_COMPAT -MT > ftplib.lo -MD -MP -MF .deps/ftplib.Tpo -c ../src/utilfuns/ftplib.c -o > ftplib.o > In file included from ../src/utilfuns/ftplib.c:64:0: > ../include/ftplib.h:26:0: warning: "_FTPLIB_NO_COMPAT" redefined [enabled by > default] > <command-line>:0:0: note: this is the location of the previous definition > mv -f .deps/ftplib.Tpo .deps/ftplib.Plo > /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > -I../include -I../include -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix > -D__unix__ -DSWICU_DATA=\"/usr/lib64/sword/1.6.2_icu_4.4.2\" > -D_FTPLIB_NO_COMPAT -g3 -O0 -Wall -Werror -D_ICU_ -ftemplate-depth-25 > -I/usr/include -I/usr/lib -DUSELUCENE -I/usr/lib64 -MT roman.lo -MD -MP > -MF .deps/roman.Tpo -c -o roman.lo `test -f '../src/utilfuns/roman.cpp' || > echo './'`../src/utilfuns/roman.cpp > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -I../include > -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix -D__unix__ > -DSWICU_DATA=\"/usr/lib64/sword/1.6.2_icu_4.4.2\" -D_FTPLIB_NO_COMPAT -g3 > -O0 -Wall -Werror -D_ICU_ -ftemplate-depth-25 -I/usr/include -I/usr/lib > -DUSELUCENE -I/usr/lib64 -MT roman.lo -MD -MP -MF .deps/roman.Tpo -c > ../src/utilfuns/roman.cpp -o roman.o > mv -f .deps/roman.Tpo .deps/roman.Plo > /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > -I../include -I../include -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix > -D__unix__ -DSWICU_DATA=\"/usr/lib64/sword/1.6.2_icu_4.4.2\" > -D_FTPLIB_NO_COMPAT -g3 -O0 -Wall -Werror -D_ICU_ -ftemplate-depth-25 > -I/usr/include -I/usr/lib -DUSELUCENE -I/usr/lib64 -MT ftplibftpt.lo -MD > -MP -MF .deps/ftplibftpt.Tpo -c -o ftplibftpt.lo `test -f > '../src/mgr/ftplibftpt.cpp' || echo './'`../src/mgr/ftplibftpt.cpp > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -I../include > -I/usr/include -DUSE_AUTOTOOLS -DUNIX -Dunix -D__unix__ > -DSWICU_DATA=\"/usr/lib64/sword/1.6.2_icu_4.4.2\" -D_FTPLIB_NO_COMPAT -g3 > -O0 -Wall -Werror -D_ICU_ -ftemplate-depth-25 -I/usr/include -I/usr/lib > -DUSELUCENE -I/usr/lib64 -MT ftplibftpt.lo -MD -MP -MF .deps/ftplibftpt.Tpo > -c ../src/mgr/ftplibftpt.cpp -o ftplibftpt.o > In file included from ../src/mgr/ftplibftpt.cpp:26:0: > ../include/ftplib.h:26:0: error: "_FTPLIB_NO_COMPAT" redefined [-Werror] > <command-line>:0:0: note: this is the location of the previous definition > cc1plus: all warnings being treated as errors > > make[1]: *** [ftplibftpt.lo] Error 1 > make[1]: Leaving directory `/home/p/xulsword/built_sword/lib' > make: *** [all-recursive] Error 1 > > After the first time this happened, I noticed that I did not have > ftplib3 or ftplib-dev packages installed. So I installed them > and tried the whole process again from a clean copy of the > svn source tree. This seemed to make no difference. > > Indeed, the command line established by the configuration scripts > is defining a macro that is also defined (identically) in the header. > It would be easy enough for me to remove it from the header or > qualify it with an #ifndef, slightly harder (for me) to dig through how it's > getting into the make command and remove it there, but what's the RIGHT > thing to do? > > I guess I'll take the #ifndef approach for now, though I hadn't > been planning on patching the sword code (quite yet). > > Any help? > Thanks, > --paul > > > _______________________________________________ > sword-devel mailing list: sword-devel@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page