Texlive build instructions are incorect

[Homer Simpson]

The texlive chapter needs some love WRT building from source and requires building asymptote seperately either in tree or standalone.

i would suggest that the --enable-shared option become recommended as opposed to optional besides building the binaries from source "cause you can and its cool" recompiling static bins using shared libs that are common shared libs is a nice thing to do in most cases when building by default it links against libraries statically.

1)The "optional" components are not used unless --with-system-XXXX is specified when calling configure.

--with-system-libgs --with-system-harfbuzz (Must be built with graphite2) --with-system-icu --with-system-teckit --with-system-graphite2 --with-system-zziplib --with-system-xpdf --with-system-poppler --with-system-cairo --with-system-pixman --with-system-gd --with-system-freetype2 --with-system-t1lib --with-system-libpng --with-system-zlib

a gottcha with this is that when configure runs the first lib it cant find will cause it to fail checking any further so check the output of configure.

the default behaviour is ALWAYS to build internal libs when building

2)CLISP is only required for building xindy this is not built by default and requires adding the following options

--enable-xindy --enable-xindy-rules --enable-xindy-doc

3)Some "effort" can be saved setting the following _prefix is recomended as /opt/texlive however the installer will install to /opt/texlive/2013 use of /opt/texlive/2013 needs to specified as prefix if this is where the "binary" live version is installed.

--prefix=_prefix (depends on install tl install) --includedir=/usr/include --libdir=/usr/(lib|lib64) --datarootdir=_prefix (not share to ensure compat with tl) --infodir=_prefix/texmf-dist/doc/info --mandir=_prefix/texmf-dist/doc/man --bindir=_prefix/bin/<ARCH-DIR as per tl>

setting these options allows a "Clean" install over the existing tl distribution replacing the files or running find/replace scripts. likewise use of --includedir --libdir puts the shared libs in the system dir's on install.

4)Additional options i used

--enable-etex --enable-shared --enable-ttf2pk2 --enable-xdv2pdf

the following "base" options --disable-native-texlive-build (for building shared) --enable-mktextex-default and --with-banner-add (suggested for 3d party builds) complete the "options"

asymptote

---

In the utils directory there is a dir for asymptote it needs to be configured and built independantly of texlive

./configure --prefix=_prefix --enable-texlive-build --enable-gc=system --datarootdir=_prefix/texmf-dist \

--infodir=_prefix/texmf-dist/doc/info --mandir=_prefix/texmf-dist/doc/man

use of --enable-gc=system is only to be used if gc is built with c++ support otherwise it will build a suitable gc in tree

the options are crafted to merge this build into the tl tree with make install as with the core source above.

a note could be added that a ls -lt _prefix/bin/<ARCH> will show any files not replaced at the bottom and should only contain some pre installed symlinks.

[ken@…]

I suspect that many (or even all) of the editors do not have experience with using tex. I remember that on the one occasion _I_ looked at it before, I found its build system impenetrable and I had no understanding of how to use it. This looks a useful list of things, but I have some questions and comments:

1. I guess it will be worth adding the --with-system- options, but mostly as *options* (different markup from the required/recommended commands), because it can be built without them. For zlib, it is part of LFS so we ought to use the system version by default.

2. In my (slightly old) local copy of the book, xwindows is marked as optional. I guess that might be required for some of these options to be useful ? I s'pose I can try to check that part, if I can find the space to try to build tex - I don't normally install all these possible deps.

3. Why would a builder want to install xindy ? I'm looking for more elaboration of what it enables the installed tex to do.

[ no comments on the configure options, at least until I try them! ]

4. Similarly, any explanations for the additional / base options, please, or do we have to google for them ?

5. In the same vein, why do you think it is worth building asymptote ? Also, I don't understand your sentence:

the options are crafted to merge this build into the tl tree with make install as with the core source above.

