[tlbuild] Bug in kpse-icu-flags.m4: a long-standing OpenBSD build failure

[Karl Berry]

Back on this mail from April 2017 and earlier (sorry):
https://tug.org/pipermail/tlbuild/2017q2/003799.html

To summarize, icu needs -lpthread on openbsd (but nothing else among our
systems).

I previously hacked in an ICU_LIBS_EXTRA variable back then to make it
more convenient to add manually:
  https://tug.org/pipermail/tlbuild/2017q2/003812.html
I've left in ICU_LIBS_EXTRA, but now I've also changed kpse-icu-flags.m4
to add the -lpthread automatically on openbsd. r49495.

Although it would be better to link a test program to see if it is
necessary, that would be lots more complicated, and I had no suitable
test program at hand, and since in our case the reality is that openbsd
is all that needs it (as far as I've heard?), I just hardwired it:

pin Build/source/m4/kpse-icu-flags.m4]
# checking for openbsd to add -lpthread for icu.
case $build_os in
openbsd*)
  eval AS_TR_CPP($1)_LIBS=\"$[]AS_TR_CPP($1)_LIBS -lpthread\"
  ;;
esac
which amounts to ICU_LIBS="$ICU_LIBS -lpthread";
except it seemed nicer to use the code that will work regardless of
non-identifier characters in the library name, etc.

I added some more debugging/logging messages to the m4 macros while I
was at it. Searching for "tldbg" in the config.log file and configure
scripts should show more traces of what's happening now.

>     ./Work/libs/icu/icu-build/config/icu-config \
>         --prefix=/path/to/Work/libs/icu/icu-build \
>         --ldflags-system

I decided not to use icu-config because that would induce a dependency
on libpthread.so on, so far as I can see, most or all (Unixish)
platforms. This does not seem like a good idea.  That is, looking at the
built icu-config script on my CentOS7, where -lpthread is not needed,
but it is still included in the output:
LIBS="-lpthread -lm  "
(libm is not needed either on this system.) Maybe libpthread is
ubiquitious among the systems we build binaries for, but ... maybe not ...

As far as I know, the TL configure scripts only call pkg-config to
configure a library when the system library is being used, not the
library from TL. This certainly has its pros and cons, but I'm not
inclined to make (the huge effort for) a wholesale switch without clear
proof that it would be better. From the above, I'm guessing it would be
worse, in terms of cases that have to be fixed.

Hope I didn't mess up too badly. --thanks, karl.