Hi. Following upgrading 64-bit openSUSE Leap from version 42.2 to 42.3 on August 31, 2017 and then updating many software packages during September 1-2, 2017, probably including some TeX Live software packages, I could run pdflatex on October 13, 2017. But beginning on March 10, 2018 I discovered I could no longer successfully execute a command of the form ``pdflatex Throwaway22.tex,” then receiving a messages like “pdflatex.fmt doesn’t match pdftex.pool.” A response to the command “tex -v” on September 2, 2016 showed that I had portions of TeX Live 2016 installed for use in this openSUSE operating system; and the date for the installation of portions of TeX Live was still shown as September 2, 2017 in March of the year 2018.
After reading some postings on the Internet I made the following attempts to try to remedy this problem:
-
executing “fmtutil –all” and “fmtutil-sys –all”. A common result for me: “Successfully rebuilt formats: 22, no available formats: 18, failed to build: 8 (pdftex/pdftex xetex/xetex pdftex/pdfetex pdftex/mllatex xetex/xelatex pdftex/latex pdftex/etex pdftex/pdflatex)”. The file fmtutil.pl was found to be a “Read-only” Perl script file that was last modified on June 9. 2016, the day of TeX Live 2016’s release (http://texblog.net/latex-archive/distributions/tex-live-2016-released/), and is within that file reported to be ``Maintained in TeX Live: Master/texmf-dist/scripts/texlive”. So the file fmtutil.pl seems to be a file that an openSUSE repository acquired from TeX Live 2016. And I do have version 5.18.2-9.1 of the Perl interpreter installed in my openSUSE Linux operating system to work with the Perl script fmtutil.pl.
-
According to https://www.tug.org/texlive/quickinstall on the Internet the path for TeX Live binary files should be added to the PATH environment variable. Executable files of most, if not all of the above eight files pdflatex, et cetera, for which format files failed to be built were found in /usr/bin in my openSUSE system. But eventually I found that /usr/bin was already in my openSUSE PATH environment variable! (That is after learning for the BASH (Bourne Again SHell) how to add /usr/bin to the PATH environment variable by adding the “PATH=$PATH:/usr/bin” and “export PATH” statements in /home/MYHOMEDIRECTORY/.profile, via “echo $PATH” seeing that /usr/bin was in that PATH environment variable twice, and then taking those two statements out of /home/MYHOMEDIRECTORY/.profile, I was right back where I started with the error message “pdflatex.fmt doesn’t match pdftex.pool” not eliminated following a command of the form “pdflatex Throwaway22.tex”.)
- I found some important definitions of variables for TeX Live 2016 in /etc/texmf/web2c/texmf.cnf, including for the variable TEXMFCNF. But after entering the command ``echo $TEXMFCNF” and receiving no information I realized that TEXMFCNF was not an environment variable in my openSUSE installation. Karl Berry’s instructions in http://metdos.fam.cie.uva.es/~latex/software/texlive-en.pdf were for a user of TeX Live to enter a “setenv TEXMFCNF ….” command or its BASH- (Bourne Again SHell-) equivalent statement which should make TEXMFCNF an environment variable. So in /etc/environment as a superuser I entered
TEXMFCNF=/var/lib/texmf:/var/lib/texmf/web2c:/etc/texmf:
(tab) /etc/texmf/web2c:/usr/share/texmf:/usr/share/texmf/web2c
export TEXMFCNF
, saved the file /etc/environment in my installation of the KWrite text editor, and restarted my openSUSE operating system (I am usually the only user of my computer.). Then in a terminal program after entering the command “echo $TEXMFCNF” I gratefully could see the above list of directories being displayed, proving that TEXMFCNF had indeed been made an environment variable. But unfortunately after in /home/MYUSERNAME entering “pdflatex Throwaway22.tex” I still saw the error message “pdflatex.fmt doesn’t match pdftex.pool”.
The posting on https://bugzilla.opensuse.org/show_bug.cgi?id=984878 for software “bug” number 984878 indicated that the error message I obtained could have been caused by problems with hypenated file names. Despite that “bug” having been reported on July 7, 2016 as having been fixed, in a written discussion on that same Web page on July 19, 2016 Bernhard Wiedeman’s inclusion of ``42.3” in lines containing hyphenated file names suggests that the problem with hypenated file names may have occurred in some version of openSUSE 42.3. However, I think all or nearly all of the texlive software packages in openSUSE Leap 42.3 have hypenated file names of the form texlive-… Yet according to my experience executions using fmtutil and fmtutil-sys have indicated that some format files were actually built using those commands. Furthermore I think hyphenated file names for TeX Live software packages have existed for some years, including on October 13, 2017 when pdflatex worked in my 64-bit openSUSE Leap 42.3 Linux operating system with portions of probably TeX Live 2016 installed for use by it. So I am inclined to think problems with hyphenated file names may not be the cause of the problem I report here.—And if so, this could indicate that the error message of the type I report here may in general have at least two possible causes for it being reported by computer software.
On https://tug.org/pipermail/tex-live/2013-July/033985.html Zdenĕk Wagner wrote relating to someone else concerning my type of problem something close to, ``pdftex.pool is no longer needed, it is compiled inside the pdftex binary. The problem you describe is almost always caused by a wrong PATH setting or by a forgotten TEX* environment variable. Your binary finds a format created by a different version. You have to examine your environment and find what is not set properly.” As a result of these comments by Zdenĕk Wagner I have been pursuing the possibility of a problem with one or more environment variables being the cause of my problem.
Major questions:
- How may I make a command of the form ``pdflatex Throwaway22.tex” work in my installation of the 64-bit openSUSE Leap 42.3, Linux operating system? I have probably hundreds of software packages with “texlive” in their names installed in this operating system, even though I probably have not been using some of them. So I hope a solution can be found which will not require me to install all of those packages one at a time in order to restore my TeX Live software to the state in which it existed before this present problem began to exist.
(Besides trying to keep my openSUSE computer software up to date, using pdflatex to produce technical write-ups, the GNU’s Not Unix (GNU) Image Manipulation Program (GIMP) to produce figures for such technical write-ups, and some years ago latex2html to produce technical write-ups has been a major reason for me to use an openSUSE Linux operating system. Thanks for all of the free software! Because of it I could gratefully produce a technical write-up using my personal computer while at home and then in some instances go somewhere with free Internet service to have it sent to someone via the Internet. In the years of the 1980s and 1990s I used computers in universities, at least one institute, and laboratories to produce some technical write-ups. Then in the year 2000 or 2001 I began to use a personal computer in a home.)
- Based on what I have read on the Internet I may have made matters worse by executing one of the commands “fmtutil –all” or “fmtutil-sys –all”. Will my TeX Live 2016 installation be repairable?
It appears that in TeX Live 2016 some environment variables beginning with ``TEX” in their file names have continued to be used. For example, I found that the variable TEXINPUTS was set in /etc/texlive.csh and texlive.sh and that in the file /etc/texmf/web2c/texmf.cnf the variables TEXMFDIST, TEXMFSYSVAR, TEXMFSYS, TEXMFHOME, TEXMFVAR, et cetera, were set, at least usually and ultimately to one or more directories.
Questions of possibly lesser importance at least at this stage of my investigation:
A1. Is it ill-advised to upgrade to TeX Live 2017 from installation software obtained from http://ctan.org/ on the Internet instead of waiting for openSUSE repositories to provide it? But doing this might not help me solve my present problem if an error in my TeX Live 2016 setup would be propagated into TeX Live 2017 following such an upgrade of TeX Live.
A2. If not, how would I make that upgrade in a way that would not harm my existing computer software in openSUSE?
B. Is there a way for me to efficiently save and later work with the names of hundreds of TeX Live 2016 software packages I have installed in order to efficiently make a fresh installation of those same software packages from TeX Live 2016 or TeX Live 2017, should it ever become necessary to do so? If not, installing hundreds of TeX Live software packages one at a time could be very time consuming; so instead of installing so many texlive-… software packages one at a time I suppose I could install a much shorter list of more-essential, texlive-…. software packages for use with pdflatex, bibtex, and maybe latex2html. But in this shorter way I might later discover that I would need to install additional texlive-… software packages, for example for certain types of fonts, if I would discover that a \usepackage{…} command in a LaTeX file would require a software package I would not yet have installed.
(I think we can understand how I have come to install so many TeX Live software packages in the following way.–When I read about an interesting capability of some TeX Live software package which I could imagine possibly using or want to have in case I would ever want to use it, I installed it, but then later did not use it. It’s a little like walking along a buffet line of food and putting everything that looks good to eat on one’s plate of food, but then later not eating all of that food. That would be wasteful and not be a good thing to do. The expression for this type of behavior is approximately “His eyes are bigger than his stomach.”)