Do you, perhaps, intend that asymptote should be separately configured after, or before, the main configure, and if so will the main "make; make install" also deal with asymptote - or does it also need those commands to be run in its directory ?

6. Finally, any _simple_ "idot's guide to using tex" references to give something that an editing monkey can use to see that the installed tex works, please ?

I guess this is something I could look at for one of my current 7.4 systems, but I really know nothing at all about tex (except that people, mainly academics, use it for formatting posh text) so I need some further guidance if I'm going to spend time on this. Thanks.

[Pierre Labastie]

I do use TeX, and could provide some sample source files for testing. I do not think I could get acquainted to the build system for tackling the above before the February 15th freeze (lack of time).

Asymptote is a script language for vector graphics and supersedes metapost. It may not be wanted by all people using TeX, but it produces nice graphics.

[Homer Simpson]

I guess it will be worth adding the --with-system- options, but mostly as *options* (different markup from the required/recommended commands), because it can be built without them. For zlib, it is part of LFS so we ought to use the system version by default.

The source of all these dependancies is included and will be built and linked statically and will not be used "optionally" this is a downside and has a precident in ghostscript where it bundles everything. so no they not optional but allow saving space/resources in normal operation, this is only if --enable-shared is used as by default it will link statically against system libs too.

In my (slightly old) local copy of the book, xwindows is marked as optional. I guess that might be required for some of these options to be useful ? I s'pose I can try to check that part, if I can find the space to try to build tex - I don't normally install all these possible deps.

Indeed --without-x is a valid option and there are X libs linked in looking at ldd * if these are not built they wont replace the tug provided binaries.

Why would a builder want to install xindy ? I'm looking for more elaboration of what it enables the installed tex to do.

Its a index creator for latex further than that i know it is supplied by tug but not built without enableing it at configure time. the optional requirements in the book refer to CLISP this is the only module that requires it.Once again not building it will leave the tug build in place.

Similarly, any explanations for the additional / base options, please, or do we have to google for them

Google is so yesterday duckduckgo is the new black ... I call them base options as they already described and outlined in the book. i have pasted the --help bits here for completeness

--disable-native-texlive-build

do not build for the TeX Live binary distribution

--enable-mktextex-default run mktextex if TeX source missing --with-banner-add=STR add STR to version string appended to banner lines

In the same vein, why do you think it is worth building asymptote ?

As noted above if its not built its not replaced a static tug supplied binary will remain intact this is upto the builder.

"the options are crafted to merge this build into the tl tree with make install as with the core source above."

Basically you start off with a tug install in a directory building from source replaces the tug binaries they cant be put into _prefix/bin as they reference ../../texmf-dist the layout of tug is not LFS so use of the layout options is to on make install replace the files already there transparently not requiring extra steps currently in the book.

Do you,

perhaps, intend that asymptote should be separately configured after, or before, the main configure, and if so will the main "make; make install" also deal with asymptote - or does it also need those commands to be run in its directory ?

one option is to open a chapter for it this im not in favor of as it will require refering to this chapter and using the source again or downloading it as a standalone off sourceforge.

if required cd to the dir run new configure / make / install something along the lines if you call now you will get a ......

Finally, any _simple_ "idot's guide to using tex" references to give something that an editing monkey can use to see that the installed tex works, please ?

I use it to generate doxygen pdf's and it does real good job at it. a quick test will be to grab flex source build it then remove docs/flex.pdf and build again it should build the pdf. latex is used if detected in a supprising amount of packages and if present when a book build begins will give more valuable /usr/share/docs.

Running the tex installer as per the book is required it pulls 1.6G-2G of tarballs and installs them the majority of this is fonts followed by docs on my pc 3.5G was dumped into the hdd.

at this point setting PATH will have you up and running on the tug binarires for the masochists who want 100% LFS and no 3d party binaries or those who are heavy users and 300 static bins is using more than it should the source build is the solution.

[ken@…]

