PUMA_Init failed. (cuneifomr 0.9.0)

[MaxiPunkt]

As it seems that you don't read through old bugreports (#362224), I'll open a new one:

$ cuneiform -l ger -f html -o test.html test.tiff
Cuneiform for Linux 0.9.0
PUMA_Init failed.

I already had this problem with cuneiform 0.8.0 on my system (MandrivaLinux 2010.0), and it's still there for cuneiform 0.9.0.

I built an RPM of cuneiform out of it's source-code myself. Doing this means using Mandriva's %cmake RPM-macro.
All cmake-options used by this macro can be seen here:
http://launchpadlibrarian.net/35930811/cmake.txt (bug #/362224, comment #16)

Strace-output for cuneiform 0.8.0 can be seen here:
http://launchpadlibrarian.net/35930821/strace_cuneinform.txt (bug #/362224, comment #17)

For cuneiform 0.9.0 I'll attach a new strace...

[Jussi Pakkanen (jpakkane)]

The compiler flags seem quite aggressive to me, they may cause some problems. Could you try the following things first.

Compile the source locally (i.e. manually without RPM) with default options. Run it from the build directory without install using the CF_DATADIR env variable. Does it work?

If yes, rebuild locally using the CFLAGS etc from the attachment. Run as above. Does it work?

[MaxiPunkt (maxantispam)]

Hi there,

