[tlbuild] dvipdfm-x issues

[Karl Berry]

Hi Nelson - back on your mail from May 2016 (sorry):
https://tug.org/pipermail/tlbuild/2016q2/003535.html

    When I examine texk/config.log and texk/dvipdfm-x/log on OpenSUSE 11
    ...
    ./libtool: line 7475: cd: ${exec_prefix}/lib/x86_64-pc-linux-gnu: No
    such file or directory

I believe this is the same problem you reported wrt centos6 on March 1,
2018. I replied to it here, suggesting configure --libdir=/usr/local/lib
as the cleanest fix:
  https://tug.org/pipermail/tlbuild/2018q3/004294.html
I don't know if you tried that or if it works. I hope so.

FWIW, I logged in to your osuse11 machine (osuse.vm) and was able to
build all the non-C++11 programs like this (~karl/bin/mybuild on that
machine), but without trying to use any local libraries or compilers:

PATH=/usr/bin:/bin
cd /tl/source
rm -rf libs/icu libs/poppler libs/graphite2 texk/dvisvgm # or configure fails
./Build \
  -g \
  -C \
  --disable-xetex \
  --disable-luatex \
  --disable-luajittex \
  --disable-luatex53 \
  --disable-dvisvgm \
  --disable-bibtexu \
  --disable-upmendex \
  --disable-poppler \
  --without-system-icu \
  --without-system-graphite2 \
  --without-system-poppler \
  --enable-native-texlive-build

I realize this is not reproducing your exact situation, but it's what
I've got. Sorry. (I think you may be just about the only person on the
planet trying to use many locally-compiled libraries.)

    It really would be nice if we could get builds to work pretty much
    anywhere

Yes, it certainly would. I am only one person and can only do so much,
as can be seen by the dates on these messages. Pretty much every
configure failure has to be investigated from scratch, on a system of
the right type, all the way to the bitter end. So just reproducing such
problems is nontrivial.

I know everyone does what they can. All I can say is that it also "would
be nice" if other contributors could get to the point of finding fixes
for particular configure failures. It's all just shell scripts, so
ultimately all is visible.

I know automake/autoconf are seen as painful. I don't disagree, but I
believe it's because software configuration is inherently, unavoidably,
horribly painful nowadays. I am not aware of any system that could
replace it for TL's situation, with many heterogenous packages coming
from many different sources. (CMake is not even remotely flexible
enough.)

The only real "fix" I can see is no longer creating binaries in the
upstream TeX Live, and leaving it to distros and others. I don't think
that's the desired outcome yet. So we trudge on as best we can ...
--best, karl.