Thanks! I must be be a bit slow this week. As you say, like ghostscript. So, they all ought to be recommended. I've got a few other things to do, so it will probably be some time before I make progress on this.

[Homer Simpson]

FYI ive tested with cross compiling from x86_64 -> {i686,arm} and it works you cannot cross compile xindy. however i have a complex build enviroment that quite frankly is completely bodged.

The great thing with this is you can cp a working XXX arch /opt/texlive to YYY arch rebuild and you have a working version saving a 2Gb download (remember to mv /opt/texlive/bin/XXX-linux to /opt/texlive/YYY-linux before installing).

as a ARM linux user [Google Chromebook] i build on a intel (i7 3770) almost a complete arm distribution there somethings i cant build properly even icedtea with a bit of persuasion can be built. the trick is using a "hybrid" build root where it has glibc/zlib/gcc/make/bash/.... all from the native system and makes use of qemu/binutils_misc so when i chroot /build/arm uname -a [arm bin reports arm7l gcc -v will reveal its a x86_64 binary targeting arm. this allows me to build much faster than on a native arm CPU and use the threads of the native system. in this case there was no need to chroot and build if there any programs executed during build they would succeed under qemu.

[ken@…]

Problem: If we recommend GD, t1lib, ZZIPlib, TECkit, Graphite (also CLISP) those packages need to be added to the book. I'm reluctant to do that if they are only used by TeX. Also, Graphite seems to have moved to ​http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_home

[Homer Simpson]

Good point that the Optionals are already in the list for texlive as "orphans" of these depends GD has the only benifit been added to the book as its is a optional dependancy to glibc required to build memusagestat and graphviz (not listed currently in book as dependancy).

if you leave out graphite from texlive you need to leave out harfbuzz these are to render complex fonts and may be worth a mention for those in the north east corner of the world building graphite is straightforward with cmake (may require -DLIB_SUFFIX=64 to put libs into /lib64) and then harfbuzz is built adding --with-graphite2. id sugest a note on the harfbuzz page that for these fonts graphite can be installed (libreoffice/mozilla are consumers).

the others you listed are indeed only benificial to texlive.clisp is the problem child it depends on libsigsegv and optional/recomended libffcall (not libffi) this is a orphan with CVS only download on GNU savannah.

for the average builder this adds too much complexity with no functional gain and marginal overall gain on resources saved in using self built vs vendor supplied binaries (+/- 600k for i686 looking at size of .a files).

[ken@…]

Grrr! I hate TeX. Gave it a build which appeared to work (some different switches, and not building in the source directory). Before I tried to install that, I decided to test the binary version from the installer. To start with, flex.pdf was recreated, but evince was unable to display it. Hacked around with some simple TeX, got that working, moved on to "simple" latex - almost everything I found online did not work, but I eventually got a random page which sort of showed pdflatex was working. Went back to flex, this time I generated the pdf and evince displayed it ok. Ostensibly, nothing different in either my PATH or what was installed.

Will come back to this when I've done graphite2.

[ken@…]

A note in passing - the installer has been updated, but not the source. That means that some of the scripts (shell, perl) show newer svn revisions, but the install from source will then overwrite them with the older versions.

[Homer Simpson]

Indeed this is complicated by the installer changing on a "daily" basis the text needs to read "will change" not "may change" see comments from tug bellow.

the tlmngr script will update the system possibly called from cron or via the GUI [pl/TK script and a further dependancy (cpan -i Tk).

the source is updated less often and rebuilt it seems less frequently looking at the file dates for the arch files the archive.

seems like its well maintained perhaps a if you update the archive check for and reinstall the source.

as tex is modular and mature i see it as updating any other package as the installed files are from the latest source. the other option is to not install the support files only the built bins this could have problems too in that the files on the system may be working with a slightly patched version of code and fail. i personally like to install like with like or push the changes as a patch and then build it. i think both scenarios are valid and at the builders descression if you want to just use it install and leave the LFS "users" are genrally more advanced and are not looking for ubuntu/redhat and want to DIY it.

this is a mail i got on the tldistro list...looking at the page

---

It looks sensible enough to me. Do you have a special reason to enable mktextex by default? Just wondering.

BTW, the install-tl-* directory name certainly does change whenever we remake it (i.e., daily), not just "may" change.

best, k

---

ive left mktextex option off and it builds fine

--enable-mktextex-default run mktextex if TeX source missing

its in the book currently and does not make sense indeed.

[ken@…]

Thanks for that, particularly for confirming my guess that mktextex is unnecessary.

A lot to think about. My current plan is to deal with the --with-system part, then update my own general buildscripts, build a new LFS, and see what happens with the installer before anything from a desktop has been installed. And also to confirm if anything there links to system libraries.

[ken@…]

The main part of the from-source changes are now in. Still to do: confirm the runtime dependencies for tl-installer. Add the switches for xindy. Build asy.

[Homer Simpson]

Here are the dependancies found in the from source build only ill do some comparisions when i have a moment (kids/missus claim im always having a moment).

this method is not perfect vpx is a dependancy of GD texlive might never use vpx but its pulled in anyway even though it would run fine againset a GD not linked with VPX ....

i normally build -> staging (DESTDIR) -> tar when all built convert the tar files to RPM then use yum/rpm to find conflicts / missing dependancies and some other cool things cause im "lazy".

the following perl modules are not "default" perl 5.18 or bundled (Date::Format Date::Parse Digest::SHA1 File::Which HTML::FormatText HTML::TreeBuilder Spreadsheet::ParseExcel Tk WWW::Mechanize)

/bin/bash /bin/sh /bin/sh /usr/bin/env /usr/bin/perl /usr/bin/python

libICE.so.6()(64bit) libSM.so.6()(64bit) libTECkit.so.0()(64bit) libX11.so.6()(64bit) libXau.so.6()(64bit) libXaw.so.7()(64bit) libXdmcp.so.6()(64bit) libXext.so.6()(64bit) libXmu.so.6()(64bit) libXpm.so.4()(64bit) libXt.so.6()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.7)(64bit) libcairo.so.2()(64bit) libcrypt.so.1()(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libexpat.so.1()(64bit) libfontconfig.so.1()(64bit) libfreetype.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgd.so.3()(64bit) libgraphite2.so.3()(64bit) libgs.so.9()(64bit) libharfbuzz.so.0()(64bit) libicudata.so.52()(64bit) libicui18n.so.52()(64bit) libicuio.so.52()(64bit) libicuuc.so.52()(64bit) libjpeg.so.8()(64bit) libkpathsea.so.6()(64bit) liblzma.so.5()(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libnsl.so.1()(64bit) libpixman-1.so.0()(64bit) libpng16.so.16()(64bit) libpng16.so.16(PNG16_0)(64bit) libpoppler.so.43()(64bit) libptexenc.so.1()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.15)(64bit) libstdc++.so.6(GLIBCXX_3.4.5)(64bit) libt1.so.5()(64bit) libtiff.so.5()(64bit) libutil.so.1()(64bit) libuuid.so.1()(64bit) libvpx.so.1()(64bit) libxcb.so.1()(64bit) libz.so.1()(64bit) libzzip-0.so.13()(64bit)

perl perl perl perl perl perl(Config) perl(Cwd) perl(Date::Format) perl(Date::Parse) perl(Digest::MD5) perl(Digest::SHA1) perl(Encode) perl(English) perl(Env) perl(Exporter) perl(File::Basename) perl(File::Copy) perl(File::Find) perl(File::Path) perl(File::Spec) perl(File::Spec::Functions) perl(File::Temp) perl(File::Which) perl(File::stat) perl(FileHandle) perl(FindBin) perl(Getopt::Long) perl(Getopt::Std) perl(HTML::FormatText) perl(HTML::TreeBuilder) perl(IO::File) perl(List::Util) perl(Math::Trig) perl(POSIX) perl(Pedigree) perl(Pod::Man) perl(Pod::Usage) perl(Spreadsheet::ParseExcel) perl(TeXLive::TLConfFile) perl(TeXLive::TLConfig) perl(TeXLive::TLDownload) perl(TeXLive::TLPDB) perl(TeXLive::TLPOBJ) perl(TeXLive::TLPaper) perl(TeXLive::TLUtils) perl(TeXLive::TLWinGoo) perl(Tk) perl(Tk::Dialog) perl(Tk::NoteBook) perl(WWW::Mechanize) perl(autodie) perl(constant) perl(integer) perl(only) perl(pdfTeX) perl(strict) perl(utf8) perl(vars) perl(warnings) rpmlib(CompressedFileNames) rpmlib(PayloadFilesHavePrefix)

[ken@…]

Which version of libsigsegv are you using ? I installed 2.10 in /usr, but clisp's strange configure script fails to find it, and keeps telling me to install 2.8. Normally I can grok a configure script enough to get an idea, but the version in clisp's src/configure is too different from anything I've ever seen.

I note that although the top-level configure script implies libsigsegv is a really good idea, none of the distros I've looked at seem to use it.

Will try without it.

[ken@…]

Hmm, segfault in 'make check'. Looking further, there are what purport to be build instructions for clisp at the end of ​https://www.tug.org/svn/texlive/trunk/Build/source/utils/README?view=markup using static version of all the libs. Colour me disgusted.

[Homer Simpson]

Hi i use 2.10 with CFG_FAULT=fault-linux-i386.h" as a option passed to configure and installed to /usr.

Clisp is built with "--srcdir=../ --with-libsigsegv-prefix=/usr" in a build dir in the root i found that the build tree is "poluted" and indeed the "configure" script is not standard autoconf.

the motivation for the "static" clisp build is similar to -enable-static-lib(gcc|stdc) options in that the runtime does not need to be shiped to the end user personally i disagree with doing this.

im not a fan of static builds at all that said they have there place but almost always are abused some of the worst offenders are propriatary vendors trying to "support" FOSS.

TUG releases static builds for a "live" up and get going and kudos to them for releasing the source to build your own sure its a tangled mess but in context with almost 4Gb taken by tex this is a big chunk of the entire build bloated as hell over time. perhaps we need to see tex as a distro in a distro and not just a package almost a ecosystem of its own.

[ken@…]

Again, thanks, and ignore my rant about the static libs in the TeX website.

Your fault-linux-i386.h looks as if it is specific to i?86. For x86_64 I assume it picks up fault-linux.h, the alternative would be fault-linux-x86_64-old.h which seems unlikely.

I've now got clisp to build on x86_64 with

mkdir build
cd build
../configure --srcdir=../ --prefix=/usr --with-libsigsegv-prefix=/usr

and that _does_ find libsigsegv. Doesn't help with the testsuite, that still fails with a segfault at the end.

I can confirm that adding your switches for xindy:

--enable-xindy --enable-xindy-rules --enable-xindy-doc

enables me to build the tex2xindy binary, and also the file xindy.mem (no idea what that is), but it did NOT create xindy.run which is also a binary from the installer.

Full disclosure - I only did a DESTDIR install for this.

Will take a look at asy later.

[ken@…]

I added asy in r12712, so everything except xindy is now in the book. Returning to blfs-book for future consideration of adding xindy and its dep(s).

Please note that although the testsuite for clisp failed for me, that might not be critical, or might be fixed if yet another package is built.

The real showstoppers for me are my lack of a suitable document on which to test that xindy's indexing works, and the apparent failure to install a new xindy.run from the source.

[ken@…]

I've created #4719 so that we don't forget about xindy. Closing this ticket.