[frobtads] Error compiling 1.2.3 with --enable-static-link

I’m getting this with an up-to-date Debian GNU/Linux 7 (wheezy) during make:

[...] CXXLD t3make src/osportable.o: In function `os_get_sys_clock_ms': /tmp/src-20130518-6b29887dfe-1.2.3/src/osportable.cc:714: undefined reference to `clock_gettime' /tmp/src-20130518-6b29887dfe-1.2.3/src/osportable.cc:719: undefined reference to `clock_gettime' src/osportable.o: In function `os_time_ns': /tmp/src-20130518-6b29887dfe-1.2.3/src/osportable.cc:735: undefined reference to `clock_gettime' collect2: error: ld returned 1 exit status [...]
The commands used:

./bootstrap
./configure --prefix=$HOME/opt/frobtads-1.2.3 --disable-t2-compiler --enable-static-link
make

During bootstrap I’m getting some warnings, but those doesn’t seem fatal because without --enable-static-link everything compiles fine.

warning: The macro `AC_TRY_COMPILE' is obsolete.

Any hints?

Try LIBS=’-lrt’ when calling configure:

LIBS='-lrt' configure [...]

The bootstrap warning is harmless.

Thank you, RealNC.

Some backgroud:

I’m trying to compile statically because I can’t bootstap nor compile frobtads on an old system that I regulary use for development and test. I can bootstrap in wheezy, but then compilation fails in the old system (src/osfrobtads.h; vasprinf related.)

My plan is to compile with the up-to-date system and install the binaries onto the old one.

Until now, I was using 8dbe7fa5c2 dynamic binaries that I managed to get working at the time of that commit, but the differences between the systems doesn’t allow me to do the same for frob, now (t3make works but generates incompatible .t3 files: interpreter is too old.)

Back to the topic:

This fixes the clock* errors, but confuses the checking for pthreads, and causes errors linking t3make. Adding -pthread to LIBS solves them, and t3make pass linking.

But, here it comes frob linking, with massive errors. Most about ncurses and curl. I can workaround many ncurses errors with some more LIBS options, but I think I’m hitting the wall with curl and kerberos.

curl-config --static-libs … returns some options. Using those, there’re problems again linking t3make.

CXXLD t3make /usr/bin/ld: cannot find -lgssapi_krb5 /usr/bin/ld: cannot find -lkrb5 /usr/bin/ld: cannot find -lk5crypto
Removing those 3 options, t3make passes linking again, but frob doesn’t (although less curl errors raised, it seems.)

Some searching brings me to Debian bug #439039 libkrb5-dev: static libraries no longer supported. I’m starting to think that curl network support in frob and static linking are somehow incompatible. I’m not planning to use network related features when using the staticaly linked frob, so…

Would it be feasible to configure out curl support for frob? Does that makes sense?

If you think that it will be time consuming and doesn’t worth the effort, don’t worry. I can adapt my TADS development workflow, using the newest system. Or maybe I have to dig for about the vasprintf problem…

I’d be more interested in the original build error you get on the old system. That should be easier to fix compared to ripping out networking support.

Fair enough. I’ll post soon. Thank you very much.

I found an error in src/osfrobtads.h related to vasprinf. It’s a missing include. I’ve pushed a fix for it to Git. It’s just a matter of adding:

#include <stdarg.h>

at the beginning of the file, right after the line:

#include <dirent.h>

Oops, I just posted https://intfiction.org/t/frobtads-error-compiling-1-2-3-on-debian-squeeze/5517/1

I’ll try the include and report back there.