Unable to compile with tkrzw

[ech3]

Branch: v1.5.0-rc2 Hash: bf15c15 Server: Ubuntu 20.04.6 LTS

Description: On my system, I tried to compile with tkzrw, but was unable to. This was originally reported in #339, but there was a request to have this a separate ticket. That ticket saw this issue on RHEL8, this issue is reported on Ubuntu 20.04.6 running in a VirtualBox.

Reproduction instructions:

1. Run the following commands:

wget https://dbmx.net/tokyocabinet/tokyocabinet-1.4.48.tar.gz
tar xvf tokyocabinet-1.4.48.tar.gz
cd tokyocabinet-1.4.48
./configure
make -j2
cd ..
git clone https://github.com/estraier/tkrzw.git
cd tkrzw
./configure
make -j2
cd ..
git clone https://github.com/zevv/duc.git
cd duc
git checkout v1.5.0-rc2
# There's no configure in the tar.gz, so I have to build it:
aclocal
autoreconf -i

2. A default configuration results in:

$ export PKG_CONFIG_PATH="../tkrzw:../tokyocabinet-1.4.48:/usr/lib/pkgconfig"
$ ./configure
[SNIP]
Selected backend tkrzw
checking for tkrzw_get_last_status in -ltkrzw... no
configure: error: Unable to find tkrzw

3. If I try to use tokyocabinet:

./configure --with-db-backend=tokyocabinet

Everything goes well. The PKG_CONFIG_PATH is needed in step 2 otherwise it won't compile.

4. The TKRZW doesn't seem to have the appropriate variables that Tokyo Cabinet does:

$ ./configure --help | grep TK
$ ./configure --help | grep TC
  TC_CFLAGS   C compiler flags for TC, overriding pkg-config
  TC_LIBS     linker flags for TC, overriding pkg-config
eh926929@eh926929-VirtualBox:~/duc$ cat /etc/issue
Ubuntu 20.04.6 LTS \n \l

Originally I thought this might be something with my toolchain, but this is happening on an install of Ubuntu in a virtual machine, so I don't think it is my environment.

[l8gravely]

Thanks for the report. Can you tell me which release you were testing on? I'm just about to release v1.5.0-rc2 with some fixes for a bunch of issues.

I just spun up a test Ubuntu 20.04 system and while I can compile tkrzw-1.0.32 and duc v1.5.0-rc2 with my latest changes, it doesn't work properly. I need to do more checking here, but any details you can provide would be a big help.

[ashugg]

I recently built duc 1.5.0-rc1 from source on Mac OS X 10.15.7 (very old system) with tkrzw-1.0.32 also built from source. It's working perfectly well. I did not use tokyo-cabinet.

One significant difference between my build and OP's instructions is that I did a "make install" in tkrzw-1.0.32 to put the libraries and headers into /usr/local, and from there they were picked up by autoconfigure in the duc source tree without any flags or environment settings needed.

[ashugg]

I've attached my build log, if that's of any interest. Read it with zless -R, as it was recorded under 'script'.

20250921-Cami-Darwin-andrew-Source.txt.gz

[ech3]

One significant difference between my build and OP's instructions is that I did a "make install"

Unfortunately, I do not have root access on my machines and have to deal with the limitations of rolling my own compiles. While there are a lot of ways to get around this, not having the environment variables there like the Tokyo Cabinet does for specific directories can be problematic for users with less access rights than they would like on their system. I don't know all of the details of the automake system, so I would have a hard time suggesting what needs to change unfortunately. While I acknowledge there are other options, having the environment variable usable would make things a lot easier for those of us who have to deal with the situation I find myself in.

[ashugg]

I had thought this error on line 86 of configure.ac was the cause:

p		AC_SUBST([TKRZW_CFLAGS])

That 'p' is not meant to be there.

However, taking it out and rebuilding the autoconf files did not result in any additional options being available in the configure script - TKRZW_CFLAGS was already present, and nothing else is "enabled" by removing the errant 'p' character.

Looking further, the problem for you is that pkgconfig is not used for tkrzw, and the environment's LDFLAGS gets reset, so if libtkrzw* files are not in a standard location, they're not going to get used.

