[tlbuild] dvipdfm-x issue on CentOS 6

[Karl Berry]

Nelson - back on this mail from six months ago (ridiculous, I know), I
expect you've solved it all by now, but just for the record, responding
to various in your email:

- exec_prefix is a standard part of the GNU build system, as you know;
it's supposed to default to ${prefix}, as set in the top-level Makefile.

- the problem below is the -L${exec_prefix}/lib/x86_64-pc-linux-gnu
flag, which is apparently being passed as a literal string, without 
variable expansion.

- therefore libtool tries to take the dirname of a strangely-named
directory, with that literal dollar sign and braces in it:
  ./libtool: line 7475: cd: ${exec_prefix}/lib/x86_64-pc-linux-gnu: No such file or directory
which clearly fails, regardless of the suffix or value of exec_prefix.

- this is being done as part of a configure test (-o conftest), and has
nothing to do with what's actually being tested (zlib in this case).
libtool is aborting before it gets to the point of actually trying to
link anything.

- possibly if you ran 
 make AM_MAKEFLAGS=libdir=/usr/local/lib
it would propagate down. There are dozens of such variables, as you
know, and it would not be feasible to manually list them all in every
recursive make just in case they need to be manually overridden.

- I think it would probably be more reliable to run configure
--libdir=/usr/local/lib to get rid of the unwanted exec_prefix-based
value in the first place. 

- Not that it matters for your environment, but I'll mention for the
archive that I did end up building all the non-C++11-dependent programs
on CentOS6 and the resulting tarball is linked from
tug.org/texlive/bugs.html. (The most important missing programs are
xetex, luatex, dvisvgm.)

Best,
Karl


Date: Thu, 1 Mar 2018 19:11:46 -0700
From: "Nelson H. F. Beebe" <beebe at math.utah.edu>
To: "TLbuilders" <tlbuild at tug.org>
Cc: beebe at math.utah.edu
Subject: [tlbuild]  dvipdfm-x issue on CentOS 6

My earlier CentOS 7 builds have succeeded completely.

I've made considerable progress in getting my texlive-20180227
snapshot to build on GNU/Linux CentOS 6, for which several system
components are too old for the demands of some TeX Live 2018 configure
scripts.

I'll report on CentOS 6 more fully later, but I have hit a stumbling
block that perhaps others on this list can see how to solve.

My builds reach the point of the dvipdfm-x directory, then die like
this:

	configure:15964: ./libtool --mode=link --tag=CC /usr/local/bin/gcc-6			\
	    -o conftest -I${prefix}/include							\
	    -I/var/tmp/build/bare/texlive-20180227/source/Work/libs/zlib/include		\
	    -I/var/tmp/build/bare/texlive-20180227/source/Work/texk				\
	    -I/var/tmp/build/bare/texlive-20180227/source/texk -DNO_DEBUG			\
	    -I${prefix}/include -L${exec_prefix}/lib/x86_64-pc-linux-gnu			\
	    -Wl,-rpath,${exec_prefix}/lib/x86_64-pc-linux-gnu conftest.c			\
	    /var/tmp/build/bare/texlive-20180227/source/Work/libs/zlib/libz.a			\
	    /var/tmp/build/bare/texlive-20180227/source/Work/texk/kpathsea/libkpathsea.la	\
	    -lm >&5										\
	    ./libtool: line 7475: cd: ${exec_prefix}/lib/x86_64-pc-linux-gnu: No such file or directory

	libtool:   error: cannot determine absolute directory name of '${exec_prefix}/lib/x86_64-pc-linux-gnu'
	configure:15964: $? = 1
	configure: failed program was:
	...
	configure:15967: error: Sorry, you need zlib with compress2

The local library /usr/local/lib6/libz.a has the symbol compress2, as does
the source/Work/libs/zlib/libz.a.  The symbol exec_prefix is set to /usr/local,
as shown by earlier contents of the config.log file.  However, neither of
these 

	/usr/lib/x86_64-pc-linux-gnu
	/usr/local/lib/x86_64-pc-linux-gnu

exist as directories on my CentOS 6 systems.

It would appear that if I create an empty directory with the second
name above, that might fix the problem.  It does not.

Because that directory does not exist, it should not even be
referenced in the Makefiles, but it is, starting at the top-level one,
which has

	libdir = ${exec_prefix}/lib/x86_64-pc-linux-gnu

I therefore restarted the make with

	make libdir='${prefix}/lib' world

That failed in dvipdfm-x as before.  I tried again without a variable
expansion, like this:

	env libdir=/usr/local/lib make -e world

and that failed the same way.

I next tried one level down:

	cd texk
	env libdir=/usr/local/lib make -e world

I get the same failure in dvipdfm-x.

It would appear some Makefile, or libtool script, along the way is not
correctly propagating the value of libdir set on the command line, or
imported from the global variable environment, but instead, is
overriding those settings with a wrong value for libdir.