Since publication of the article below, subsequent investigations with a member of the TeX Live team have identified the exact cause of the problem: An outdated version of GNU’s gawk command-line tool (used during compilation). I had been using version 3.1.7 of GNU’s gawk (supplied with the MSYS distribution I was using) but after updating it to version 4.0.2 the line-ending problem no longer arises. If you are using MSYS on Windows, and want to compile TeX Live…, check the version of gawk installed on your machine. As I say, you live and (re)learn…<\/p>\n
Just a short note to share the solution to a problem I experienced when trying to compile Tex Live from the C\/C++ source distribution… on Windows. I have a bit of relevant experience because I regularly compile LuaTeX from source and have built other TeX engines–including Knuthian TeX from raw WEB code and some versions of XeTeX.<\/p>\n
So, with that experience, I decided to have a go at building TeX Live from the source file distribution–it’s useful to be able to build and use the latest versions of TeX-related software. Using SVN (via the Tortoise SVN client) I checked out the TeX Live source directory and tried to build it using MinGW64\/MSYS64. I read through the notes in Unquestionably, TeX Live is a truly impressive work of considerable complexity and, of course, it should build OK on Windows–so I figured that the problem must be a relatively minor one to do with my setup. However, tracking it down initially felt like “looking for a needle in a haystack”, to quote a well-known English figure of speech. Well, after a couple of days I found the problem… line endings in some key text files! When I checked out the source via SVN some key files ( I discovered that the And yes, so far all the TeX-related programs I have tried to build have compiled successfully. This is not the first time I have been “bitten” through problems caused by Linux\/Widows line endings… so I guess you always live and (re)learn.<\/p>\n \ufeff<\/p>\n","protected":false},"excerpt":{"rendered":" Post-publication update: GNU gawk Since publication of the article below, subsequent investigations with a member of the TeX Live team have identified the exact cause of the problem: An outdated version of GNU’s gawk command-line tool (used during compilation). I had been using version 3.1.7 of GNU’s gawk (supplied with the MSYS distribution I was […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3794","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/3794","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3794"}],"version-history":[{"count":29,"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/3794\/revisions"}],"predecessor-version":[{"id":3823,"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/3794\/revisions\/3823"}],"wp:attachment":[{"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3794"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3794"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.readytext.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3794"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}README.2building<\/code> (supplied with the TeX Live source) and followed the example to build dvipdfm-x<\/code>. Running the Build\/configure scripts (using the --disable-all-pkgs<\/code> option) worked fine but, sadly, compilation failed with a cascade of errors… so I wanted to find out why.<\/p>\nconfig.h.in<\/code> and similar *.in<\/code> files) had been saved with Windows line endings (CR+LF) rather than Linux endings of LF only. Running the top-level TeX Live Build\/configure scripts generates a config.status<\/code> shell script file for each component\/sub-system that has to be compiled. As the config.status<\/code> scripts execute, they create a number of temporary files which are processed and deleted on-the-fly. To stop these temporary files being deleted (to assist my bug hunt) I used a simple trick of adding the line alias rm='echo'<\/code> at the start of one of the config.status<\/code> shell scripts (which are generated by configure<\/code>).<\/p>\nconfig.status<\/code> scripts generate a temporary file called defines.awk<\/code>–which is a script designed to be executed by the AWK program. The purpose of defines.awk<\/code> is to process “template” configuration files (called config.h.in<\/code> (and similar)) to generate various config.h<\/code> files that contain important settings (#define<\/code>s) detected during the configuration process (i.e., during the execution of configure<\/code>). These config.h<\/code> files vary for each program you are building and are essential for successful compilation. Well, it turned out that the defines.awk<\/code> script was failing to correctly parse the config.h.in<\/code> files (and similar) simply because the Windows line endings were causing a vital regular expression (in defines.awk<\/code>) to fail. This resulted in the config.h<\/code> files being a copy of config.h.in<\/code> because none of the text replacements had worked due to failure of the AWK regular expression. Not surprisingly, erroneous config.h<\/code> files caused the spectacular failure of compilation I experienced on my first attempt. Re-saving the config.h.in<\/code> files (and some other *.in<\/code> files) with Linux line endings seems to have solved the problems.<\/p>\n