Thank you, RealNC.
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.
… returns some options. Using those, there’re problems again linking 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…