I've hacked around it, but it would be better for the whole with_db_backend section of configure.ac to be made consistent IMHO.

@ech3 if you're comfortable with some simple edits and shell commands, I'll give you a brief list of steps that should get you up and running.

[ashugg]

(suggest retitling this issue e.g. "Unable to compile with tkrzw", there's no problem compiling tkrzw)

[ech3]

@ech3 if you're comfortable with some simple edits and shell commands, I'll give you a brief list of steps that should get you up and running. As long as I can find bandwidth, I can try stuff out. Just let me know what you're wanting me to do. I am well versed with Linux.

[l8gravely]

"Andrew" == Andrew Shugg @.***> writes:

#ashugg left a comment (zevv/duc#341)

I recently built duc 1.5.0-rc1 from source on Mac OS X 10.15.7 (very old system) with tkrzw-1.0.32 also built from source. It's working perfectly well. I did not use tokyo-cabinet.

Thanks for the testing!

One significant difference between my build and OP's instructions is that I did a "make install" in tkrzw-1.0.32 to put the libraries and headers into /usr/local, and from there they were picked up by autoconfigure in the duc source tree without any flags or environment settings needed.

Thanks. If you care to update the instructions and send in a patch with the updates to the INSTALL file, that would be appreciated.

[l8gravely]

"ech3" == ech3 @.***> writes:

#ech3 left a comment (zevv/duc#341) One significant difference between my build and OP's instructions is that I did a "make install"

Unfortunately, I do not have root access on my machines and have to deal with the limitations of rolling my own compiles. While there are a lot of ways to get around this, not having the environment variables there like the Tokyo Cabinet does for specific directories can be problematic for users with less access rights than they would like on their system. I don't know all of the details of the automake system, so I would have a hard time suggesting what needs to change unfortunately. While I acknowledge there are other options, having the environment variable usable would make things a lot easier for those of us who have to deal with the situation I find myself in.

So if you could update the INSTALL instructions to reflect both situations, I'd be happy to apply the patch for people.

Right now I'm super busy with some other stuff in life, but I'll try to get v1.5.0-rc1 (or rc2) out the door sooner rather than later.

John

[ech3]

So I found there was an issue with the PKG_CONFIG_PATH in my original reproduction instructions, I edited them to fix the issue I found. Fixing the PKG_CONFIG_PATH didn't have an effect when running against the 1.5.0-rc2 tag.

I tried the following change to the configure.ac to make it match most of the other entries:

-                LDFLAGS="$outer_LDFLAGS -ltkrzw"
-                AC_CHECK_LIB(tkrzw, tkrzw_get_last_status, 
-                            [ 
-                                 TKRZW_LIBS="-ltkrzw"               
-                                 AC_DEFINE([ENABLE_TKRZW], [1], [Enable tkrzw db backend])
-                            ], [ AC_MSG_ERROR(Unable to find tkrzw) ])
-               AC_SUBST([TKRZW_LIBS])
-               AC_SUBST([TKRZW_CFLAGS])
+               PKG_CHECK_MODULES([TKRZW], [tkrzw])
+               AC_DEFINE([ENABLE_TKRZW], [1], [Enable tkrzw db backend])

With this change I was able to get configure to run cleanly. The compile didn't run cleanly until I did:

export CPPFLAGS=-I../tkrzw export LDFLAGS=-L../tkrzw export LD_LIBRARY_PATH=../tkrzw/

When I tried to run the duc executable, it printed the help, and that's as far as I tested. All of the environment variables are the cost of doing business in my environment, and are expected. However, I don't know enough about configure.ac to say whether that is a proper solution or not, but it had the advantage of working in my environment at least. Also, lmdb is also configured a similar way in the configure.ac. however, I am not trying to compile against it since it is not a default database, but can if that is a requirement.

Right now I'm super busy with some other stuff in life

Understood. I don't have tons of bandwidth to pour towards this either. I am less concerned with this than #339 because I can hack it into submission, but haven't had bandwidth to look at that one in depth either.

[caco3]

Right now I'm super busy with some other stuff in life, but I'll try to get v1.5.0-rc1 (or rc2) out the door sooner rather than later.

That would be great!