5 Community‎ > ‎


Code repository

The code is stored in a git repository. The repository is accessible from the Github.

The code can be checked out from the repository. This code gives the latest versions of the Bibledit suite or programs. The code has not been thoroughly tested, but is supported.

To get the most recent code, do the following in a terminal.

git clone --depth 1 https://github.com/teusbenschop/bibledit.git

The above command makes a shallow clone of the code repository to your local disk. It will create a directory called "bibledit". Go into that directory, go into directory "gtk" for bibledit-gtk, or into directory "web" for bibledit-web. Then do the normal "./configure", "make", "sudo make install" sequence, as is described in the installation documentation for bibledit-gtk and the installation documentation for bibledit-web..

Note 1. If you are installing development versions often, to save bandwidth, it is possible to leave the directory "bibledit", created above, as it is. If that directory is left there, then next time there is no need to clone the whole repository. Just pulling the changes is enough:

$ cd bibledit
$ git reset --hard
$ git pull
Continue installation from here...

Note 2. For best results close Bibledit-Gtk while installing the new version. This does not apply to Bibledit-Web.

Help needed

Help in developing Bibledit is welcome.

* Do you like writing good documentation? Your help is welcome to maintain the helpfiles of Bibledit.

* You know how useful packages are? Making packages could be the thing you would like to help with.

* Are you good at testing? Your feedback is welcome and suggestions for new features too.

Bugs and feature requests

When submitting bug reports it is sometimes useful to include the configuration and data of Bibledit-Gtk. This allows the programmer or tester to reproduce your bug, and so fix it. In a terminal type

tar -czf bibledit.tar.gz .bibledit

to create a file called bibledit.tar.gz. This file can be attached to the bug report.

How it started

It started with an entry in the programmer's diary:

* Friday 30 May 2003. I made the decision to move from Windows to Linux. God will help here, and the future will show why this decision had to be taken. A lot of programming needs to be done to move the Bible translation programs to Linux.

I remember that at that time I had lost peace with God for a good while, was in great unrest of mind, and examined myself thoroughly to find out what it was, and then came to the above decision. It seemed to me a bit an unusual cause for this unrest, but nevertheless I could not find another one. After the decision was made and the actual move, I regained my peace.

In 2004 some programming work was done that aided Bible translation work, and as I foresaw a greater future use for this program, I called it Bibledit.

After that God gave sufficient energy to work on the project in the spare time. Others started to contribute too, and the project moved forward to where it is now.

Using the debugger

When troubleshooting bibledit a core file may be requested.

A core file is a file created by the operating system when a program terminates unexpectedly, encounters a bug, or violates the operating system's protection mechanisms.

By default core files are not created on some Linux systems. Whether or not the operating system creates core files is controlled by the ulimit command. To see the current ulimit setting for core files, do the following:

ulimit -c

The ulimit command sets limits on the resource available to the bash shell. The -c parameter controls the size of core files. The value 0 indicates that core files are not created. To enable core file creation, increase the size limit of core files to a number greater than zero. For example:

ulimit -c 50000

allows core files and limits the file size to 50000 bytes.

If you need to enable core file creation temporarily to create a core file for a problem application, increase the ulimit at the command line and then run the application.

When bibledit causes a segmentation fault and leaves a core dump file, you can use gdb to look at the program state when it crashed. Use the core command to load a core file.The argument to the core command is the filename of the core dump file, which is usually "core.<pid>", making the full command core core.<pid>.

prompt > bibledit
Segmentation fault (core dumped)
prompt > gdb bibledit
(gdb) core core.<pid>

If bibledit crashes repeatedly, an easier way is to start bibledit through the debugger, and then use the backtrace command to see what happened and when.

Open bibledit in the debugger:

gdb bibledit

Bibledit would not run in gdb normally and say that another copy is already running. To disable that check for another instance, and have it run in gdb, add the --debug argument to the commandline:

(gdb) set args --debug

Run it:

(gdb) run

If there is a problem, bibledit will freeze. Switch to the debugger. View the stack:

(gdb) backtrace

You can then contact the developer and inform him about what you see and when it happened.


On Cygwin, gdb might get stopped and return you to the terminal. Enter "fg" to get the debugger back.

Subpages (2): Diagnostics Mac OS X Notes