I can successfully run cuneiform 0.9.0 out of my local RPM-build-directory!
I even did NOT change one of these "aggressive" flags (exept the "-Werror=format-security"-thing I've disabeled for now).

That means the binary is exactly the same as put into the RPM afterwards.
To run cuneiform localy I've used the following script:

#!/bin/bash
#
PATH_TO_TESTFILE="/media/win_fat/Tools_LINUX/CuneIform_test"

export CF_DATADIR="/home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/datafiles"

./cuneiform -l ger -f html -o test.html $PATH_TO_TESTFILE/test.tiff

Does that simply mean cuneiform does't find it's datafiles for what reason ever?

[Jussi Pakkanen (jpakkane)]

After you have installed the RPM try run the installed binary with CF_DATADIR pointing to your build tree (assuming RPM does not delete it after packaging). Something like this:

export CF_DATADIR="/home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/datafiles"
/usr/bin/cuneiform [your switches here]

Does this work?

[MaxiPunkt (maxantispam)]

I've updated the script to echo all variables. Now look at this:

---------------------------------------------
$ ./test.sh

PATH_TO_BIN = /home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/build
PATH_TO_DATADIR = /home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/datafiles

Cuneiform for Linux 0.9.0

=> This one is o.k.

---------------------------------------------
$ ./test.sh (2nd attemt)

PATH_TO_BIN = /usr/bin
PATH_TO_DATADIR = /home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/datafiles

Cuneiform for Linux 0.9.0

=> This one is o.k.

---------------------------------------------
$ ./test.sh

PATH_TO_BIN = /home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/build
PATH_TO_DATADIR = /usr/share/cuneiform

Cuneiform for Linux 0.9.0
PUMA_Init failed.

=> This one is NOT o.k.

---------------------------------------------
$ ./test.sh

PATH_TO_BIN = /usr/bin
PATH_TO_DATADIR = /usr/share/cuneiform

Cuneiform for Linux 0.9.0
PUMA_Init failed.

---------------------------------------------

So it seems that cuneiform has a problem when I point to the datafiles at /usr/share/cuneiform
But the files are definetively there:

$ ls /usr/share/cuneiform
cube16pd.dat dc2204.dat rec2rus.dat rec6.dat rec6ukr.dat rec7ser.dat rec8lit.dat rec9frn.dat
cube16pl.dat dc_agr.dat rec2tur.dat rec6dut.dat rec7bul.dat rec7slo.dat rec8pol.dat rec9grm.dat
cube16pr.dat dc_etrd.dat rec3blt.dat rec6est.dat rec7cro.dat rec7spa.dat rec8por.dat rec9hun.dat
cube16ps.dat dc_rtrd.dat rec3cen.dat rec6frn.dat rec7cze.dat rec7swe.dat rec8rom.dat rec9ita.dat
cube16pt.dat pln_hpd.dat rec3.dat rec6grm.dat rec7dan.dat rec7tur.dat rec8rus.dat rec9lat.dat
cubeabde.dat pln_prc.dat rec3n.dat rec6hun.dat rec7.dat rec7ukr.dat rec8ser.dat rec9lit.dat
dc010101.dat rec1blt.dat rec3r&e.dat rec6ita.dat rec7dut.dat rec8bul.dat rec8slo.dat rec9pol.dat
dc0201.dat rec1cen.dat rec3rus.dat rec6lat.dat rec7est.dat rec8cro.dat rec8spa.dat rec9por.dat
dc0202.dat rec1.dat rec3tur.dat rec6lit.dat rec7frn.dat rec8cze.dat rec8swe.dat rec9rom.dat
dc0203.dat rec1n.dat rec4cour.dat rec6pol.dat rec7grm.dat rec8dan.dat rec8tur.dat rec9rus.dat
dc0204.dat rec1r&e.dat rec4inc.dat rec6por.dat rec7hun.dat rec8.dat rec8ukr.dat rec9ser.dat
dc0205.dat rec1rus.dat rec4mtr.dat rec6rom.dat rec7ita.dat rec8dut.dat rec9bul.dat rec9slo.dat
dc0206.dat rec1tur.dat rec4r&e.dat rec6rus.dat rec7lat.dat rec8est.dat rec9cro.dat rec9spa.dat
dc1201.dat rec2blt.dat rec6all.dat rec6ser.dat rec7lit.dat rec8frn.dat rec9cze.dat rec9swe.dat
dc1203.dat rec2cen.dat rec6bul.dat rec6slo.dat rec7pol.dat rec8grm.dat rec9dan.dat rec9tur.dat
dc1204.dat rec2.dat rec6cro.dat rec6spa.dat rec7por.dat rec8hun.dat rec9.dat rec9ukr.dat
dc2201.dat rec2n.dat rec6cze.dat rec6swe.dat rec7rom.dat rec8ita.dat rec9dut.dat vital.dat
dc2203.dat rec2r&e.dat rec6dan.dat rec6tur.dat rec7rus.dat rec8lat.dat rec9est.dat viteng.dat

[Jussi Pakkanen (jpakkane)]

That is strange. Can you run strace, or better yet gdb, on one working and one nonworking and examine where the execution takes a different path?

[MaxiPunkt (maxantispam)]

Hi there,

I had to put the commands on console instead of my script.
Otherwise the strace-output whouldn't have been very meaningful.

If these strace-outputs don't help you and you need an output with GDB, you should give me a hint how to manage this.
I didn't really work with GDB before (apart from the KDE-feature to have a gdb-backtrace automatically, when a program crashed.

[Jussi Pakkanen (jpakkane)]

In the working case you have this:

open("/home/maxipunkt/rpm/BUILD/cuneiform-linux-0.9.0/datafiles/rec6all.dat", O_RDONLY) = 3
...
read(3, " 0 rec6.dat\r\n 1 rec6grm.dat\r\n "..., 4096) = 473

Whereas in the failing case you have this:

open("/usr/share/cuneiform/rec6all.dat", O_RDONLY) = 3
...
read(3, " 0 rec6.dat\n 1 rec6grm.dat\n 2 "..., 4096) = 445

That is, the latter reads fewer bytes than the first one. This should not be, but I can't think of a reason for this. Try checking that these two rec6all.dat files are identical (diffing is sufficient).

[MaxiPunkt (maxantispam)]

Wow - good guess!

Finally I got it: RPM spec-helper played tricks on me!

Some cuneiform-datafiles aren't binary files but textfiles with DOS-EOL - file "rec6all.dat" is a good example for this.

Now spec-helper checks all textfiles on their EOL and does a DOS2UNIX-conversion.

I had to put a "export DONT_FIX_EOL=1" in my specfile and now it works.

Sorry for wasting your time.