From marcpenninga at gmail.com Fri Jul 4 11:14:13 2025 From: marcpenninga at gmail.com (Marc Penninga) Date: Fri, 4 Jul 2025 12:14:13 +0300 Subject: [tlbuild] =?utf-8?b?RXJyb3IgaW4g4oCcQnVpbGRpbmcgVGVYIExpdmXigJ0g?= =?utf-8?q?docs?= Message-ID: <3ea61c7f-952d-4d2c-bc11-3eb602900660@gmail.com> Hello all, Section 4.5, ?Build one engine? of the ?Building TeX Live? doc claims that > The first make run will configure everything, and even build the libraries, even though the packages are disabled. (doc/tlbuild.texi, lines 597--598). I think this is incorrect; while it does *configure* everything, it doesn't actually *build* any libraries, not even those required by the engine being built! When attempting to build luahbtex, I found I had to manually trigger the building of the dependencies (libs/harfbuzz and libs/pplib), even with the --enable-luahbtex option to configure. In the end, the following variation of the example from this section worked for me: mkdir -p Work; cd Work ../configure --without-x --disable-shared --disable-all-pkgs \ --enable-luahbtex --disable-synctex --disable-xetex \ --enable-missing -C CFLAGS=-g CXXFLAGS=-g make for lib in harfbuzz pplib; do (cd libs/"$lib"; make); done cd texk/web2c make luahbtex Best regards, Marc From karl at freefriends.org Fri Jul 4 22:16:53 2025 From: karl at freefriends.org (Karl Berry) Date: Fri, 4 Jul 2025 14:16:53 -0600 Subject: [tlbuild] Error in “Building TeX Live” docs In-Reply-To: <3ea61c7f-952d-4d2c-bc11-3eb602900660@gmail.com> Message-ID: <202507042016.564KGrIR568088@freefriends.org> Hi Marc - thanks much for the report and the winning invocation. think I the luatex configure might behave differently in this regard than the other engines. I'll look into it. --thanks again, karl. From andreas_tex at freenet.de Wed Jul 23 19:30:27 2025 From: andreas_tex at freenet.de (Andreas Scherer) Date: Wed, 23 Jul 2025 19:30:27 +0200 Subject: [tlbuild] Debian Buster EOL Message-ID: <3eb75e6a-30ae-4d66-b73a-5a1516bd7b40@freenet.de> Dear list, As of recent commits it became apparent that Debian Buster has been superseded by Debian Bullseye: https://www.debian.org/releases/buster/ Maybe it's a good idea to upgrade the i386-linux build environment on Github to a supported system. At this time, the builds on Buster, well, ... go bust. Best, Andreas From norbert at preining.info Wed Jul 23 20:45:45 2025 From: norbert at preining.info (Norbert Preining) Date: Wed, 23 Jul 2025 20:45:45 +0200 Subject: [tlbuild] Debian Buster EOL In-Reply-To: <3eb75e6a-30ae-4d66-b73a-5a1516bd7b40@freenet.de> References: <3eb75e6a-30ae-4d66-b73a-5a1516bd7b40@freenet.de> Message-ID: Hi Andreas, > As of recent commits it became apparent that Debian Buster has been > superseded by Debian Bullseye: https://www.debian.org/releases/buster/ Yes, well aware of that. > Maybe it's a good idea to upgrade the i386-linux build environment on Github > to a supported system. At this time, the builds on Buster, well, ... go > bust. We always try to build on the oldest possible system to get optimal compatibility. glibc changes are unfortunately far too common and destroy compatibility. When building goes "bust" as you said, and there is no other way, then we will update to bullseye or some other distribution. Best regards Norbert -- DI Dr Norbert Preining https://www.preining.info arXiv / Cornell University + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From hille42 at web.de Thu Aug 28 23:43:41 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Thu, 28 Aug 2025 23:43:41 +0200 Subject: [tlbuild] texlive-source: zziplib on i386 Message-ID: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> Hello Karl, recently I've packaged the texlive-source (TL2025) for Debian and noticed in initial attempt that it fails to compile on i386 (probably on hurd-i386 too, but this is not yet proven) [1]. To fix / work around that issue I started to use the zzlib bundled with the texlive-sources in (hurd-)i386 [2]. Is there a patch applied to the zzlib in the texlive-sources (I did not find anything in the Changelog)? If yes, would it make sense to forward it to zzlib upstream and apply it there? Many thanks! Hilmar [1] https://buildd.debian.org/status/fetch.php?pkg=texlive-bin&arch=i386&ver=2025.20250727.75242%2Bds-1&stamp=1753770029&raw=1 [2] https://buildd.debian.org/status/fetch.php?pkg=texlive-bin&arch=i386&ver=2025.20250727.75242%2Bds-3&stamp=1754433760&raw=1 -- sigfault -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From norbert at preining.info Fri Aug 29 00:07:31 2025 From: norbert at preining.info (Norbert Preining) Date: Fri, 29 Aug 2025 00:07:31 +0200 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> References: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> Message-ID: Hi Hilmar, > Is there a patch applied to the zzlib in the texlive-sources (I did not find > anything in the Changelog)? If yes, would it make sense to forward it to > zzlib upstream and apply it there? There is, see: https://git.texlive.info/texlive/tree/Build/source/libs/zziplib/TLpatches I guess that this is necessary patch-01-header @@ -16,6 +16,7 @@ #include #include #include +#include #ifdef __cplusplus extern "C" { Best regards Norbert -- DI Dr Norbert Preining https://www.preining.info arXiv / Cornell University + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From hille42 at web.de Fri Aug 29 00:08:45 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Fri, 29 Aug 2025 00:08:45 +0200 Subject: [tlbuild] texlive-source: building detex Message-ID: Hello, another one: we noticed that building detex fails on single job machines, b/c the subdir, where the compiled files should be written to, does not exist when gcc is called [1] [2]. I applied the patch [3] as suggested in the last message in the bug and the issue is solved. Consider to apply the patch to tl-sources. Thanks! Hilmar [1] https://buildd.debian.org/status/fetch.php?pkg=texlive-bin&arch=hurd-amd64&ver=2025.20250727.75242%2Bds-4&stamp=1755303272&raw=1 [2] https://bugs.debian.org/1111524 [3] https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/detex_single_job.diff -- sigfault -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From hille42 at web.de Fri Aug 29 00:19:31 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Fri, 29 Aug 2025 00:19:31 +0200 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: References: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> Message-ID: <0c572826-e180-4a7f-bbaf-00c94de21639@web.de> Am 29.08.2025 um 00:07 schrieb Norbert Preining: Hello Norbert, >> Is there a patch applied to the zzlib in the texlive-sources (I did not find >> anything in the Changelog)? If yes, would it make sense to forward it to >> zzlib upstream and apply it there? > > There is, see: https://git.texlive.info/texlive/tree/Build/source/libs/zziplib/TLpatches > > I guess that this is necessary patch-01-header > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > #ifdef __cplusplus > extern "C" { > Hmm. The linking fails with /usr/bin/ld: libluamisc.a(libluamisc_a-luazip.o): in function `zip_openfile': luazip.c:(.text+0x654): undefined reference to `zzip_open_ext_io64' The function declaration is in zzip/zzip.h, not in the additional zzip/zzip32.h. Are you sure? Hilmar -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From norbert at preining.info Fri Aug 29 00:24:16 2025 From: norbert at preining.info (Norbert Preining) Date: Fri, 29 Aug 2025 00:24:16 +0200 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: <0c572826-e180-4a7f-bbaf-00c94de21639@web.de> References: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> <0c572826-e180-4a7f-bbaf-00c94de21639@web.de> Message-ID: On Fri, 29 Aug 2025, Hilmar Preu?e wrote: > zzip/zzip32.h. Are you sure? No, but this is what is patched into the sources of TL. Maybe the other patch in the linked directory - but doesn't feel like. Could also be a gcc issue (too new a version) - we generally build with very old gcc. Best regards Norbert -- DI Dr Norbert Preining https://www.preining.info arXiv / Cornell University + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From norbert at preining.info Fri Aug 29 00:25:29 2025 From: norbert at preining.info (Norbert Preining) Date: Fri, 29 Aug 2025 00:25:29 +0200 Subject: [tlbuild] texlive-source: building detex In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025, Preu?e, Hilmar via tlbuild wrote: > another one: we noticed that building detex fails on single job machines, Do you mean Build -j1 fails? I am surprised ... I think I have built TL many times with -j1. Best regards Norbert -- DI Dr Norbert Preining https://www.preining.info arXiv / Cornell University + IFMGA Guide + TU Wien + TeX Live GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From patrick.gundlach at gmail.com Fri Aug 29 11:40:52 2025 From: patrick.gundlach at gmail.com (Patrick Gundlach) Date: Fri, 29 Aug 2025 11:40:52 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) Message-ID: Hello all, probably an FAQ, but my quick research didn't give any results. I'd like to cross compile LuaTeX for Windows on Linux (in a Docker environment). These are the packages on my linux host that I install: apt-get install build-essential git curl gcc-mingw-w64 gcc-aarch64-linux-gnu parallel ruby apt-utils liblua5.3-dev This is the command line I use at the top level directory ./build.sh --nojit --luahb --nostrip --mingw64 This fails and the last lines are /usr/bin/bash ./libtool --tag=CXX --mode=link g++ -Wall -Wunused -Wreturn-type -Wno-write-strings -Wno-unknown-pragmas -mtune=nocona -g -O3 -fno-lto -fno-use-linker-plugin -export-dynamic -fno-lto -fno-use-linker-plugin -static-libgcc -static-libstdc++ -o luahbtex.exe luatexdir/luahbtex-luatex.o mplibdir/luahbtex-lmplib.o libluatex.a libluahbtexspecific.a libluatex.a libff.a libluamisc.a libluasocket.a libluaffi.a libluaharfbuzz.a /luatex/build-windows64/libs/lua53/ libtexlua53.la libmplibcore.a /luatex/build-windows64/libs/zziplib/libzzip.a /luatex/build-windows64/libs/libpng/libpng.a /luatex/build-windows64/libs/harfbuzz/libharfbuzz.a /luatex/build-windows64/libs/graphite2/libgraphite2.a /luatex/build-windows64/libs/pplib/libpplib.a /luatex/build-windows64/libs/zlib/libz.a lib/lib.a /luatex/build-windows64/texk/kpathsea/libkpathsea.la libmputil.a libunilib.a libmd5.a -lwsock32 -lws2_32 libtool: link: g++ -Wall -Wunused -Wreturn-type -Wno-write-strings -Wno-unknown-pragmas -mtune=nocona -g -O3 -fno-lto -fno-use-linker-plugin -fno-lto -fno-use-linker-plugin -static-libgcc -static-libstdc++ -o luahbtex.exe luatexdir/luahbtex-luatex.o mplibdir/luahbtex-lmplib.o -Wl,--export-all-symbols libluahbtexspecific.a libluatex.a libff.a libluamisc.a libluasocket.a libluaffi.a libluaharfbuzz.a /luatex/build-windows64/libs/lua53/.libs/libtexlua53.a libmplibcore.a /luatex/build-windows64/libs/zziplib/libzzip.a /luatex/build-windows64/libs/libpng/libpng.a /luatex/build-windows64/libs/harfbuzz/libharfbuzz.a /luatex/build-windows64/libs/graphite2/libgraphite2.a /luatex/build-windows64/libs/pplib/libpplib.a /luatex/build-windows64/libs/zlib/libz.a lib/lib.a /luatex/build-windows64/texk/kpathsea/.libs/libkpathsea.a libmputil.a libunilib.a libmd5.a -lwsock32 -lws2_32 /usr/bin/ld: unrecognized option '--export-all-symbols' /usr/bin/ld: use the --help option for usage information collect2: error: ld returned 1 exit status make: *** [Makefile:8110: luahbtex.exe] Error 1 lua(jit)tex binary not stripped -rwxr-xr-x 1 root root 40430325 Aug 29 09:38 build-windows64/texk/web2c/luatex.exe ls: cannot access 'build-windows64/texk/web2c/luahbtex.exe': No such file or directory Any hints? Any information that I should provide? This is the LuaTeX repository: https://gitlab.lisn.upsaclay.fr/texlive/luatex/-/tree/f3b89e4f88bc84de184e2cd1c08f34407e386ed3 Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From hille42 at web.de Fri Aug 29 17:08:07 2025 From: hille42 at web.de (=?UTF-8?Q?Hilmar_Preu=C3=9Fe?=) Date: Fri, 29 Aug 2025 17:08:07 +0200 (GMT+02:00) Subject: [tlbuild] texlive-source: building detex In-Reply-To: References: Message-ID: <0075f42e-0539-46d0-a09e-4229cd85d68b@web.de> Hello, Yes, exactly. I'm able to reproduce the issue on my rasbpi5, when calling ./debian/rules build. I did the build in an unstable chroot. As mentioned in the pull request the issue could have been triggered by a change in "make" so make sure your version of make is up to date. Hilmar 29.08.2025 00:25:31 Norbert Preining : > On Fri, 29 Aug 2025, Preu?e, Hilmar via tlbuild wrote: >> another one: we noticed that building detex fails on single job machines, > > Do you mean > ??? Build -j1 > fails? I am surprised ... I think I have built TL many times with -j1. > > Best regards > > Norbert > > -- > DI Dr Norbert Preining??????????????????????? https://www.preining.info > arXiv / Cornell University?? +?? IFMGA Guide?? +?? TU Wien? +? TeX Live > GPG: 0x860CDC13?? fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From luigi.scarso at gmail.com Sat Aug 30 09:24:01 2025 From: luigi.scarso at gmail.com (luigi scarso) Date: Sat, 30 Aug 2025 09:24:01 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 at 15:59, Patrick Gundlach wrote: > Hello all, > > probably an FAQ, but my quick research didn't give any results. > > I'd like to cross compile LuaTeX for Windows on Linux (in a Docker > environment). > > These are the packages on my linux host that I install: > > apt-get install build-essential git curl gcc-mingw-w64 > gcc-aarch64-linux-gnu parallel ruby apt-utils liblua5.3-dev > > This is the command line I use at the top level directory > > ./build.sh --nojit --luahb --nostrip --mingw64 > > This fails and the last lines are > > /usr/bin/bash ./libtool --tag=CXX --mode=link g++ -Wall -Wunused > It should be /usr/bin/bash ./libtool --tag=CXX --mode=link x86_64-w64-mingw32-g++ -Wall -Wunused so very likely you have not installed the c++ compiler from mingw. Under ubuntu I have both g++-mingw-w64-x86-64-win32 and g++-mingw-w64-x86-64-posix, default win32; Google for posix vs win32 and also "mingw-w64 ucrt" where the ucrt is the c runtime used from windows 10 As an alternative https://github.com/mstorsjo/llvm-mingw/releases -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.gundlach at gmail.com Sat Aug 30 12:08:30 2025 From: patrick.gundlach at gmail.com (Patrick Gundlach) Date: Sat, 30 Aug 2025 12:08:30 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: References: Message-ID: so very likely you have not installed the c++ compiler from mingw. > Under ubuntu I have both g++-mingw-w64-x86-64-win32 > and g++-mingw-w64-x86-64-posix, default win32; > after apt install g++-mingw-w64, it compiles. Next step: try out the binaries ... Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.gundlach at gmail.com Sat Aug 30 16:37:24 2025 From: patrick.gundlach at gmail.com (Patrick Gundlach) Date: Sat, 30 Aug 2025 16:37:24 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: References: Message-ID: > > > > after apt install g++-mingw-w64, it compiles. Next step: try out the > binaries ... > seems to work fine on arm64 Windows. Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From luigi.scarso at gmail.com Sat Aug 30 17:55:51 2025 From: luigi.scarso at gmail.com (luigi scarso) Date: Sat, 30 Aug 2025 17:55:51 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 at 16:37, Patrick Gundlach wrote: > >> >> after apt install g++-mingw-w64, it compiles. Next step: try out the >> binaries ... >> > > seems to work fine on arm64 Windows. > > Patrick > > Hm, which toolchain ? aarch64-w64-mingw32 or x86_64-w64-mingw32 ? In the latter case, there should be a sort of translation so you should be able to compare the pages per second (eg. compile the luatex manual). -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Sat Aug 30 22:22:09 2025 From: karl at freefriends.org (Karl Berry) Date: Sat, 30 Aug 2025 14:22:09 -0600 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: Message-ID: <202508302022.57UKM9Os084151@freefriends.org> Hi Patrick - just to mention for the future, I believe dev-luatex at ntg.nl is the best place to report build problems in the luatex repo. The people on tlbuild mostly only use the TL repo. Even though, as you've seen, Luigi is subscribed to this list too :). Thanks, Karl From patrick.gundlach at gmail.com Sat Aug 30 22:26:05 2025 From: patrick.gundlach at gmail.com (Patrick Gundlach) Date: Sat, 30 Aug 2025 22:26:05 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: <202508302022.57UKM9Os084151@freefriends.org> References: <202508302022.57UKM9Os084151@freefriends.org> Message-ID: Karl Berry schrieb am Sa. 30. Aug. 2025 um 22:22: > Hi Patrick - just to mention for the future, I believe dev-luatex at ntg.nl > is the best place to report build problems in the luatex repo. The > people on tlbuild mostly only use the TL repo. Even though, as you've > seen, Luigi is subscribed to this list too :). Hello Karl, I thought that the build system is taken from TeXlive, that is why I asked here. Thank you for pointing me in the right direction. Patrick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Sat Aug 30 23:32:19 2025 From: karl at freefriends.org (Karl Berry) Date: Sat, 30 Aug 2025 15:32:19 -0600 Subject: [tlbuild] texlive-source: building detex In-Reply-To: Message-ID: <202508302132.57ULWJut088417@freefriends.org> Hi Hille, Samuel, https://bugs.debian.org/1111524 https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/detex_single_job.diff ... BUILT_SOURCES = detex-src/$(am__dirstamp) Ok, committed (TL r76190), but I have questions. 1) what changed that this bug is now being provoked? Not anything in TL or Automake (for years), as far as I know. 2) Why do you patch detex.l in the first place? Can we install that patch? 3) Speaking as an Automake maintainer, I'd like to fix the real bug, but it's hard to work on anything in the midst of the complex TL build. Can you make a small reproducible test that I could work on in Automake? 4) At first glance, the proximate cause of the problem seems to be ylwrap, rather than the Automake rules discussed in https://lists.gnu.org/archive/html/bug-automake/2017-06/msg00005.html, etc. If ylwrap figures out the dirname of the target file and creates it (as in the change below), instead of assuming it exists, does that solve the problem? In the detex-src source directory, I tried running /tmp/ylwrap detex.l lex.yy.c foo/baz.c -- flex and it failed without the change below (same error message as yours), but succeeded with it. I admit I'm unsure how all the parts are interacting. --thanks, karl. --- Build/source/build-aux/ylwrap 2024-08-18 14:08:31.117633000 -0700 +++ /tmp/ylwrap 2025-08-30 14:25:56.992904605 -0700 @@ -198,2 +198,5 @@ fi + + target_dirname=`get_dirname $target` + test -d "$target_dirname" || mkdir -p "$target_dirname" From tex at maxchernoff.ca Sun Aug 31 06:03:03 2025 From: tex at maxchernoff.ca (Max Chernoff) Date: Sat, 30 Aug 2025 22:03:03 -0600 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: References: Message-ID: <2325394fceb37be5d6a13942cd9bc941413fb3c0.camel@maxchernoff.ca> Hi Patrick, On Fri, 2025-08-29 at 11:40 +0200, Patrick Gundlach wrote: > I'd like to cross compile LuaTeX for Windows on Linux (in a Docker > environment). Back in March, I built all the TL programs with mingw on Fedora 41 (gcc 14.2.1); I needed the following packages: awk fontconfig-devel gcc-c++ gzip mingw64-fontconfig mingw64-fontconfig-static mingw64-gcc mingw64-gcc-c++ mingw64-libstdc++ perl-File-Find perl-interpreter tar xz the following patch: diff --git a/libs/zziplib/zziplib-src/zzip/plugin.h b/libs/zziplib/zziplib-src/zzip/plugin.h index b4b39722..95e622b9 100644 --- a/libs/zziplib/zziplib-src/zzip/plugin.h +++ b/libs/zziplib/zziplib-src/zzip/plugin.h @@ -39,12 +39,20 @@ extern "C" { struct zzip_plugin_io { /* use "zzip_plugin_io_handlers" in applications !! */ int (*open)(zzip_char_t* name, int flags, ...); int (*close)(int fd); + #ifdef WIN32 + int (*read)(int fd, void * buf, unsigned int len); + #else zzip_ssize_t (*read)(int fd, void* buf, zzip_size_t len); + #endif zzip_off_t (*seeks)(int fd, zzip_off_t offset, int whence); zzip_off_t (*filesize)(int fd); long sys; long type; + #ifdef WIN32 + int (*write)(int fd, const void * buf, unsigned int len); + #else zzip_ssize_t (*write)(int fd, _zzip_const void* buf, zzip_size_t len); + #endif }; typedef union _zzip_plugin_io --- a/texk/texlive/windows_wrapper/runscript_dll.c +++ b/texk/texlive/windows_wrapper/runscript_dll.c @@ -15,6 +15,10 @@ #define MAX_MSG 2*MAX_PATH #define DIE(...) { _snprintf( msg_buf, MAX_MSG - 1, __VA_ARGS__ ); goto DIE; } +#ifdef __MINGW32__ +_CRTIMP int __cdecl __getmainargs(int * _Argc, char *** _Argv, char ***_Env, int _DoWildCard, int x*_StartInfo); +#endif + char module_name[] = "runscript.dll"; char script_name[] = "runscript.tlu"; char texlua_name[] = "texlua"; // just a bare name, luatex strips the rest anyway diff --git a/texk/web2c/texprofdir/texprof.w b/texk/web2c/texprofdir/texprof.w index f590c599..a9a8df0b 100644 --- a/texk/web2c/texprofdir/texprof.w +++ b/texk/web2c/texprofdir/texprof.w @@ -31263,7 +31263,7 @@ with a tread specific clock otherwise. #endif #else /* guess a default */ -#ifdef _WIN32 +#if defined(_WIN32) && !defined(__MINGW32__) time_error=timespec_get(&ts, TIME_UTC); #else time_error=clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts); and the following command line: ../configure --host=x86_64-w64-mingw32 --build=x86_64-linux-gnu \ --enable-multiplatform --enable-linked-scripts -C CFLAGS='-O0 -g3 \ -ggdb3 -Wno-unknown-pragmas -mtune=nocona -g -O3 -fno-lto \ -fno-use-linker-plugin' CXXFLAGS='-O0 -g3 -ggdb3 \ -Wno-unknown-pragmas -mtune=nocona -g -O3 -fno-lto \ -fno-use-linker-plugin' LDFLAGS='-fno-lto -fno-use-linker-plugin \ -static-libgcc -static-libstdc++' MAKEFLAGS='-j16' This is likely out-of-date now and certainly doesn't follow the "best practices", but it worked for me at the time. Thanks, -- Max From karl at freefriends.org Sun Aug 31 19:00:11 2025 From: karl at freefriends.org (Karl Berry) Date: Sun, 31 Aug 2025 11:00:11 -0600 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> Message-ID: <202508311700.57VH0BH3069793@freefriends.org> Hi again Hille, Is there a patch applied to the zzlib in the texlive-sources As Norbert mentioned, our patches are generally in a TLpatches/ subdir, which has its own ChangeLog. The linking fails with /usr/bin/ld: libluamisc.a(libluamisc_a-luazip.o): in function `zip_openfile': luazip.c:(.text+0x654): undefined reference to `zzip_open_ext_io64' The function declaration is in zzip/zzip.h, not in the additional zzip/zzip32.h. Indeed, the #include zzip32.h seems immaterial for this. I wonder if we still need it. Anyway, looking at zzip.h, I see that the #define zzip_open_ext_io zzip_open_ext_io64 happens with #ifdef ZZIP_LARGEFILE_RENAME Therefore I surmise that your 32-bit build is #defining ZZIP_LARGEFILE_RENAME and ours isn't. This #define apparently happens in zzip/conf.h under various conditions. (Original code, not touched by us.) Our configure stuff is not defining it, as far as I can grep. Where is the original zziplib release that causes the build failure for you? Perhaps there are other changes that we failed to note in TLpatches. Although I have to suspect the difference is where/whether certain preprocessor symbols are defined. --thanks, karl. From sthibault at debian.org Sun Aug 31 21:02:30 2025 From: sthibault at debian.org (Samuel Thibault) Date: Sun, 31 Aug 2025 21:02:30 +0200 Subject: [tlbuild] texlive-source: building detex In-Reply-To: <202508302132.57ULWJut088417@freefriends.org> References: <202508302132.57ULWJut088417@freefriends.org> Message-ID: Hello, Karl Berry, le sam. 30 ao?t 2025 15:32:19 -0600, a ecrit: > Hi Hille, Samuel, > > https://bugs.debian.org/1111524 > https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/detex_single_job.diff > ... > BUILT_SOURCES = detex-src/$(am__dirstamp) > > Ok, committed (TL r76190), but I have questions. > > 1) what changed that this bug is now being provoked? The very fact that Debian now patches detex.l for a gcc-15 build issue. The detex.c file then needs regenerated, as expected. Otherwise, the build will just use the pre-shipped file fine. > 2) Why do you patch detex.l in the first place? Can we install that > patch? Installing it would be welcome, sure :) > 3) Speaking as an Automake maintainer, I'd like to fix the real bug, but > it's hard to work on anything in the midst of the complex TL build. Can > you make a small reproducible test that I could work on in Automake? Attached is a reproducer: $ tar xf tmp.tgz $ (cd tmp ; autoreconf -vfi) $ mkdir build $ cd build $ ../tmp/configure --disable-dependency-tracking $ make /bin/bash ../tmp/ylwrap ../tmp/detex-src/detex.l lex.yy.c detex-src/detex.c -- flex ../tmp/ylwrap: line 204: ../detex-src/detex.c: No such file or directory make: *** [Makefile:412: detex-src/detex.c] Error 1 > 4) At first glance, the proximate cause of the problem seems to be > ylwrap, rather than the Automake rules discussed in > https://lists.gnu.org/archive/html/bug-automake/2017-06/msg00005.html, No, ylwrap is just the symptom. The real cause is that here: detex-src/$(am__dirstamp): @$(MKDIR_P) detex-src @: >>detex-src/$(am__dirstamp) detex-src/detex.$(OBJEXT): detex-src/$(am__dirstamp) \ detex-src/$(DEPDIR)/$(am__dirstamp) it's the detex-src/detex.$(OBJEXT) that depends on detex-src/$(am__dirstamp) to get the detex-src directory built, while it is the detex-src/detex.c target that needs it. > etc. If ylwrap figures out the dirname of the target file and creates > it (as in the change below), instead of assuming it exists, does that > solve the problem? It shouldn't be doing such a thing. It's being told to create detex-src/detex.c. As all unix tools, it should just assume detex-src already exists, and not take the initiative of creating it. Really, a way to fix it without modifying automake is to use: BUILT_SOURCES = detex-src/$(am__dirstamp) to make sure that detex-src/ is created before anything else. Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: tmp.tgz Type: application/x-gtar-compressed Size: 879 bytes Desc: not available URL: From karl at freefriends.org Sun Aug 31 23:59:45 2025 From: karl at freefriends.org (Karl Berry) Date: Sun, 31 Aug 2025 15:59:45 -0600 Subject: [tlbuild] texlive-source: building detex In-Reply-To: Message-ID: <202508312159.57VLxj6f089252@freefriends.org> Hi Samuel, > 2) Why do you patch detex.l in the first place? Can we install that > patch? Installing it would be welcome, sure :) So ... what is the detex.l patch? Sorry, there are too many at https://github.com/debian-tex/texlive-bin/tree/master/debian/patches to go through them all. Also not sure if that's the right place to look. Attached is a reproducer: Thanks much. it's the detex-src/detex.$(OBJEXT) that depends on detex-src/$(am__dirstamp) to get the detex-src directory built, while it is the detex-src/detex.c target that needs it. Thanks again. Makes sense. It shouldn't be doing such a thing. It's being told to create detex-src/detex.c. As all unix tools, it should just assume detex-src Agreed. I was on the wrong road there. Really, a way to fix it without modifying automake is to use: BUILT_SOURCES = detex-src/$(am__dirstamp) Yep, already committed. --best, karl. From sthibault at debian.org Mon Sep 1 00:13:03 2025 From: sthibault at debian.org (Samuel Thibault) Date: Mon, 1 Sep 2025 00:13:03 +0200 Subject: [tlbuild] texlive-source: building detex In-Reply-To: <202508312159.57VLxj6f089252@freefriends.org> References: <202508312159.57VLxj6f089252@freefriends.org> Message-ID: Karl Berry, le dim. 31 ao?t 2025 15:59:45 -0600, a ecrit: > > 2) Why do you patch detex.l in the first place? Can we install that > > patch? > > Installing it would be welcome, sure :) > > So ... what is the detex.l patch? Sorry, there are too many at > https://github.com/debian-tex/texlive-bin/tree/master/debian/patches to > go through them all. Also not sure if that's the right place to look. It is the right place, it is gcc-15/86.patch Samuel From patrick.gundlach at gmail.com Mon Sep 1 09:39:43 2025 From: patrick.gundlach at gmail.com (Patrick Gundlach) Date: Mon, 1 Sep 2025 09:39:43 +0200 Subject: [tlbuild] Cross compile on Linux for Windows (AMD64) In-Reply-To: <2325394fceb37be5d6a13942cd9bc941413fb3c0.camel@maxchernoff.ca> References: <2325394fceb37be5d6a13942cd9bc941413fb3c0.camel@maxchernoff.ca> Message-ID: Max, thank you very much for your insight. I will save this message for the next time I cross compile on Linux. Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Tue Sep 2 22:16:22 2025 From: karl at freefriends.org (Karl Berry) Date: Tue, 2 Sep 2025 14:16:22 -0600 Subject: [tlbuild] texlive-source: building detex In-Reply-To: Message-ID: <202509022016.582KGM2F058845@freefriends.org> > https://github.com/debian-tex/texlive-bin/tree/master/debian/patches to > go through them all. Also not sure if that's the right place to look. It is the right place, it is gcc-15/86.patch Ah. I already installed that back in June. So hopefully this stuff won't be a problem next year. --thanks, karl. From hille42 at web.de Wed Sep 3 16:47:53 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Wed, 3 Sep 2025 16:47:53 +0200 Subject: [tlbuild] texlive-source: debug symbols Message-ID: <8581f04c-4d50-41fb-b667-e88b5097319f@web.de> Hello again, the Debian quality checker complained that no debug symbols are generated when the TL binaries are built: texlive-binaries-dbgsym: debug-file-with-no-debug-symbols The help for that warning said, one should call gcc/g++ using option -g so currently we build with: # Debug symbols. export CFLAGS += -g export CPPFLAGS += -g Is there a configure option I missed or is it intended that debug symbols are not created? Thanks! Hilmar -- sigfault -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From luigi.scarso at gmail.com Wed Sep 3 19:25:11 2025 From: luigi.scarso at gmail.com (luigi scarso) Date: Wed, 3 Sep 2025 19:25:11 +0200 Subject: [tlbuild] texlive-source: debug symbols In-Reply-To: <8581f04c-4d50-41fb-b667-e88b5097319f@web.de> References: <8581f04c-4d50-41fb-b667-e88b5097319f@web.de> Message-ID: On Wed, 3 Sept 2025 at 16:48, Preu?e, Hilmar via tlbuild wrote: > Hello again, > > the Debian quality checker complained that no debug symbols are > generated when the TL binaries are built: > > texlive-binaries-dbgsym: debug-file-with-no-debug-symbols > > The help for that warning said, one should call gcc/g++ using option -g > so currently we build with: > > # Debug symbols. > export CFLAGS += -g > export CPPFLAGS += -g > > Is there a configure option I missed or is it intended that debug > symbols are not created? Thanks! > > Gentoo says at https://wiki.gentoo.org/wiki/Debugging CFLAGS="${CFLAGS} -ggdb3" CXXFLAGS="${CXXFLAGS} -ggdb3" LDFLAGS="${LDFLAGS} -ggdb3" but I think that CFLAGS="${CFLAGS} -g" CXXFLAGS="${CXXFLAGS} -g" should be ok. Given that we also compile with -O2, it is known from the gcc manual that """ GCC allows you to use -g with -O. The shortcuts taken by optimized code may occa- sionally be surprising: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops. Nevertheless it is possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs. """ (indeed I use -O0 -ggdb3 or -Og -ggdb3 ) Furthermore, the size of a program compiled with debugging information is 2.5 / 3 times larger than that of the same program without it, but debugging information is usually not loaded by the loader at runtime (certainly with an elf file), unless a program such as a debugger requires it. In practice, the only difference is in the download from the network and the size occupied on a disk. -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Wed Sep 3 23:13:41 2025 From: karl at freefriends.org (Karl Berry) Date: Wed, 3 Sep 2025 15:13:41 -0600 Subject: [tlbuild] texlive-source: debug symbols In-Reply-To: <8581f04c-4d50-41fb-b667-e88b5097319f@web.de> Message-ID: <202509032113.583LDfLM061955@freefriends.org> Hi Hille, export CFLAGS += -g export CPPFLAGS += -g CXXFLAGS rather than CPPFLAGS. But anyway, it shouldn't be necessary, as explained below. Does your build log show no -g's in the compile commands? There's a -g option for the ./Build script, but I don't think you use ./Build? (The purpose of the option is to avoid optimization.) Without anything special, you should get the default from autoconf, which as far as I know is still -g -O2. Is there a configure option I missed or is it intended that debug symbols are not created? It depends on what make target you are using. I'm guessing the default, which is "world". Symbols are included in the compile commands by default. What happens is that the default "world" target of the top-level Makefile runs "make install-strip" instead of install (see below). Clearly it would be trivial to make that "install-strip" name be a variable so you could override it to "install". Would that be helpful? But beyond that, make world also runs make check. Are you running your own separate make check? If so, it's happening twice. make install && make texlinks would be equivalent to what world actually does. -k .PHONY: world # Run texlinks here since the binaries won't be there # at install-data, and fmtutil.cnf won't be there at install-exec, # and there is no install-hook or install-local. texlinks_dir = texk/texlive/tl_support world: all # Serialize 'make all' and 'make install-strip'. @echo "top-level make $@: running install-strip..." $(MAKE) $(AM_MAKEFLAGS) install-strip # # Just in case it's not a full checkout. if test -d "$(texlinks_dir)"; then \ echo "top-level make $@: making run-texlinks in $(texlinks_dir) ..."; \ cd $(texlinks_dir) && $(MAKE) $(AM_MAKEFLAGS) run-texlinks; \ else :; fi # @echo "top-level make $@: running $(check_target)..." $(MAKE) $(AM_MAKEFLAGS) $(check_target) # @echo "top-level make $@ done." From karl at freefriends.org Wed Sep 3 23:13:42 2025 From: karl at freefriends.org (Karl Berry) Date: Wed, 3 Sep 2025 15:13:42 -0600 Subject: [tlbuild] texlive-source: debug symbols In-Reply-To: Message-ID: <202509032113.583LDgIY061983@freefriends.org> CFLAGS="${CFLAGS} -ggdb3" CXXFLAGS="${CXXFLAGS} -ggdb3" LDFLAGS="${LDFLAGS} -ggdb3" Debug level 3 includes macro definitions in the debugging output, which greatly increases the size. Sometimes that's what you want, sometimes it isn't. For distributions, I doubt it. CFLAGS="${CFLAGS} -g" CXXFLAGS="${CXXFLAGS} -g" should be ok. I agree. Much less disk/network space is consumed, and I expect the debug symbols are unused 99.999% of the time. Luigi, as you describe, sometimes one also wants to use -Og to truly suppress optimization. But again, for distribution, probably not worth it. karl From jakob.jakobson13 at posteo.de Thu Sep 4 20:03:40 2025 From: jakob.jakobson13 at posteo.de (Jakob Jakobson) Date: Thu, 04 Sep 2025 18:03:40 +0000 Subject: [tlbuild] =?utf-8?q?Flatpak_build_of_texlive_with_GCC15_for_x86?= =?utf-8?q?=5F64_and_arm64?= Message-ID: Dear all, I have a problem building texlive for the flatpak package with the newest flatpak SDK ( https://github.com/flathub/org.freedesktop.Sdk.Extension.texlive/issues/192) . Building texlive for flatpak was no problem with the flatpak SDK 24.08 that used GCC 14. But the newer version of the flatpak SDK uses GCC 15 and there the problems begin: I tried the following two combinations for compilation, but the they both failed (see also here https://github.com/flathub/org.freedesktop.Sdk.Extension.texlive/pull/193 ). Can you give me any advice? The combination of cflags: -std=gnu17 and cxxflags: -std=gnu++17 lead to a compilation error in the module texk/dvisvgm/dvisvgm-src/libs/woff2/src/woff2_out of the x86_64 build whereas the combination of build flags cflags: -std=gnu17 and cxxflags: -std=gnu++20 lead to a compilation error in the module dvisvgm/dvisvgm-src/libs/clipper/clipper.cpp of the arm64 build. I can?t test the arm64 build on my PC and I would appreciate any hint for a solution very much as I don?t want to spam the github ressources. Thanks and regards Jakob PS: The full logs can be found via the github pull request. From karl at freefriends.org Thu Sep 4 22:20:41 2025 From: karl at freefriends.org (Karl Berry) Date: Thu, 4 Sep 2025 14:20:41 -0600 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: Message-ID: <202509042020.584KKfh9060542@freefriends.org> the newer version of the flatpak SDK uses GCC 15 A variety of patches have been applied to the TL sources to pay the necessary obeisance to GCC 15. Sorry, but I don't have them accumulated in a branch or anything for you to apply. And there have been many unrelated changes that you wouldn't want to have. So all I can advise is to use an older gcc for now, or wait until TL 2026 is released. and there the problems begin: Due to the C23 standard's breakage of 50+ years of existing code. -k From jakob.jakobson13 at posteo.de Fri Sep 5 07:38:19 2025 From: jakob.jakobson13 at posteo.de (Jakob Jakobson) Date: Fri, 05 Sep 2025 05:38:19 +0000 Subject: [tlbuild] =?utf-8?q?Flatpak_build_of_texlive_with_GCC15_for_x86_?= =?utf-8?q?=5F64_and_arm64?= In-Reply-To: <202509042020.584KKfh9060542@freefriends.org> References: <202509042020.584KKfh9060542@freefriends.org> Message-ID: <1b3c34f76f113bea169986415f6ab1d1@posteo.de> So there is no chance to get it compiled by using compiler flags (such as cflags and cxxflags or others)? Am 04.09.2025 22:20 schrieb Karl Berry: > the newer version of the flatpak SDK uses GCC 15 > > A variety of patches have been applied to the TL sources to pay the > necessary obeisance to GCC 15. Sorry, but I don't have them accumulated > in a branch or anything for you to apply. And there have been many > unrelated changes that you wouldn't want to have. > > So all I can advise is to use an older gcc for now, or wait until TL > 2026 is released. > > and there the problems begin: > > Due to the C23 standard's breakage of 50+ years of existing code. -k From luigi.scarso at gmail.com Fri Sep 5 08:51:39 2025 From: luigi.scarso at gmail.com (luigi scarso) Date: Fri, 5 Sep 2025 08:51:39 +0200 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: <1b3c34f76f113bea169986415f6ab1d1@posteo.de> References: <202509042020.584KKfh9060542@freefriends.org> <1b3c34f76f113bea169986415f6ab1d1@posteo.de> Message-ID: On Fri, 5 Sept 2025 at 07:38, Jakob Jakobson wrote: > So there is no chance to get it compiled by using compiler flags (such > as cflags and cxxflags or others)? > Hm, that shouldn't be the case. I mean, gcc15 with the appropriate cflags and cxxflags should be equivalent to gcc14. Can you send me the two logs with gcc14 (which compiles correctly) and gcc15 off-list? -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Sat Sep 6 22:30:00 2025 From: karl at freefriends.org (Karl Berry) Date: Sat, 6 Sep 2025 14:30:00 -0600 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: <1b3c34f76f113bea169986415f6ab1d1@posteo.de> Message-ID: <202509062030.586KU0Pu043005@freefriends.org> Just to follow up: So there is no chance to get it compiled by using compiler flags (such as cflags and cxxflags or others)? Sure, as Luigi said, it should work if you tell gcc to use an older standard. Anything but C23 should be ok. In most of our own builds, we use CXXFLAGS=-std=c++17. We're using older compilers so haven't needed to set CFLAGS yet, but presumably the same should be ok. Or gnu17. Hope it flies, Karl From hille42 at web.de Mon Sep 8 00:12:48 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Mon, 8 Sep 2025 00:12:48 +0200 Subject: [tlbuild] texlive-source: debug symbols In-Reply-To: <202509032113.583LDfLM061955@freefriends.org> References: <202509032113.583LDfLM061955@freefriends.org> Message-ID: <341bf4e7-d91e-4e34-86f2-1d5e84c0bd65@web.de> On 9/3/2025 11:13 PM, Karl Berry wrote: Hello Karl, > export CFLAGS += -g > export CPPFLAGS += -g > > CXXFLAGS rather than CPPFLAGS. > Thanks for the pointer, but indeed neither of them seems to be needed, just the CFLAGS parameter: > But anyway, it shouldn't be necessary, as explained below. Does your > build log show no -g's in the compile commands? > You may grep the build log from amd64 [1] hille at rasppi3:~/devel/TeXLive/github $ grep ^g++ fetch.php... |grep -- -g" "|wc -l 65 hille at rasppi3:~/devel/TeXLive/github $ grep ^g++ fetch.php\... |wc -l 65 For gcc it looks differently: hille at rasppi3:~/devel/TeXLive/github $ grep ^g++ fetch.php... |grep -- -g" "|wc -l 0 but 1328 calls to gcc. > There's a -g option for the ./Build script, but I don't think you use > ./Build? (The purpose of the option is to avoid optimization.) > Yes, correct; I don't use the build script. We unpack the source tree, apply some patches, run autoconf and then configure, with a lot of option as visible on [2]. > Without anything special, you should get the default from autoconf, > which as far as I know is still -g -O2. > AFAICT neither -g nor -O2 is present. I had a closer look at the patches, but I did not notice that we change the build system, so that some gcc options could be lost. > Is there a configure option I missed or is it intended that debug > symbols are not created? > > It depends on what make target you are using. I'm guessing the default, > which is "world". > just make -j4 (depending on the # of CPU's). dh_auto_build -O--builddirectory=Work -O--max-parallel=8 cd Work && make -j4 make[1]: Entering directory '/build/reproducible-path/texlive-bin-2025.20250727.75242+ds/Work' env MAKE="make" LDFLAGS="-Wl,-z,relro -Wl,-z,now" \ CC="gcc" CFLAGS="-std=gnu17 -g -std=gnu17 -g" \ CXX="g++" CXXFLAGS="-g -O2 -ffile-prefix-map=/build/reproducible-path/texlive-bin-2025.20250727.75242+ds=. -fstack-protec tor-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard" \ OBJCXX="" OBJCXXFLAGS="-g -O2 -ffile-prefix-map=/build/reproducible-path/texlive-bin-2025.20250727.75242+ds=. -fstack-pro tector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard" \ As one can see the CFLAGS contains the strings we introduced twice, but the -g we had to introduce. I double checked, if we overwrite CFLAGS at any point, but AFAICT we just append options. > Symbols are included in the compile commands by default. What happens is > that the default "world" target of the top-level Makefile runs "make > install-strip" instead of install (see below). > > Clearly it would be trivial to make that "install-strip" name be a> variable so you could override it to "install". Would that be helpful? > No, we don't call "make world", so during "make install" no symbols are stripped. Adding -g to CFLAGS was all I had to do, the binaries are stripped later using the Debian specific tools. Hilmar [1] https://buildd.debian.org/status/fetch.php?pkg=texlive-bin&arch=amd64&ver=2025.20250727.75242%2Bds-4&stamp=1755214073&raw=1 [2] https://github.com/debian-tex/texlive-bin/blob/master/debian/rules#L134 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From hille42 at web.de Mon Sep 8 00:31:41 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Mon, 8 Sep 2025 00:31:41 +0200 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: References: <7202cda0-1c32-445c-8e6f-2c459d28020e@web.de> <0c572826-e180-4a7f-bbaf-00c94de21639@web.de> Message-ID: On 8/29/2025 12:24 AM, Norbert Preining wrote: > On Fri, 29 Aug 2025, Hilmar Preu?e wrote: Hello Norbert, >> zzip/zzip32.h. Are you sure? > > No, but this is what is patched into the sources of TL. > Maybe the other patch in the linked directory - but doesn't feel like. > If there would be an issue with the header file I would expect warnings/error when the object files created. In our case however the build fails during linking. Hilmar -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From hille42 at web.de Mon Sep 8 00:36:54 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Mon, 8 Sep 2025 00:36:54 +0200 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: <202508311700.57VH0BH3069793@freefriends.org> References: <202508311700.57VH0BH3069793@freefriends.org> Message-ID: <4c988e47-9c36-4cfc-9c15-72f322a41563@web.de> On 8/31/2025 7:00 PM, Karl Berry wrote: Hello Karl, > Therefore I surmise that your 32-bit build is #defining > ZZIP_LARGEFILE_RENAME and ours isn't. This #define apparently happens in > zzip/conf.h under various conditions. (Original code, not touched by us.) > Our configure stuff is not defining it, as far as I can grep. > > Where is the original zziplib release that causes the build failure for > you? Perhaps there are other changes that we failed to note in TLpatches. > We use 0.13.78+dfsg.1-0.1, which is delivered with Debian unstable. I may build that package using a i386 to see the build tree if that would be helpful. Hilmar -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From j.woerner at posteo.de Mon Sep 8 19:36:21 2025 From: j.woerner at posteo.de (=?UTF-8?Q?Jakob_W=C3=B6rner?=) Date: Mon, 08 Sep 2025 17:36:21 +0000 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: <202509062030.586KU0Pu043005@freefriends.org> References: <202509062030.586KU0Pu043005@freefriends.org> Message-ID: Luigi hinted that the header cstdint might be missing. By directing the output of $ echo "#include " | /bin/g++ -E -dM -x c++ - into the file gcc14 and $ echo "#include " | /bin/g++ -E -dM -x c++ - into the file gcc15 and comparing them with $ diff gcc14 gcc15 I got the following result given below. However, unfortunately I don't know what I should be looking for. 4a5 > #define __LDBL_MANT_DIG__ 64 55a57 > #define __cpp_inheriting_constructors 201511L 76a79 > #define __TIMESIZE __WORDSIZE 192c195 < #define __glibcxx_assert(cond) do { if (std::__is_constant_evaluated() && !bool(cond)) std::__glibcxx_assert_fail(); } while (false) --- > #define __glibcxx_assert(cond) do { if (__builtin_expect(!bool(cond), false)) _GLIBCXX_ASSERT_FAIL(cond); } while (false) 194d196 < #define _GLIBCXX_HAVE_WCSTOF 1 195a198 > #define __DEC64X_MAX_EXP__ 6145 249a253 > #define _GLIBCXX26_CONSTEXPR 255a260 > #define _GLIBCXX_HAVE_SINF 1 259a265 > #define __STDC_EMBED_EMPTY__ 2 312a319 > #define __DEC64X_EPSILON__ 1E-33D64x 315,316d321 < #define INT64_C(c) c ## L < #define __cpp_return_type_deduction 201304L 329c334 < #define __GNUC__ 14 --- > #define __GNUC__ 15 347a353,354 > #define _GLIBCXX26_DEPRECATED > #define _GLIBCXX_ASSERTIONS 1 379a387 > #define __SUSECONDS64_T_TYPE __SQUAD_TYPE 380a389 > #define _GLIBCXX_USE_STRUCT_TM_TM_ZONE 1 439a449 > #define __DEC64X_MAX__ 9.999999999999999999999999999999999E6144D64x 442c452 < #define __GNUG__ 14 --- > #define __GNUG__ 15 446c456 < #define __GLIBCXX__ 20250523 --- > #define __GLIBCXX__ 20250808 468c478,479 < #define __GXX_ABI_VERSION 1019 --- > #define __GXX_ABI_VERSION 1020 > #define UINT32_C(c) c ## U 560c571 < #define __VERSION__ "14.3.0" --- > #define __VERSION__ "15.2.0" 570a582 > #define __DEC64X_MIN__ 1E-6143D64x 596a609 > #define __cpp_decltype 200707L 600a614 > #define _GLIBCXX26_DEPRECATED_SUGGEST(ALT) 643a658 > #define __DEC64X_MANT_DIG__ 34 670a686 > #define INT64_C(c) c ## L 693c709 < #define _GLIBCXX_EXTERN_TEMPLATE 1 --- > #define _GLIBCXX_EXTERN_TEMPLATE -1 734a751 > #define __STDC_EMBED_FOUND__ 1 769a787 > #define __STDC_EMBED_NOT_FOUND__ 0 774c792 < #define _GLIBCXX_HAVE_SINF 1 --- > #define __DEC64X_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143D64x 786c804 < #define _GLIBCXX_RELEASE 14 --- > #define _GLIBCXX_RELEASE 15 822d839 < #define __LDBL_MANT_DIG__ 64 859d875 < #define __cpp_decltype 200707L 894d909 < #define UINT32_C(c) c ## U 899d913 < #define __cpp_inheriting_constructors 201511L 918a933 > #define __DEC64X_MIN_EXP__ (-6142) 934a950 > #define __GXX_CONSTEXPR_ASM__ 1 951a968 > #define __cpp_return_type_deduction 201304L 1067d1083 < #define __TIMESIZE __WORDSIZE 1077c1093 < #define __GNUC_MINOR__ 3 --- > #define __GNUC_MINOR__ 2 1117a1134 > #define _GLIBCXX_HAVE_WCSTOF 1 1152d1168 < #define __SUSECONDS64_T_TYPE __SQUAD_TYPE Am 06.09.25 um 22:30 schrieb Karl Berry: > Just to follow up: > > So there is no chance to get it compiled by using compiler flags (such > as cflags and cxxflags or others)? > > Sure, as Luigi said, it should work if you tell gcc to use an older > standard. Anything but C23 should be ok. In most of our own builds, we > use CXXFLAGS=-std=c++17. We're using older compilers so haven't needed > to set CFLAGS yet, but presumably the same should be ok. Or gnu17. > > Hope it flies, > Karl > From karl at freefriends.org Mon Sep 8 22:27:19 2025 From: karl at freefriends.org (Karl Berry) Date: Mon, 8 Sep 2025 14:27:19 -0600 Subject: [tlbuild] texlive-source: debug symbols In-Reply-To: <341bf4e7-d91e-4e34-86f2-1d5e84c0bd65@web.de> Message-ID: <202509082027.588KRJrr044181@freefriends.org> AFAICT neither -g nor -O2 is present. In a subdir of our Build/source, I ran, with nothing relevant in the environment, mkdir foo cd foo ./configure --prefix=/tmp/tltry and the resulting ./Makefile contains, as I would expect, the line CFLAGS = -g -O2 which is (still) the default for Autoconf. CFLAGS="-std=gnu17 -g -std=gnu17 -g" \ Oh. Well, if you specify CFLAGS, it's up to you to include the -g if you want it. if we overwrite CFLAGS at any point, but AFAICT we just append options. If/since you set CFLAGS on the cmdline, you are overriding the default -g -O2 even if you defined it in your script only by appending -- you were appending to the empty string. So you have to include the -g yourself. This is not related to TL, as far as I can see. --best, karl. From karl at freefriends.org Mon Sep 8 22:27:19 2025 From: karl at freefriends.org (Karl Berry) Date: Mon, 8 Sep 2025 14:27:19 -0600 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: <4c988e47-9c36-4cfc-9c15-72f322a41563@web.de> Message-ID: <202509082027.588KRJmU044189@freefriends.org> We use 0.13.78+dfsg.1-0.1, which is delivered with Debian unstable. I may build that package using a i386 to see the build tree if that would be helpful. 1) As far as anything I can do, can you point me at or send a .tgz or .zip file of the sources? I see https://debian.pkgs.org/sid/debian-main-amd64/libzzip-dev_0.13.78+dfsg.1-0.1_amd64.deb.html but I don't run Debian and don't know how to simply unpack a .deb file. 1a) And, where is the real upstream that you used? Can you give me an exact url to something I can download? There are so many versions, so many forks, so many releases ... 2) As far as I can see, you need to debug your failing build to see why ZZIP_LARGEFILE_RENAME is being defined on i386, when it is not being defined in the TL build. I'm sure you don't need me to advise you, but FWIW, I usually manually run the failing compile command with -E -dD to get the preprocessor output with all #define's included in the output. --best, karl. From vojta at math.berkeley.edu Mon Sep 8 23:05:11 2025 From: vojta at math.berkeley.edu (Paul Vojta) Date: Mon, 8 Sep 2025 14:05:11 -0700 Subject: [tlbuild] texlive-source: zziplib on i386 In-Reply-To: <202509082027.588KRJmU044189@freefriends.org> References: <4c988e47-9c36-4cfc-9c15-72f322a41563@web.de> <202509082027.588KRJmU044189@freefriends.org> Message-ID: On Mon, Sep 08, 2025 at 02:27:19PM -0600, Karl Berry wrote: > We use 0.13.78+dfsg.1-0.1, which is delivered with Debian unstable. I > may build that package using a i386 to see the build tree if that would > be helpful. > > 1) As far as anything I can do, can you point me at or send a .tgz or > .zip file of the sources? I see > https://debian.pkgs.org/sid/debian-main-amd64/libzzip-dev_0.13.78+dfsg.1-0.1_amd64.deb.html > but I don't run Debian and don't know how to simply unpack a .deb file. I don't know about the exact version you are asking about, but here's what you can do with non-Debian linux: % wget http://mirrors.ocf.berkeley.edu/debian/pool/main/z/zziplib/libzzip-dev_0.13.72%2bdfsg.1-1.1_amd64.deb % ar x libzzip-dev_0.13.72+dfsg.1-1.1_amd64.deb This gives you files control.tar.xz, data.tar.xz, and debian-binary Mostly you'll be interested in data.tar.xz. --Paul Vojta, vojta at math.berkeley.edu From luigi.scarso at gmail.com Tue Sep 9 08:07:53 2025 From: luigi.scarso at gmail.com (luigi scarso) Date: Tue, 9 Sep 2025 08:07:53 +0200 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: References: <202509062030.586KU0Pu043005@freefriends.org> Message-ID: On Mon, 8 Sept 2025 at 21:30, Jakob W?rner wrote: > Luigi hinted that the header cstdint might be missing. > > By directing the output of > > $ echo "#include " | /bin/g++ -E -dM -x c++ - > > into the file gcc14 and > > $ echo "#include " | /bin/g++ -E -dM -x c++ - > > into the file gcc15 and comparing them with > > $ diff gcc14 gcc15 > > I got the following result given below. However, unfortunately I don't > know what I should be looking for. > > 4a5 > > #define __LDBL_MANT_DIG__ 64 > 55a57 > > #define __cpp_inheriting_constructors 201511L > 76a79 > > #define __TIMESIZE __WORDSIZE > ok, you have cstdint . What happen if you add #include after #include in source/texk/dvisvgm/dvisvgm-src/libs/woff2/include/woff2/output.h ? -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob.jakobson13 at posteo.de Wed Sep 10 20:01:15 2025 From: jakob.jakobson13 at posteo.de (Jakob Jakobson) Date: Wed, 10 Sep 2025 18:01:15 +0000 Subject: [tlbuild] =?utf-8?q?Flatpak_build_of_texlive_with_GCC15_for_x86_?= =?utf-8?q?=5F64_and_arm64?= In-Reply-To: References: <202509062030.586KU0Pu043005@freefriends.org> Message-ID: Applying the patch fixed the problem. Is this a bug in texlive or should I report it to the flatpak people? Am 09.09.2025 08:07 schrieb luigi scarso: > On Mon, 8 Sept 2025 at 21:30, Jakob W?rner > wrote: > >> Luigi hinted that the header cstdint might be missing. >> >> By directing the output of >> >> $ echo "#include " | /bin/g++ -E -dM >> -x c++ - >> >> into the file gcc14 and >> >> $ echo "#include " | /bin/g++ -E -dM >> -x c++ - >> >> into the file gcc15 and comparing them with >> >> $ diff gcc14 gcc15 >> >> I got the following result given below. However, unfortunately I >> don't >> know what I should be looking for. >> >> 4a5 >>> #define __LDBL_MANT_DIG__ 64 >> 55a57 >>> #define __cpp_inheriting_constructors 201511L >> 76a79 >>> #define __TIMESIZE __WORDSIZE > > ok, you have cstdint . > > What happen if you add > #include > after > #include > in > source/texk/dvisvgm/dvisvgm-src/libs/woff2/include/woff2/output.h > ? > > -- > luigi From luigi.scarso at gmail.com Wed Sep 10 20:47:38 2025 From: luigi.scarso at gmail.com (luigi scarso) Date: Wed, 10 Sep 2025 20:47:38 +0200 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: References: <202509062030.586KU0Pu043005@freefriends.org> Message-ID: Il Mer 10 Set 2025, 20:01 Jakob Jakobson ha scritto: > Applying the patch fixed the problem. Is this a bug in texlive or should > I report it to the flatpak people? > I think it should be applied to texlive. Karl ? -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Wed Sep 10 22:10:00 2025 From: karl at freefriends.org (Karl Berry) Date: Wed, 10 Sep 2025 14:10:00 -0600 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: Message-ID: <202509102010.58AKA0Me046979@freefriends.org> I think it should be applied to texlive. Karl ? It needs to be reported to the dvisvgm maintainer. https://github.com/mgieseki/dvisvgm/issues Thanks, Karl From martin.gieseking at uos.de Wed Sep 10 23:12:48 2025 From: martin.gieseking at uos.de (Martin Gieseking) Date: Wed, 10 Sep 2025 23:12:48 +0200 Subject: [tlbuild] Flatpak build of texlive with GCC15 for x86 _64 and arm64 In-Reply-To: <202509102010.58AKA0Me046979@freefriends.org> References: <202509102010.58AKA0Me046979@freefriends.org> Message-ID: Am 10.09.2025 um 22:10 schrieb Karl Berry: > I think it should be applied to texlive. > Karl ? > > It needs to be reported to the dvisvgm maintainer. > https://github.com/mgieseki/dvisvgm/issues The issue has already been fixed in the dvisvgm repository: https://github.com/mgieseki/dvisvgm/commit/dcb5940dff7ca3084330119a4ff1472cd52ef6de So, I guess, the fix will arrive in TL with the next import of the upstream sources. Best, Martin From hille42 at web.de Mon Sep 15 23:32:16 2025 From: hille42 at web.de (=?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=) Date: Mon, 15 Sep 2025 23:32:16 +0200 Subject: [tlbuild] texlive-source: debug symbols In-Reply-To: <202509082027.588KRJrr044181@freefriends.org> References: <202509082027.588KRJrr044181@freefriends.org> Message-ID: <797586af-c002-48c9-804d-da028160a821@web.de> Am 08.09.2025 um 22:27 schrieb Karl Berry: Hi Karl, > If/since you set CFLAGS on the cmdline, you are overriding the default > -g -O2 even if you defined it in your script only by appending -- you > were appending to the empty string. So you have to include the -g > yourself. This is not related to TL, as far as I can see. --best, karl. > Many thanks for help! That was the reason. # Workaround for incompatibility to GCC 15. export DEB_CFLAGS_MAINT_APPEND += -std=gnu17 works better: now that flag is really just appended and all remaining flags (incl. -g) are kept. Thanks again, Hilmar -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: