I am required to use CCFinder for an assignment at my university.

As, on the download page, http://www.ccfinder.net/ccfinderxos.html there is
only a binary avialble for Windows, I must compile from source.

Please note: http://www.ccfinder.net/doc/10.2/en/install-ubuntui386.html
appears to indicate there used to be a binary for Linux available.)

There is a source package for Win32, and an additional download for
Ubuntu 9.10 i386. However, my environment is ArchLinux x86_64 bit.
From the blog http://nicolas-bettenburg.com/?p=290 it appears the
karmic.mk files are to be renamed to Makefile in order to compile.
The dependency libraries, the boost library is to be installed.
However, just installing the dependencies did not make it compile.

The first problem to encounter was

In file included from ../common/bitvector.cpp:2:0:
../common/bitvector.h:8:2: fout: ‘size_t’ does not name a type

and some more error messages related to size_t. This is caused
by the missing include of cstddef, so adding

#include <cstddef>

fixed this problem.

The next problem to run into:

g++ -licule -licutu -licuio -licuuc -liculx -licudata -licui18n -lboost_thread-mt -o ../ubuntu32/ccfx base64encoder.o bitvector.o ccfx.o ccfxcommon.o prettyprintermain.o rawclonepairdata.o unportable.o utf8support.o ccfxconstants.o
/usr/bin/ld: cannot find -lboost_thread-mt

Solution: Edit the Makefile, Changed to LIBS=
Replace -lboost-thread-my by -lboost-thread

 

As for the modules, I will not be describing every problem, only the solutions.


Compiling the picosel module

Copy karmic.mv to Makefile
no other problems encountered


Compiling pyeasytorq module

Copy karmic.mv to Makefile
Change
-I/usr/include/python2.6/
to
-I/usr/include/python2.7/

Add -fPIC to OPTS=
Change -lboost_thread-mt to -lboost_thread on the LIBS= line


Compiling the picosellib module

Note there is a type on the guide pointed to above,
the correct spelling is with double l.

Copy markic.mv to Makefile
Edit the Makefile:

Changes to OPTS=
Replace
-I/usr/lib/jvm/java-6-openjdk/include
by
-I/usr/lib/jvm/java-7-openjdk/include/ -I/usr/lib/jvm/java-7-openjdk/include/linux
Add -fPIC

Changed to LIBS=
Replace -lboost-thread-my by -lboost-thread


Compiling the CCFinderXLib module

Copy markic.mv to Makefile
Edit the Makefile:
Changes to OPTS=
Replace
-I/usr/lib/jvm/java-6-openjdk/include
by
-I/usr/lib/jvm/java-7-openjdk/include/ -I/usr/lib/jvm/java-7-openjdk/include/linux
Add -fPIC

Changed to LIBS=
Replace -lboost-thread-my by -lboost-thread



Apart from “personality problems”, this appeared to have produced a working binary

[andre@hp ubuntu32]$ ./ccfx
CCFinderX ver. 10.2.7.4 for Ubuntu i386 (C) 2009-2010 AIST
[andre@hp ubuntu32]$ file ccfx
ccfx: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x29bf88343a59e7c0f56c83115d704d139b066ff9, not stripped

However, the binary is not able to work as it should. The error message it produces is:

sh: /usr/bin/python: Bestand of map bestaat niet

This is due the fact, the path to the pyton 2 interpreter is hardcoded into the
program, in ccfx.cpp line 2567. As ArchLinux already switched to python 3, the
correct path to the python 2 interpreter should be /usr/bin/python2



In my opinion, it’s a bad habit to hard-code paths into your program that is
meant for public release. Open source projects usually distribute their
source code with a configure script included, that detects the correct
paths of includes et cetera. And for good reason, as for editing all
these Makefiles manually is quite inconvenient.

Please note: the paths and versions mentioned in this post are specific to my ArchLinux installation, and another distribution might ship other versions of python and java.

Another note: The binaries obtained by this procedure pass the test described in Nicolas Bettenburg’s blog. However, replacing the boost_thread-mt by boost_thread might introduce multithreading related issues. However, a non-multithreading version of a threading library doesn’t make much sense, therefore I don’t expect this to be an issue.

« »