From asyropoulos at gmail.com Mon Jul 16 17:42:41 2018 From: asyropoulos at gmail.com (Apostolos Syropoulos) Date: Mon, 16 Jul 2018 18:42:41 +0300 Subject: [tlbuild] install-tl script is broken Message-ID: Hello, A friend of mine tried to install TeXLive on a Solaris box and after installation there were no binaries. In fact, the installation script printed the following message: Detected platform: Solaris on Intel x86 *** WARNING: No binaries for your platform found. set binary platforms: 0 out of 8 ?Well there is a problem here. The system is ?x86_64-pc-solaris2.11? and the folder ./texlive/archive contains pdftex.x86_64-solaris.tar.xz xetex.x86_64-solaris.tar.xz Thus it includes the correct binaries, fails to correctly detect the system and one cannot install the binaries. Any suggestion to solve this problem? A.S. -- Apostolos Syropoulos Xanthi, GREECE -------------- next part -------------- An HTML attachment was scrubbed... URL: From asyropoulos at gmail.com Mon Jul 16 17:54:36 2018 From: asyropoulos at gmail.com (Apostolos Syropoulos) Date: Mon, 16 Jul 2018 18:54:36 +0300 Subject: [tlbuild] x86_64 or i386 on Solaris Message-ID: ?And to help to solve the problem reported in my previous message, one should use the isainfo command. On x86_64 systems the command isainfo -b will print 64 while one i386 systems it will print 32. A.S. -- Apostolos Syropoulos Xanthi, GREECE -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Tue Jul 17 01:08:48 2018 From: karl at freefriends.org (Karl Berry) Date: Mon, 16 Jul 2018 23:08:48 GMT Subject: [tlbuild] x86_64 or i386 on Solaris In-Reply-To: Message-ID: <201807162308.w6GN8miE025877@freefriends.org> We run config.guess, which should do the right thing. What does config.guess return on the system at hand? You can get the current version from, e.g., http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/config.guess It's also in the TL tree as tlpkg/installer/config.guess, among other places. -k From reinhard.kotucha at web.de Tue Jul 17 01:27:33 2018 From: reinhard.kotucha at web.de (Reinhard Kotucha) Date: Tue, 17 Jul 2018 01:27:33 +0200 Subject: [tlbuild] install-tl script is broken In-Reply-To: References: Message-ID: <23373.10725.679982.413469@gargle.gargle.HOWL> On 2018-07-16 at 18:42:41 +0300, Apostolos Syropoulos wrote: > Hello, > > A friend of mine tried to install TeXLive on a Solaris box and > after installation there were no binaries. In fact, the > installation script printed the following message: > > Detected platform: Solaris on Intel x86 > ? > *** WARNING: No binaries for your platform found.? > ? set binary platforms: 0 out of 8 > > ?Well there is a problem here. The system is ?x86_64-pc-solaris2.11? > and the folder? ./texlive/archive contains > > pdftex.x86_64-solaris.tar.xz > xetex.x86_64-solaris.tar.xz Hi Apostolos, is "?x86_64-pc-solaris2.11" the output of config.guess? This is what the installer uses in order to detect Unix platforms. Platform detection is performed by the function platform_name() in tlpkg/TeXLive/TLUtils.pm . Here print(platform_name("x86_64-pc-solaris2.11"), "\n"); correctly returns x86_64-solaris I don't know what went wrong. And from your other mail: > And to help to solve the problem reported in my previous message, > one should use the isainfo command. On x86_64 systems the command > isainfo -b will print 64 while one i386 systems it will print 32. I don't see any advantage. isainfo doesn't provide any information we can't already derive from config.guess. > Thus it includes the correct binaries, fails to correctly detect > the system and one cannot install the binaries. Any suggestion to > solve this problem? I have no clue. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha at web.de ------------------------------------------------------------------ From babafou at babafou.eu.org Fri Aug 3 09:09:10 2018 From: babafou at babafou.eu.org (Marc Baudoin) Date: Fri, 3 Aug 2018 09:09:10 +0200 Subject: [tlbuild] Can't build latest TeX Live on NetBSD/amd64 Message-ID: <20180803070910.GA28802@shuttle.babafou.eu.org> Hi, Since two weeks ago, I've been unable to build the latest sources of TeX Live on NetBSD/amd64: g++ -Wreturn-type -Wno-unknown-pragmas -Wno-write-strings -DHAVE_CONFIG_H -I. -I../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont -I../.. -I../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont/../include -g -O2 -MT cff.o -MD -MP -MF $depbase.Tpo -c -o cff.o ../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont/cff.cc &&\ mv -f $depbase.Tpo $depbase.Po ../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont/cff.cc: In constructor 'Efont::Cff::Cff(const String&, unsigned int, ErrorHandler*)': ../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont/cff.cc:351:58: error: '_Static_assert' was not declared in this scope "NSTANDARD_STRINGS defined incorrectly"); ^ gmake[6]: *** [Makefile:475: cff.o] Error 1 gmake[6]: Leaving directory '/usr/local/src/texlive/Work/texk/lcdf-typetools/lcdf-typetools-src/libefont' I'm don't know enough C++ to patch this. Anybody else having this problem? From karl at freefriends.org Sat Aug 4 00:06:15 2018 From: karl at freefriends.org (Karl Berry) Date: Fri, 3 Aug 2018 22:06:15 GMT Subject: [tlbuild] Can't build latest TeX Live on NetBSD/amd64 In-Reply-To: <20180803070910.GA28802@shuttle.babafou.eu.org> Message-ID: <201808032206.w73M6Fcp030020@freefriends.org> Hi Marc, Since two weeks ago, According to svn log, the last code change to lcdf-typetools was Feb 22. So I wonder, did your system change two weeks ago, e.g., new compiler? ../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont/cff.cc:351:58: error: '_Static_assert' was not declared in this scope It appears that something on your system is #defining static_assert to use _Static_assert, which is undefined. Eddie's code only uses static_assert, and has a fallback #define for it that does not involve _Static_assert (see the top of cff.cc). So I don't think the fault lies with the original code. Telling your compiler to report everything getting #defined might shed some light. See the "One tip:" paragraph I wrote on tug.org/texlive/build.html#implementation for specifics on doing this with gcc, if you are using gcc. BTW, it does compile for me with the gcc coming with CentOS7, which reports itself today as gcc version 4.8.5 20150623 (Red Hat 4.8.5-28). -k From babafou at babafou.eu.org Sat Aug 4 09:13:32 2018 From: babafou at babafou.eu.org (Marc Baudoin) Date: Sat, 4 Aug 2018 09:13:32 +0200 Subject: [tlbuild] Can't build latest TeX Live on NetBSD/amd64 In-Reply-To: <201808032206.w73M6Fcp030020@freefriends.org> References: <20180803070910.GA28802@shuttle.babafou.eu.org> <201808032206.w73M6Fcp030020@freefriends.org> Message-ID: <20180804071332.GB3914@shuttle.babafou.eu.org> Hi, Karl Berry ?crit : > > Since two weeks ago, > > According to svn log, the last code change to lcdf-typetools was Feb 22. > So I wonder, did your system change two weeks ago, e.g., new compiler? Crap! You're so right. I upgraded from NetBSD 7 to NetBSD 8. > ../../../../../texk/lcdf-typetools/lcdf-typetools-src/libefont/cff.cc:351:58: > error: '_Static_assert' was not declared in this scope > > It appears that something on your system is #defining static_assert to > use _Static_assert, which is undefined. It's in /usr/include/assert.h: #if ((__cplusplus - 0) < 201103L) #ifndef static_assert #define static_assert _Static_assert #endif /* static_assert */ #endif > BTW, it does compile for me with the gcc coming with CentOS7, which > reports itself today as > gcc version 4.8.5 20150623 (Red Hat 4.8.5-28). -k I don't think the compiler is at fault here. I tried a build with CXXFLAGS=-std=c++11 and it's OK. Thanks! From babafou at babafou.eu.org Sat Aug 4 09:30:20 2018 From: babafou at babafou.eu.org (Marc Baudoin) Date: Sat, 4 Aug 2018 09:30:20 +0200 Subject: [tlbuild] Test suite failing in mfluajit on NetBSD Message-ID: <20180804073020.GC3914@shuttle.babafou.eu.org> Hi again, New problem now the C++ stuff has been taken care of, the test suite is failing in mfluajitdir: Work/texk/web2c/mfluajitdir/mfluajittraptest.log contains: ../mfluajit --progname=inimfluajit <$testdir/mftrap1.in >mftrapin.fot + ../mfluajit --progname=inimfluajit mftrapin.fot PANIC: unprotected error in call to Lua API (runtime code generation failed, restricted kernel?) [1] Segmentation fault ../mfluajit --pr... Any idea? It might also be related to my NetBSD 8 upgrade, I don't have a 7 system left to test on it but I can set up a VM if required. From karl at freefriends.org Sat Aug 4 23:47:40 2018 From: karl at freefriends.org (Karl Berry) Date: Sat, 4 Aug 2018 21:47:40 GMT Subject: [tlbuild] Test suite failing in mfluajit on NetBSD In-Reply-To: <20180804073020.GC3914@shuttle.babafou.eu.org> Message-ID: <201808042147.w74Llei6001238@freefriends.org> PANIC: unprotected error in call to Lua API (runtime code generation failed, restricted kernel?) [1] Segmentation fault ../mfluajit --pr... I don't know. I forwarded your message to Luigi. In any case, mfluajit is supremely unimportant :). You might see if --disable-mfluajit lets it proceed through ... -k From babafou at babafou.eu.org Sun Aug 5 13:11:06 2018 From: babafou at babafou.eu.org (Marc Baudoin) Date: Sun, 5 Aug 2018 13:11:06 +0200 Subject: [tlbuild] Test suite failing in mfluajit on NetBSD In-Reply-To: <201808042147.w74Llei6001238@freefriends.org> References: <20180804073020.GC3914@shuttle.babafou.eu.org> <201808042147.w74Llei6001238@freefriends.org> Message-ID: <20180805111106.GA9219@shuttle.babafou.eu.org> Karl Berry ?crit : > PANIC: unprotected error in call to Lua API (runtime code generation failed, restricted kernel?) > [1] Segmentation fault ../mfluajit --pr... > > I don't know. I forwarded your message to Luigi. > > In any case, mfluajit is supremely unimportant :). You might see if > --disable-mfluajit lets it proceed through ... -k It does. From karl at freefriends.org Fri Aug 31 20:07:52 2018 From: karl at freefriends.org (Karl Berry) Date: Fri, 31 Aug 2018 18:07:52 GMT Subject: [tlbuild] always static libstdc++? Message-ID: <201808311807.w7VI7qbd011748@freefriends.org> Hi TL builders - do any of your platforms *not* require the KPSE_CXX_HACK to statically link the C++ runtime for the native TL binaries? Specifically, in the output from configure, these lines: checking for statically linking C++ runtime library... ok configure: using -nodefaultlibs -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -lgcc_eh -lgcc -lc -lgcc_eh -lgcc If the correct arguments can't be determined, it says "not supported" instead of "ok". and also in the configure summary at the end: enable_cxx_runtime_hack: yes If this is always needed for our native TL binaries, I'm going to change the Autoconf macro that checks for it to abort if --enable-native-texlive-build is given and the necessary options aren't discovered. (Having just wasted some time trying to figure out why my binaries were no longer statically linked and not noticing that crucial configure line ...) On the other hand, I thought there might be some platforms where we do distribute binaries with the C++ libraries dynamically linked, for whatever reason, and that's ok. (So then I wouldn't make that change.) Please let me know ... --thanks, karl. From kbrow1i at gmail.com Fri Aug 31 21:18:32 2018 From: kbrow1i at gmail.com (Ken Brown) Date: Fri, 31 Aug 2018 15:18:32 -0400 Subject: [tlbuild] always static libstdc++? In-Reply-To: <201808311807.w7VI7qbd011748@freefriends.org> References: <201808311807.w7VI7qbd011748@freefriends.org> Message-ID: <97e9c68d-b0be-38aa-b727-52c894229869@gmail.com> On 8/31/2018 2:07 PM, Karl Berry wrote: > Hi TL builders - do any of your platforms *not* require the > KPSE_CXX_HACK to statically link the C++ runtime for the native TL > binaries? Specifically, in the output from configure, these lines: > > checking for statically linking C++ runtime library... ok > configure: using -nodefaultlibs -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -lgcc_eh -lgcc -lc -lgcc_eh -lgcc > > If the correct arguments can't be determined, it says "not supported" > instead of "ok". > > and also in the configure summary at the end: > enable_cxx_runtime_hack: yes > > If this is always needed for our native TL binaries, I'm going to change > the Autoconf macro that checks for it to abort if > --enable-native-texlive-build is given and the necessary options aren't > discovered. (Having just wasted some time trying to figure out why my > binaries were no longer statically linked and not noticing that crucial > configure line ...) Hi Karl, Your proposed change is fine for Cygwin. Ken From karl at freefriends.org Sat Sep 1 01:14:02 2018 From: karl at freefriends.org (Karl Berry) Date: Fri, 31 Aug 2018 23:14:02 GMT Subject: [tlbuild] dvisvgm-2.5 in TL Message-ID: <201808312314.w7VNE2Ch009761@freefriends.org> I just committed the update of dvisvgm in the TL tree to the new 2.5 release. As usual, I am not sure if all the libgs madness survived the update correctly. If you have a chance, please give it a try ... --thanks, karl. From koch at uoregon.edu Sat Sep 1 18:21:52 2018 From: koch at uoregon.edu (Richard Koch) Date: Sat, 1 Sep 2018 09:21:52 -0700 Subject: [tlbuild] dvisvgm-2.5 in TL In-Reply-To: <201808312314.w7VNE2Ch009761@freefriends.org> References: <201808312314.w7VNE2Ch009761@freefriends.org> Message-ID: <50D9B88B-45B0-4736-8149-74B9C9FCDE61@uoregon.edu> Karl, I built the current sources on the Macintosh (system 10.11.6, El Capitan) without problems. Afterward, I searched the console for "checking for statically linking C++ runtime library". There were many such messages, and all said "not supported." Dick Koch > On Aug 31, 2018, at 4:14 PM, Karl Berry wrote: > > I just committed the update of dvisvgm in the TL tree to the new 2.5 > release. As usual, I am not sure if all the libgs madness survived the > update correctly. If you have a chance, please give it a try ... > --thanks, karl. Karl, I build -------------- next part -------------- An HTML attachment was scrubbed... URL: From asyropoulos at gmail.com Sat Sep 1 20:56:01 2018 From: asyropoulos at gmail.com (Apostolos Syropoulos) Date: Sat, 1 Sep 2018 21:56:01 +0300 Subject: [tlbuild] always static libstdc++? In-Reply-To: <201808311807.w7VI7qbd011748@freefriends.org> References: <201808311807.w7VI7qbd011748@freefriends.org> Message-ID: On OpenIndiana I see the following: $ grep "checking for statically linking C++ runtime library" build.log checking for statically linking C++ runtime library... ok checking for statically linking C++ runtime library... ok checking for statically linking C++ runtime library... ok checking for statically linking C++ runtime library... ok checking for statically linking C++ runtime library... ok checking for statically linking C++ runtime library... ok $ grep enable_cxx_runtime_hack build.log enable_cxx_runtime_hack: yes A.S. -- Apostolos Syropoulos Xanthi, GREECE -------------- next part -------------- An HTML attachment was scrubbed... URL: From mojca.miklavec.lists at gmail.com Sun Sep 2 07:20:06 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 2 Sep 2018 07:20:06 +0200 Subject: [tlbuild] always static libstdc++? In-Reply-To: <201808311807.w7VI7qbd011748@freefriends.org> References: <201808311807.w7VI7qbd011748@freefriends.org> Message-ID: On Fri, 31 Aug 2018 at 20:08, Karl Berry wrote: > > On the other hand, I thought there might be some platforms where we do > distribute binaries with the C++ libraries dynamically linked, for > whatever reason, and that's ok. (So then I wouldn't make that change.) On Mac it seems to be impossible to build it statically, at least not out-of-the-box (maybe it works if one compiles libc++/stdlibc++ from source and links against that one). Mojca From mojca.miklavec.lists at gmail.com Sun Sep 2 12:07:33 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 2 Sep 2018 12:07:33 +0200 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test Message-ID: Hi, Since http://tug.org/svn/texlive?view=revision&revision=48431 (48418 was ok) all Solaris and OpenBSD builders seem to have an issue with uptexdir/gkhuge.test. The content of the test-suite.log is pretty long and contains lots of binary info, but the bottom line is ygkhugeng.err differ: char 1, line 1 (I can send the full log if needed, maybe off-list.) Mojca From h.y.acetaminophen at gmail.com Sun Sep 2 12:12:50 2018 From: h.y.acetaminophen at gmail.com (Hironobu Yamashita) Date: Sun, 2 Sep 2018 19:12:50 +0900 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: References: Message-ID: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> Hi Mojca, > Since > http://tug.org/svn/texlive?view=revision&revision=48431 > (48418 was ok) Hmm, that's strange enough; the test failing is under uptexdir, but the commit r48431 affects only pmpostdir. Also, Linux (Travis CI) and my macOS are successful. Could you send the full log off-list? Thanks, Hironobu From mojca.miklavec.lists at gmail.com Sun Sep 2 12:32:35 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 2 Sep 2018 12:32:35 +0200 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> Message-ID: On Sun, 2 Sep 2018 at 12:12, Hironobu Yamashita wrote: > > > Since > > http://tug.org/svn/texlive?view=revision&revision=48431 > > (48418 was ok) > > Hmm, that's strange enough; the test failing is under uptexdir, > but the commit r48431 affects only pmpostdir. > Also, Linux (Travis CI) and my macOS are successful. The Linux, Mac and FreeBSD builds all went fine on my end as well, it's only OpenBSD (clang) and Solaris (gcc 5.5) which seem to be affected. > Could you send the full log off-list? Sure. Mojca From mojca.miklavec.lists at gmail.com Sun Sep 2 17:10:43 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 2 Sep 2018 17:10:43 +0200 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> Message-ID: Hi, On Sun, 2 Sep 2018 at 12:40, Hironobu Yamashita wrote: > > Sorry, the "strict test" for uptftopl (under uptexdir/) introduced in r48429 > should be the culprit for the failure. > (The commit r48431 has nothing to do with it.) I'm sorry, I should have worded it in a more appropriate / accurate way. I only knew that r48418 was ok and that that any commit between 48419 and 48431 could have introduced the problem (I'm only building it once per day at most, so intermediate builds were skipped). > Please try > $ uptftopl /path/to/uptexdir/tests/gkhugeng.tfm 1>gk1.txt 2>gk2.txt > and send gk1.txt and gk2.txt. $ cat gk1.txt (COMMENT THIS IS A KANJI FORMAT FILE) $ cat gk2.txt Input file is in YOKO-kumi kanji tfm format. The fifth byte of the input file exceeds 127! Sorry, but I can't go on; are you sure this is a TFM? Mojca From h.y.acetaminophen at gmail.com Sun Sep 2 17:44:23 2018 From: h.y.acetaminophen at gmail.com (Hironobu Yamashita) Date: Mon, 3 Sep 2018 00:44:23 +0900 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> Message-ID: <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> Mojca, > $ cat gk2.txt > Input file is in YOKO-kumi kanji tfm format. > The fifth byte of the input file exceeds 127! > Sorry, but I can't go on; are you sure this is a TFM? That's the expected behavior, thus the test should never fail! I can't understand why it is failing. In more detail, (as you might have already looked into it,) gkhuge.test compares the stderr (= redirected to ygkhugeng.err, which is similar to gk2.txt above) and the distributed gkhugeng.err. If the test really fails with ygkhugeng.err differ: char 1, line 1 then the possibilities are: * the shell could not redirect stderr to a file ygkhugeng.err * there is one or more preceding (invisible?) characters inside it * (I can't think of others) Hironobu From h.y.acetaminophen at gmail.com Sun Sep 2 18:06:53 2018 From: h.y.acetaminophen at gmail.com (Hironobu Yamashita) Date: Mon, 3 Sep 2018 01:06:53 +0900 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> Message-ID: <83680778-36A0-4D13-8E5C-3D0BE6A9704F@gmail.com> Hi, > * the shell could not redirect stderr to a file ygkhugeng.err > * there is one or more preceding (invisible?) characters inside it Perhaps I came up with another; I noticed that other testfiles use "cmp" for binaries, "diff" for texts. I want to compare gkhugeng.err and ygkhugeng.err, both in texts; so here should I use "diff"? Hironobu From mojca.miklavec.lists at gmail.com Sun Sep 2 18:07:10 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 2 Sep 2018 18:07:10 +0200 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> Message-ID: Hi, On Sun, 2 Sep 2018 at 17:44, Hironobu Yamashita wrote: > > > $ cat gk2.txt > > Input file is in YOKO-kumi kanji tfm format. > > The fifth byte of the input file exceeds 127! > > Sorry, but I can't go on; are you sure this is a TFM? > > That's the expected behavior, thus the test should never fail! > I can't understand why it is failing. > > In more detail, (as you might have already looked into it,) > gkhuge.test compares the stderr (= redirected to ygkhugeng.err, > which is similar to gk2.txt above) and the distributed gkhugeng.err. > If the test really fails with > ygkhugeng.err differ: char 1, line 1 > then the possibilities are: > > * the shell could not redirect stderr to a file ygkhugeng.err > * there is one or more preceding (invisible?) characters inside it > * (I can't think of others) It looks like something else ends up in the file, maybe due to differences in gnu tools: $ cat ./Work/texk/web2c/uptests/ygkhugeng.err + TEXMFCNF=../../../texk/web2c/../kpathsea Input file is in YOKO-kumi kanji tfm format. The fifth byte of the input file exceeds 127! Sorry, but I can't go on; are you sure this is a TFM? Mojca From mojca.miklavec.lists at gmail.com Sun Sep 2 18:13:24 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 2 Sep 2018 18:13:24 +0200 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: <83680778-36A0-4D13-8E5C-3D0BE6A9704F@gmail.com> References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> <83680778-36A0-4D13-8E5C-3D0BE6A9704F@gmail.com> Message-ID: On Sun, 2 Sep 2018 at 18:06, Hironobu Yamashita wrote: > > Hi, > > > * the shell could not redirect stderr to a file ygkhugeng.err > > * there is one or more preceding (invisible?) characters inside it > > Perhaps I came up with another; > I noticed that other testfiles use "cmp" for binaries, "diff" for texts. > I want to compare gkhugeng.err and ygkhugeng.err, both in texts; > so here should I use "diff"? Diff would tell you what exactly was different (which might have been more helpful than knowing that the first character was different, leading to one or two less emails flying back and forth), so I guess it would help to use diff. But of course it wouldn't solve the problem at hand. Mojca From h.y.acetaminophen at gmail.com Sun Sep 2 18:29:23 2018 From: h.y.acetaminophen at gmail.com (Hironobu Yamashita) Date: Mon, 3 Sep 2018 01:29:23 +0900 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> <83680778-36A0-4D13-8E5C-3D0BE6A9704F@gmail.com> Message-ID: <15C511FA-8D2D-411E-8C6B-48E21DF5A928@gmail.com> > It looks like something else ends up in the file, maybe due to > differences in gnu tools: > > $ cat ./Work/texk/web2c/uptests/ygkhugeng.err > + TEXMFCNF=../../../texk/web2c/../kpathsea > Input file is in YOKO-kumi kanji tfm format. > The fifth byte of the input file exceeds 127! > Sorry, but I can't go on; are you sure this is a TFM? Thank you very much, now I understand! I think I can sort gkhuge.test to first set TEXMFCNF, instead of setting it at each one-line execution. That would avoid such differences in gnutools. > Diff would tell you what exactly was different (which might have been > more helpful than knowing that the first character was different, > leading to one or two less emails flying back and forth), so I guess > it would help to use diff. Thanks for your advice; I'll switch to diff for the future ;-) As it's well past midnight here in Japan, the fix will be tomorrow Best, Hironobu From simon at getthingsfixed.co.uk Mon Sep 3 10:31:43 2018 From: simon at getthingsfixed.co.uk (Simon Dales) Date: Mon, 03 Sep 2018 09:31:43 +0100 Subject: [tlbuild] always static libstdc++? In-Reply-To: References: <201808311807.w7VI7qbd011748@freefriends.org> Message-ID: <1535963503.5481.224.camel@pollock.ts.npl> On Sat, 2018-09-01 at 21:56 +0300, Apostolos Syropoulos wrote: > On OpenIndiana I see the following: > > $ grep "checking for statically linking C++ runtime library" > build.log > checking for statically linking C++ runtime library... ok > checking for statically linking C++ runtime library... ok > checking for statically linking C++ runtime library... ok > checking for statically linking C++ runtime library... ok > checking for statically linking C++ runtime library... ok > checking for statically linking C++ runtime library... ok > $ grep enable_cxx_runtime_hack build.log > enable_cxx_runtime_hack: yes (update sources, run ./Build with xindy) Same on RPi. //////////////// Simon > From h.y.acetaminophen at gmail.com Mon Sep 3 14:28:15 2018 From: h.y.acetaminophen at gmail.com (Hironobu Yamashita) Date: Mon, 3 Sep 2018 21:28:15 +0900 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: <15C511FA-8D2D-411E-8C6B-48E21DF5A928@gmail.com> References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> <83680778-36A0-4D13-8E5C-3D0BE6A9704F@gmail.com> <15C511FA-8D2D-411E-8C6B-48E21DF5A928@gmail.com> Message-ID: Hi, > I think I can sort gkhuge.test to first set TEXMFCNF, > instead of setting it at each one-line execution. > That would avoid such differences in gnu tools. > I'll switch to diff for the future ;-) Done, r48558. Travis CI (Linux) seems OK, and my macOS is fine. Please check if it passes on Solaris/OpenBSD. Hironobu From mojca.miklavec.lists at gmail.com Mon Sep 3 16:22:31 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Mon, 3 Sep 2018 16:22:31 +0200 Subject: [tlbuild] FAIL: uptexdir/gkhuge.test In-Reply-To: References: <3B4FC99F-2ABA-4362-BBB5-1C3323F1331A@gmail.com> <8C094879-34C9-473D-8921-1BACBA7FD60B@gmail.com> <5281136C-97C5-41CF-8512-02ADA07FD62F@gmail.com> <83680778-36A0-4D13-8E5C-3D0BE6A9704F@gmail.com> <15C511FA-8D2D-411E-8C6B-48E21DF5A928@gmail.com> Message-ID: On Mon, 3 Sep 2018 at 14:28, Hironobu Yamashita wrote: > > Hi, > > > I think I can sort gkhuge.test to first set TEXMFCNF, > > instead of setting it at each one-line execution. > > That would avoid such differences in gnu tools. > > > I'll switch to diff for the future ;-) > > Done, r48558. Travis CI (Linux) seems OK, and my macOS is fine. > Please check if it passes on Solaris/OpenBSD. Thank you very much. The first out of seven builds succeeded. I'll let the other ones run on their regular daily schedule a few hours from now, but I assume the problem is fixed for all. Thanks again, Mojca From henrimenke at gmail.com Tue Sep 4 06:55:19 2018 From: henrimenke at gmail.com (Henri Menke) Date: Tue, 4 Sep 2018 16:55:19 +1200 Subject: [tlbuild] ttf2afm test failing on Mac OS X Message-ID: Dear list, I realized that Travis CI on GitHub comes with XQuartz, so all the required dependencies for building TeX Live are there. Hence I added another build job to the Travis configuration (https://git.io/fA4gH). Amazingly, TeX Live builds on the first try! Unfortunately though, one of the tests is failing. FAIL: pdftexdir/ttf2afm.test The reason I am writing to the list is that I don't have a Mac to reproduce this issue locally. I would appreciate any hints. You can access the full build log here https://api.travis-ci.org/v3/job/424165569/log.txt Cheers, Henri From preining at logic.at Tue Sep 4 09:29:38 2018 From: preining at logic.at (Norbert Preining) Date: Tue, 4 Sep 2018 16:29:38 +0900 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: References: Message-ID: <20180904072938.GB3648@bulldog.preining.info> On Tue, 04 Sep 2018, Henri Menke wrote: > FAIL: pdftexdir/ttf2afm.test > https://api.travis-ci.org/v3/job/424165569/log.txt The log does not help as we need the log file of the test run, which is in the Work directory. And I don't have a mac myself either ;-) Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From mojca.miklavec.lists at gmail.com Tue Sep 4 09:39:29 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Tue, 4 Sep 2018 09:39:29 +0200 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: References: Message-ID: Dear Henri, On Tue, 4 Sep 2018 at 06:55, Henri Menke wrote: > > Dear list, > > I realized that Travis CI on GitHub comes with XQuartz, so all the > required dependencies for building TeX Live are there. Hence I added > another build job to the Travis configuration (https://git.io/fA4gH). > Amazingly, TeX Live builds on the first try! > > Unfortunately though, one of the tests is failing. > > FAIL: pdftexdir/ttf2afm.test > > The reason I am writing to the list is that I don't have a Mac to > reproduce this issue locally. I would appreciate any hints. > You can access the full build log here > https://api.travis-ci.org/v3/job/424165569/log.txt I will check it again now, but last time it was an issue of sed: RE error: illegal byte sequence which would depend on locale setting on the machine. Mojca From mojca.miklavec.lists at gmail.com Tue Sep 4 10:46:55 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Tue, 4 Sep 2018 10:46:55 +0200 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: References: Message-ID: On Tue, 4 Sep 2018 at 09:39, Mojca Miklavec wrote: > On Tue, 4 Sep 2018 at 06:55, Henri Menke wrote: > > > > I realized that Travis CI on GitHub comes with XQuartz, so all the > > required dependencies for building TeX Live are there. Hence I added > > another build job to the Travis configuration (https://git.io/fA4gH). > > Amazingly, TeX Live builds on the first try! > > > > Unfortunately though, one of the tests is failing. > > > > FAIL: pdftexdir/ttf2afm.test > > > > The reason I am writing to the list is that I don't have a Mac to > > reproduce this issue locally. I would appreciate any hints. > > You can access the full build log here > > https://api.travis-ci.org/v3/job/424165569/log.txt > > I will check it again now, but last time it was an issue of > sed: RE error: illegal byte sequence > which would depend on locale setting on the machine. I hope that http://tug.org/svn/texlive?view=revision&revision=48573 fixes the problem. (Does this need to go upstream to pdfTeX repository?) Mojca From karl at freefriends.org Tue Sep 4 23:23:38 2018 From: karl at freefriends.org (Karl Berry) Date: Tue, 4 Sep 2018 21:23:38 GMT Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: Message-ID: <201809042123.w84LNcmk009714@freefriends.org> (Does this need to go upstream to pdfTeX repository?) Yes, and I always merge commits from TL back into pdftex as needed / for the yearly pdftex update / etc. --thanks, karl. From henrimenke at gmail.com Wed Sep 5 01:08:48 2018 From: henrimenke at gmail.com (Henri Menke) Date: Wed, 5 Sep 2018 11:08:48 +1200 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: References: Message-ID: <9a5ad210-a23f-b2ce-09dd-dfee69166b30@gmail.com> On 04/09/18 20:46, Mojca Miklavec wrote: > On Tue, 4 Sep 2018 at 09:39, Mojca Miklavec wrote: >> On Tue, 4 Sep 2018 at 06:55, Henri Menke wrote: >>> >>> I realized that Travis CI on GitHub comes with XQuartz, so all the >>> required dependencies for building TeX Live are there. Hence I added >>> another build job to the Travis configuration (https://git.io/fA4gH). >>> Amazingly, TeX Live builds on the first try! >>> >>> Unfortunately though, one of the tests is failing. >>> >>> FAIL: pdftexdir/ttf2afm.test >>> >>> The reason I am writing to the list is that I don't have a Mac to >>> reproduce this issue locally. I would appreciate any hints. >>> You can access the full build log here >>> https://api.travis-ci.org/v3/job/424165569/log.txt >> >> I will check it again now, but last time it was an issue of >> sed: RE error: illegal byte sequence >> which would depend on locale setting on the machine. > > I hope that > http://tug.org/svn/texlive?view=revision&revision=48573 > fixes the problem. Thank you Mojca! That works perfectly. However, there were other tests which were failing as well for the same reason, so I just set before_script: - export LC_ALL=C - export LANG=C in the Travis configuration. Now it builds without issues on the Xcode 9.4.1 (OS X 10.13) image on Travis. I'm now trying to downgrade the Xcode version for backwards compatibility. Maybe Travis can then be used to build official TeX Live binaries for the next release. Cheers, Henri > > (Does this need to go upstream to pdfTeX repository?) > > Mojca > From karl at freefriends.org Wed Sep 5 01:18:32 2018 From: karl at freefriends.org (Karl Berry) Date: Tue, 04 Sep 2018 17:18:32 -0600 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: <9a5ad210-a23f-b2ce-09dd-dfee69166b30@gmail.com> (message from Henri Menke on Wed, 5 Sep 2018 11:08:48 +1200) Message-ID: <86r2i8vol3.fsf@frenzy.freefriends.org> - export LC_ALL=C - export LANG=C Doubt it matters, but if the configuration is supposed to be shell-agnostic, that should be - LC_ALL=C; export LC_ALL - LANG=C; export LANG From karl at freefriends.org Wed Sep 5 01:20:03 2018 From: karl at freefriends.org (Karl Berry) Date: Tue, 04 Sep 2018 17:20:03 -0600 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: <9a5ad210-a23f-b2ce-09dd-dfee69166b30@gmail.com> (message from Henri Menke on Wed, 5 Sep 2018 11:08:48 +1200) Message-ID: <86o9dcvoik.fsf@frenzy.freefriends.org> before_script: - export LC_ALL=C - export LANG=C Also, I suppose we should change the sources. -k From preining at logic.at Wed Sep 5 01:22:21 2018 From: preining at logic.at (Norbert Preining) Date: Wed, 5 Sep 2018 08:22:21 +0900 Subject: [tlbuild] ttf2afm test failing on Mac OS X In-Reply-To: <86o9dcvoik.fsf@frenzy.freefriends.org> References: <9a5ad210-a23f-b2ce-09dd-dfee69166b30@gmail.com> <86o9dcvoik.fsf@frenzy.freefriends.org> Message-ID: <20180904232221.GB25915@bulldog.preining.info> > Also, I suppose we should change the sources. -k Yes please! Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From henrimenke at gmail.com Wed Sep 5 01:50:42 2018 From: henrimenke at gmail.com (Henri Menke) Date: Wed, 5 Sep 2018 11:50:42 +1200 Subject: [tlbuild] Mac OS X build target on Travis CI Message-ID: Dear list, I was able to build TeX Live on Travis CI with Mac OS X 10.11 and Xcode 7.3. I wanted to use Mac OS X 10.10 with Xcode 6.4 but unfortunately this does not come with XQuartz. The updated Travis configuration can be found here: https://github.com/hmenke/texlive-source/blob/travis/.travis.yml I would appreciate if you could push this upstream. Perhaps this can be used to generate the binaries for future TeX Live releases. Cheers, Henri From preining at logic.at Wed Sep 5 05:52:49 2018 From: preining at logic.at (Norbert Preining) Date: Wed, 5 Sep 2018 12:52:49 +0900 Subject: [tlbuild] Mac OS X build target on Travis CI In-Reply-To: References: Message-ID: <20180905035249.GA3508@bulldog.preining.info> Hi Henri, > I would appreciate if you could push this upstream. Perhaps this can be Thanks, included in the svn repo from which it will find it's way into the git mirror. > used to generate the binaries for future TeX Live releases. I think this is mostly done by Dick Koch when preparing MacTeX, but we will see. Thanks a lot Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From preining at logic.at Wed Sep 5 06:24:10 2018 From: preining at logic.at (Norbert Preining) Date: Wed, 5 Sep 2018 13:24:10 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm Message-ID: <20180905042410.GC3508@bulldog.preining.info> Hi I just want to build some packges for Debian, but the build process stops because dvisvgm does not find xxhash.h: make[7]: Entering directory '/build/texlive-bin-2018.20180905.48574/Work/texk/dvisvgm/dvisvgm-src/src' g++ -DHAVE_CONFIG_H -I. -I../../../../../texk/dvisvgm/dvisvgm-src/src -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wimplicit -Wreturn-type -Wnon-virtual-dtor -Wno-mismatched-tags -I../../../../../texk/dvisvgm/dvisvgm-src/libs/clipper -I../../../../../texk/dvisvgm/dvisvgm-src/libs/variant/include -I/build/texlive-bin-2018.20180905.48574/Work/texk -I/build/texlive-bin-2018.20180905.48574/texk -I/usr/include/freetype2 -I/usr/include/libpng16 -g -O2 -fdebug-prefix-map=/build/texlive-bin-2018.20180905.48574=. -fstack-protector-strong -Wformat -Werror=format-security -c -o dvisvgm.o ../../../../../texk/dvisvgm/dvisvgm-src/src/dvisvgm.cpp cc1plus: warning: command line option '-Wimplicit' is valid for C/ObjC but not for C++ ../../../../../texk/dvisvgm/dvisvgm-src/src/dvisvgm.cpp:29:10: fatal error: xxhash.h: No such file or directory #include ^~~~~~~~~~ compilation terminated. The file is there in dvisvgm-src/libs/xxHash/xxhash.h but that path is not added to the include path like clipper etc. The configure options are --enable-shared \ --with-system-zlib \ --with-system-zzlib \ --with-system-potrace \ --with-system-graphite2 \ --with-system-harfbuzz \ --with-system-libgs \ --with-system-pixman \ --with-system-libpaper \ --with-system-zziplib \ --with-system-icu \ --with-system-gmp \ --with-system-mpfr \ --with-system-freetype2 \ --with-freetype2-include=/usr/include/freetype2 \ --with-system-libpng \ --with-system-gd \ --with-system-cairo \ --with-x \ --with-mf-x-toolkit \ --with-xdvi-x-toolkit=xaw \ --disable-lcdf-typetools \ --disable-biber \ --disable-dvipng \ --disable-ps2eps \ --disable-psutils \ --disable-t1utils \ --disable-cjkutils \ --disable-chktex \ --disable-dvidvi \ --disable-lacheck \ --disable-texdoctk \ --disable-ttf2pk \ --enable-ttf2pk2 \ --enable-ipc Has anyone seen similar problems? The configure output from dvisvgm doesn't say a lot: checking for gcc... (cached) gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking for ar... (cached) ar checking the archiver (ar) interface... ar checking for a BSD-compatible install... (cached) /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) mawk checking whether make sets $(MAKE)... (cached) yes checking whether make supports the include directive... yes (GNU style) checking whether make supports nested variables... (cached) yes checking build system type... (cached) x86_64-pc-linux-gnu checking host system type... (cached) x86_64-pc-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... (cached) /bin/sed checking for grep that handles long lines and -e... (cached) /bin/grep checking for egrep... (cached) /bin/grep -E checking for fgrep... (cached) /bin/grep -F checking for ld used by gcc... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes checking for BSD- or MS-compatible name lister (nm)... (cached) /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... (cached) BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... (cached) 1572864 checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... (cached) func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... (cached) func_convert_file_noop checking for /usr/bin/ld option to reload object files... (cached) -r checking for objdump... (cached) objdump checking how to recognize dependent libraries... (cached) pass_all checking for dlltool... no checking how to associate runtime and link libraries... (cached) printf %s\n checking for archiver @FILE support... (cached) @ checking for strip... (cached) strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc object... (cached) ok checking for sysroot... no checking for a working dd... (cached) /bin/dd checking how to truncate binary pipes... (cached) /bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... (cached) no checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking for dlfcn.h... (cached) yes checking dependency style of gcc... (cached) none checking whether to enable maintainer-specific portions of Makefiles... no checking whether the compiler accepts prototypes... (cached) yes checking what warning flags to pass to the C compiler... (cached) -Wimplicit -Wreturn-type checking for objdir... (cached) .libs checking if gcc supports -fno-rtti -fno-exceptions... (cached) no checking for gcc option to produce PIC... (cached) -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... (cached) yes checking if gcc static flag -static works... (cached) yes checking if gcc supports -c -o file.o... (cached) yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... (cached) no checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for special C compiler options needed for large files... (cached) no checking for _FILE_OFFSET_BITS value needed for large files... (cached) no checking for _LARGEFILE_SOURCE value needed for large files... (cached) no checking for dirent.h that defines DIR... (cached) yes checking for library containing opendir... (cached) none required checking for ANSI C header files... (cached) yes checking whether closedir returns void... (cached) no checking for assert.h... (cached) yes checking for float.h... (cached) yes checking for limits.h... (cached) yes checking for pwd.h... (cached) yes checking for stdlib.h... (cached) yes checking for sys/param.h... (cached) yes checking for putenv... (cached) yes checking for getcwd... (cached) yes checking for getwd... (cached) yes checking for memcmp... (cached) yes checking for memcpy... (cached) yes checking for mkstemp... (cached) yes checking for mktemp... (cached) yes checking for strchr... (cached) yes checking for strrchr... (cached) yes checking for an ANSI C-conforming const... (cached) yes checking for inline... (cached) inline checking for size_t... (cached) yes checking for int64_t... (cached) yes checking for uint64_t... (cached) yes checking whether isascii is declared... (cached) yes checking for struct stat.st_mtim... (cached) yes checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking for gcc option to accept ISO C99... (cached) none needed checking for g++... (cached) g++ checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking dependency style of g++... (cached) none checking what warning flags to pass to the C++ compiler... (cached) -Wreturn-type -Wno-write-strings checking how to run the C++ preprocessor... (cached) g++ -E checking for ld used by g++... (cached) /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... (cached) -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... (cached) yes checking if g++ static flag -static works... (cached) yes checking if g++ supports -c -o file.o... (cached) yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether g++ supports C++11 features by default... (cached) yes checking for ranlib... (cached) ranlib checking for sys/time.h... (cached) yes checking for sys/timeb.h... (cached) yes checking xlocale.h usability... no checking xlocale.h presence... no checking for xlocale.h... no checking whether termios.h defines TIOCGWINSZ... no checking whether sys/ioctl.h defines TIOCGWINSZ... yes checking for native WIN32 or MINGW32... (cached) no configure: creating ./config.lt config.lt: creating libtool checking for pkg-config... (cached) pkg-config checking if libkpathsea supports debugging... (cached) yes checking if defines 'z_const'... (cached) yes checking for freetype-config... (cached) freetype-config checking for pkg-config... (cached) pkg-config checking if defines 'z_const'... (cached) yes checking ghostscript/iapi.h usability... yes checking ghostscript/iapi.h presence... yes checking for ghostscript/iapi.h... yes checking for gsapi_revision in -lgs... yes configure: not linking to libgs, trying to arrange for dynamic loading checking for library containing dlopen... (cached) -ldl checking for dlfcn.h... (cached) yes checking for dlopen... yes checking for gzopen... yes checking for FT_Init_FreeType... yes checking for kpse_set_program_name... yes checking for dirent.h that defines DIR... (cached) yes checking for library containing opendir... (cached) none required checking for ANSI C header files... (cached) yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for unistd.h... (cached) yes checking for stdbool.h that conforms to C99... (cached) yes checking for _Bool... (cached) yes checking for size_t... (cached) yes checking whether struct tm is in sys/time.h or time.h... (cached) time.h checking whether lstat correctly handles trailing slash... yes checking whether stat accepts an empty string... no checking for ftime... (cached) yes checking for gettimeofday... (cached) yes checking for sigaction... yes checking for umask... yes checking for uselocale... yes configure: updating cache ../../config.cache checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating dvisvgm-src/Makefile config.status: creating dvisvgm-src/libs/Makefile config.status: creating dvisvgm-src/libs/brotli/Makefile config.status: creating dvisvgm-src/libs/clipper/Makefile config.status: creating dvisvgm-src/libs/ff-woff/Makefile config.status: creating dvisvgm-src/libs/potrace/Makefile config.status: creating dvisvgm-src/libs/variant/Makefile config.status: creating dvisvgm-src/libs/woff2/Makefile config.status: creating dvisvgm-src/libs/xxHash/Makefile config.status: creating dvisvgm-src/src/Makefile config.status: creating dvisvgm-src/src/version.hpp config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands Making all in dvisvgm All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From karl at freefriends.org Wed Sep 5 23:26:30 2018 From: karl at freefriends.org (Karl Berry) Date: Wed, 5 Sep 2018 21:26:30 GMT Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <20180905042410.GC3508@bulldog.preining.info> Message-ID: <201809052126.w85LQUb9025402@freefriends.org> np> The file is there in dvisvgm-src/libs/xxHash/xxhash.h but that path is not added to the include path like clipper etc. Norbert: Without --enable-bundled-libs, my surprise is more that clipper is included than xxhash is not. But I don't know Martin's intent for the different libraries. Martin: please see https://tug.org/pipermail/tlbuild/2018q3/004267.html for Norbert's original report. --thanks, karl. From preining at logic.at Thu Sep 6 03:30:15 2018 From: preining at logic.at (Norbert Preining) Date: Thu, 6 Sep 2018 10:30:15 +0900 Subject: [tlbuild] luatex 1.08 in TL cannot be built with --with-system-gmp Message-ID: <20180906013015.GC4225@bulldog.preining.info> Hi Luigi, hi all, configuring current TL sources with --with-system-gmp I get an error: gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/usr/include/libpng16 -I/home/norbert/Development/TeX/texlive.git/Build/source/foo/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/texk -I../../../texk/web2c/mplibdir -Wimplicit -Wreturn-type -g -O2 -MT libmplibcore_a-mpmathbinary.o -MD -MP -MF .deps/libmplibcore_a-mpmathbinary.Tpo -c -o libmplibcore_a-mpmathbinary.o `test -f 'mpmathbinary.c' || echo '../../../texk/web2c/'`mpmathbinary.c In file included from ../../../texk/web2c/mplibdir/mpmathbinary.w:28: ../../../texk/web2c/mplibdir/mpmathbinary.w:44:10: fatal error: gmp/config.h: No such file or directory #include ^~~~~~~~~~~~~~ compilation terminated. Debian's libgmp-dev does not ship gmp/config.h only gmp.h Is it now necessary to build with the TL shipped libgmp? Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From preining at logic.at Thu Sep 6 04:20:08 2018 From: preining at logic.at (Norbert Preining) Date: Thu, 6 Sep 2018 11:20:08 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <201809052126.w85LQUb9025402@freefriends.org> References: <20180905042410.GC3508@bulldog.preining.info> <201809052126.w85LQUb9025402@freefriends.org> Message-ID: <20180906022008.GA21614@bulldog.preining.info> Hi Karl, Martin, > Norbert: Without --enable-bundled-libs, my surprise is more that clipper > is included than xxhash is not. But I don't know Martin's intent for the > different libraries. I found that the difference is with --disable-native-texlive-build FAIL ../configure --disable-all-pkgs --enable-dvisvgm --disable-native-texlive-build SUCCESS ../configure --disable-all-pkgs --enable-dvisvgm Looking at the .ac and .am files nothing obvious jumps at me, though. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From norbert at preining.info Thu Sep 6 04:54:43 2018 From: norbert at preining.info (Norbert Preining) Date: Thu, 6 Sep 2018 11:54:43 +0900 Subject: [tlbuild] luatex build breaks in current TL Message-ID: <20180906025443.GD21614@bulldog.preining.info> Hi Luigi, there are more breakages in TL since the inclusion of the current luatex sources (did anyone did test builds before committing???) Travis-CI complains since the last commits, error excerpt: gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/texlive/Work/texk/ptexenc -I/texlive/texk/ptexenc -I/texlive/Work/texk -I/texlive/texk -Wimplicit -Wreturn-type -Wdeclaration-after-statement -Wno-unknown-pragmas -g -O2 -MT ptexdir/libkanji_a-kanji.o -MD -MP -MF ptexdir/.deps/libkanji_a-kanji.Tpo -c -o ptexdir/libkanji_a-kanji.o `test -f 'ptexdir/kanji.c' || echo '../../../texk/web2c/'`ptexdir/kanji.c mv -f ptexdir/.deps/libkanji_a-kanji.Tpo ptexdir/.deps/libkanji_a-kanji.Po make[5]: *** No rule to make target 'luatexdir/lua/helpers.w', needed by 'helpers.c'. Stop. make[5]: *** Waiting for unfinished jobs.... make[5]: Leaving directory '/texlive/Work/texk/web2c' Full log https://api.travis-ci.org/v3/job/425011985/log.txt Enjoy Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From norbert at preining.info Thu Sep 6 04:55:30 2018 From: norbert at preining.info (Norbert Preining) Date: Thu, 6 Sep 2018 11:55:30 +0900 Subject: [tlbuild] luatex 1.08 in TL cannot be built with --with-system-gmp In-Reply-To: <20180906013015.GC4225@bulldog.preining.info> References: <20180906013015.GC4225@bulldog.preining.info> Message-ID: <20180906025530.GE21614@bulldog.preining.info> Reposting to dev-luatex, seems to be the appropriate place. On Thu, 06 Sep 2018, Norbert Preining wrote: > Hi Luigi, hi all, > > configuring current TL sources with > --with-system-gmp > I get an error: > gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/usr/include/libpng16 -I/home/norbert/Development/TeX/texlive.git/Build/source/foo/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/texk -I../../../texk/web2c/mplibdir -Wimplicit -Wreturn-type -g -O2 -MT libmplibcore_a-mpmathbinary.o -MD -MP -MF .deps/libmplibcore_a-mpmathbinary.Tpo -c -o libmplibcore_a-mpmathbinary.o `test -f 'mpmathbinary.c' || echo '../../../texk/web2c/'`mpmathbinary.c > In file included from ../../../texk/web2c/mplibdir/mpmathbinary.w:28: > ../../../texk/web2c/mplibdir/mpmathbinary.w:44:10: fatal error: gmp/config.h: No such file or directory > #include > ^~~~~~~~~~~~~~ > compilation terminated. > > > Debian's libgmp-dev does not ship > gmp/config.h > only > gmp.h > > Is it now necessary to build with the TL shipped libgmp? Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From kakuto at fuk.kindai.ac.jp Thu Sep 6 05:10:04 2018 From: kakuto at fuk.kindai.ac.jp (Akira Kakuto) Date: Thu, 6 Sep 2018 12:10:04 +0900 Subject: [tlbuild] luatex build breaks in current TL In-Reply-To: <20180906025443.GD21614@bulldog.preining.info> References: <20180906025443.GD21614@bulldog.preining.info> Message-ID: Hi Norbert, > there are more breakages in TL since the inclusion of the current luatex > sources (did anyone did test builds before committing???) > > Travis-CI complains since the last commits, error excerpt: Probably because reautoconf is not done yet. Thanks, Akira From luigi.scarso at gmail.com Thu Sep 6 05:46:47 2018 From: luigi.scarso at gmail.com (luigi scarso) Date: Thu, 6 Sep 2018 05:46:47 +0200 Subject: [tlbuild] [Dev-luatex] luatex build breaks in current TL In-Reply-To: References: <20180906025443.GD21614@bulldog.preining.info> Message-ID: Il gio 6 set 2018, 05:10 Akira Kakuto ha scritto: > Hi Norbert, > > > there are more breakages in TL since the inclusion of the current luatex > > sources (did anyone did test builds before committing???) > > > > Travis-CI complains since the last commits, error excerpt: > > Probably because reautoconf is not done yet. > > Thanks, > Akira > Hm, perhaps I have forgotten to update some autotools files..I will rebuild later. Luatex now include mplib without binary mode, i.e no more mpfr and gmp dependencies. Metapost still has the full math modes, so it needs gmp and mpfr. Luatex also doesn't need poppler anymore, and hence no need for c++ also. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From preining at logic.at Thu Sep 6 06:28:12 2018 From: preining at logic.at (Norbert Preining) Date: Thu, 6 Sep 2018 13:28:12 +0900 Subject: [tlbuild] luatex build breaks in current TL In-Reply-To: References: <20180906025443.GD21614@bulldog.preining.info> Message-ID: <20180906042812.GF21614@bulldog.preining.info> > Probably because reautoconf is not done yet. Unfortunately not, doing a reautoconf and Build breaks at gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/mpfr/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/gmp/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/cairo/cairo -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/pixman/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/libpng/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/zlib/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/ptexenc -I/home/norbert/Development/TeX/texlive.git/Build/source/texk/ptexenc -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/texk -I../../../texk/web2c/mplibdir -Wimplicit -Wreturn-type -g -O2 -MT pmpost-pmpmathbinary.o -MD -MP -MF .deps/pmpost-pmpmathbinary.Tpo -c -o pmpost-pmpmathbinary.o `test -f 'pmpmathbinary.c' || echo '../../../texk/web2c/'`pmpmathbinary.c In file included from ../../../texk/web2c/mplibdir/mpmathbinary.w:28: ../../../texk/web2c/mplibdir/mpmathbinary.w:44:10: fatal error: gmp/config.h: No such file or directory #include ^~~~~~~~~~~~~~ compilation terminated. THere is -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/gmp/include and that directory contains gmp.h -> ../gmp.h But since gmp/config.h is searched, one needs to add .../source/Work/libs to the include path ... or fix the include statement. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From preining at logic.at Thu Sep 6 06:30:12 2018 From: preining at logic.at (Norbert Preining) Date: Thu, 6 Sep 2018 13:30:12 +0900 Subject: [tlbuild] [Dev-luatex] luatex build breaks in current TL In-Reply-To: References: <20180906025443.GD21614@bulldog.preining.info> Message-ID: <20180906043012.GG21614@bulldog.preining.info> Hi Luigi > Hm, perhaps I have forgotten to update some autotools files..I will rebuild > later. Thanks > dependencies. Metapost still has the full math modes, so it needs gmp and > mpfr. Please also look into the #include thingy, thanks. > Luatex also doesn't need poppler anymore, and hence no need for c++ also. It would be GREAT if we could use the new replacement library *all*over* TeX Live and finally eradicate poppler from TL. One of the sources of my nightmares it is this poppler. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From luigi.scarso at gmail.com Thu Sep 6 06:52:33 2018 From: luigi.scarso at gmail.com (luigi scarso) Date: Thu, 6 Sep 2018 06:52:33 +0200 Subject: [tlbuild] [Dev-luatex] luatex build breaks in current TL In-Reply-To: <20180906043012.GG21614@bulldog.preining.info> References: <20180906025443.GD21614@bulldog.preining.info> <20180906043012.GG21614@bulldog.preining.info> Message-ID: Il gio 6 set 2018, 06:30 Norbert Preining ha scritto > > > > It would be GREAT if we could use the new replacement library *all*over* > TeX Live and finally eradicate poppler from TL. One of the sources of my > nightmares it is this poppler. > I think that it's better to keep poppler in texlive for the next 2019; pplib in luatex seems to be faster than poppler, and the size of the binary is smaller, but we still have some issues with some pdf and I have not checked it on all platforms . It's better to test it only in luatex for now, but yes ,as poppler replacement for texlive it makes sense. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From preining at logic.at Thu Sep 6 07:04:31 2018 From: preining at logic.at (Norbert Preining) Date: Thu, 6 Sep 2018 14:04:31 +0900 Subject: [tlbuild] [Dev-luatex] luatex build breaks in current TL In-Reply-To: References: <20180906025443.GD21614@bulldog.preining.info> <20180906043012.GG21614@bulldog.preining.info> Message-ID: <20180906050431.GA8711@bulldog.preining.info> > now, but yes ,as poppler replacement for texlive it makes sense. I would be happy if by 2021 we could get rid of poppler, 2020 would even better ;-) Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From luigi.scarso at gmail.com Thu Sep 6 12:29:51 2018 From: luigi.scarso at gmail.com (luigi scarso) Date: Thu, 6 Sep 2018 12:29:51 +0200 Subject: [tlbuild] [Dev-luatex] luatex 1.08 in TL cannot be built with --with-system-gmp In-Reply-To: <20180906025530.GE21614@bulldog.preining.info> References: <20180906013015.GC4225@bulldog.preining.info> <20180906025530.GE21614@bulldog.preining.info> Message-ID: On Thu, Sep 6, 2018 at 8:41 AM Norbert Preining wrote: > Reposting to dev-luatex, seems to be the appropriate place. > > On Thu, 06 Sep 2018, Norbert Preining wrote: > > Hi Luigi, hi all, > > > > configuring current TL sources with > > --with-system-gmp > > I get an error: > confirmed , the split between metapost and mplib is not ok --with-system-gmp (pmpost also fails --with-system-gmp=no, so probably I have overlooked something in my local tl tree). -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.gieseking at uos.de Thu Sep 6 13:14:25 2018 From: martin.gieseking at uos.de (Martin Gieseking) Date: Thu, 6 Sep 2018 13:14:25 +0200 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <201809052126.w85LQUb9025402@freefriends.org> References: <201809052126.w85LQUb9025402@freefriends.org> Message-ID: <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> Hi Karl and Norbert, a couple of weeks ago, a Gentoo maintainer asked me to add a configuration option to disable the bundled libraries and to link against the corresponding system libs instead [1]. So I added --enable-bundled-libs (and --disable-bundled-libs) to the configure script which affects brotli, potrace, woff2, and xxhash. I checked a couple of Linux distros previously if they provide these libraries but obviously overlooked Debian not having the original xxhash [2] but only the Go port. Sorry for that. Would it be an option to add the missing package to Debian? It's already used by many different projects and probably worth to have it packaged. > Norbert: Without --enable-bundled-libs, my surprise is more that clipper > is included than xxhash is not. But I don't know Martin's intent for the > different libraries. The bundled clipper library is a slightly modified version. I extended some structures to store information required to reconstruct curved path segments from the straight line segments processed by clipper. Therefore, we can't use the system library here. Best, Martin [1] https://github.com/mgieseki/dvisvgm/issues/90 [2] https://cyan4973.github.io/xxHash From karl at freefriends.org Thu Sep 6 23:19:43 2018 From: karl at freefriends.org (Karl Berry) Date: Thu, 6 Sep 2018 21:19:43 GMT Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <20180906022008.GA21614@bulldog.preining.info> Message-ID: <201809062119.w86LJhf6012426@freefriends.org> I found that the difference is with --disable-native-texlive-build Because I made --native-texlive-build imply dvisvgm's --enable-bundled-libs. Because that is what we want for native TL builds :). -k From preining at logic.at Fri Sep 7 03:48:11 2018 From: preining at logic.at (Norbert Preining) Date: Fri, 7 Sep 2018 10:48:11 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> References: <201809052126.w85LQUb9025402@freefriends.org> <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> Message-ID: <20180907014811.GA3378@burischnitzel.preining.info> Hi Martin, > I checked a couple of Linux distros previously if they provide these > libraries but obviously overlooked Debian not having the original xxhash [2] > but only the Go port. Sorry for that. Would it be an option to add the > missing package to Debian? It's already used by many different projects and > probably worth to have it packaged. For now I will add --enable-bundled-libs and will see whether I can get xxhash into Debian. But that takes normally months to pass through NEW processing. Of course it would be nice if one could select/deselect system libs for each of the bundled libs separately ;-) All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From preining at logic.at Fri Sep 7 03:53:46 2018 From: preining at logic.at (Norbert Preining) Date: Fri, 7 Sep 2018 10:53:46 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> References: <201809052126.w85LQUb9025402@freefriends.org> <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> Message-ID: <20180907015346.GB3378@burischnitzel.preining.info> Hi Karl, hi Martin, > > Norbert: Without --enable-bundled-libs, my surprise is more that clipper No doing ../configure --disable-all-pkgs --enable-dvisvgm --disable-native-texlive-build --enable-bundled-libs I get a nice compile until the loading stage, when it booms out: /bin/bash ../../libtool --tag=CXX --mode=link g++ -Wimplicit -Wreturn-type -Wnon-virtual-dtor -Wno-mismatched-tags -I../../../../../texk/dvisvgm/dvisvgm-src/libs/clipper -I../../../../../texk/dvisvgm/dvisvgm-src/libs/variant/include -I../../../../../texk/dvisvgm/dvisvgm-src/libs/potrace -I../../../../../texk/dvisvgm/dvisvgm-src/libs/xxHash -I../../../../../texk/dvisvgm/dvisvgm-src/libs/brotli/include -I../../../../../texk/dvisvgm/dvisvgm-src/libs/woff2/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/freetype2/freetype2 -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/zlib/include -g -O2 -o dvisvgm dvisvgm.o libdvisvgm.a ../libs/clipper/libclipper.a ../libs/potrace/libpotrace.a ../libs/xxHash/libxxhash.a ../libs/ff-woff/libfontforge.a ../libs/woff2/libwoff2.a ../libs/brotli/libbrotli.a /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/kpathsea/libkpathsea.la /home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/freetype2/libfreetype.a /home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/zlib/libz.a -ldl libtool: link: g++ -Wimplicit -Wreturn-type -Wnon-virtual-dtor -Wno-mismatched-tags -I../../../../../texk/dvisvgm/dvisvgm-src/libs/clipper -I../../../../../texk/dvisvgm/dvisvgm-src/libs/variant/include -I../../../../../texk/dvisvgm/dvisvgm-src/libs/potrace -I../../../../../texk/dvisvgm/dvisvgm-src/libs/xxHash -I../../../../../texk/dvisvgm/dvisvgm-src/libs/brotli/include -I../../../../../texk/dvisvgm/dvisvgm-src/libs/woff2/include -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/texk -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/freetype2/freetype2 -I/home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/zlib/include -g -O2 -o dvisvgm dvisvgm.o libdvisvgm.a ../libs/clipper/libclipper.a ../libs/potrace/libpotrace.a ../libs/xxHash/libxxhash.a ../libs/ff-woff/libfontforge.a ../libs/woff2/libwoff2.a ../libs/brotli/libbrotli.a /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/kpathsea/.libs/libkpathsea.a /home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/freetype2/libfreetype.a /home/norbert/Development/TeX/texlive.git/Build/source/Work/libs/zlib/libz.a -ldl /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::~Ghostscript()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:277: undefined reference to `gsapi_exit' ... The configure says: checking ghostscript/iapi.h usability... yes checking ghostscript/iapi.h presence... yes checking for ghostscript/iapi.h... yes checking for gsapi_revision in -lgs... yes configure: not linking to libgs, trying to arrange for dynamic loading checking for library containing dlopen... -ldl checking for dlfcn.h... (cached) yes checking for dlopen... yes Is there something more done due to the --disable-texlive-native-build? Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From preining at logic.at Fri Sep 7 07:56:06 2018 From: preining at logic.at (Norbert Preining) Date: Fri, 7 Sep 2018 14:56:06 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> References: <201809052126.w85LQUb9025402@freefriends.org> <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> Message-ID: <20180907055606.GA27715@burischnitzel.preining.info> Hi Martin, sorry for all the bug reports ... but > but only the Go port. Sorry for that. Would it be an option to add the > missing package to Debian? It's already used by many different projects and > probably worth to have it packaged. I have packages xxhash and uploaded to Debian, and now tried to compile with libxxhash-dev, libbrotli-dev, libwoff-dev, libpotrace-dev installed, and running ../configure --disable-all-pkgs --enable-dvisvgm --disable-native-texlive-build ... /usr/bin/ld: dvisvgm.o: in function `print_version': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/dvisvgm.cpp:249: undefined reference to `potrace_version' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/dvisvgm.cpp:250: undefined reference to `XXH_versionNumber' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/dvisvgm.cpp:254: undefined reference to `BrotliEncoderVersion' /usr/bin/ld: libdvisvgm.a(GFTracer.o): in function `GFTracer::endChar(unsigned int)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/GFTracer.cpp:61: undefined reference to `potrace_param_default' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/GFTracer.cpp:62: undefined reference to `potrace_trace' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/GFTracer.cpp:63: undefined reference to `potrace_param_free' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/GFTracer.cpp:92: undefined reference to `potrace_state_free' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::~Ghostscript()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:277: undefined reference to `gsapi_exit' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::init(int, char const**, void*)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:252: undefined reference to `gsapi_new_instance' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:307: undefined reference to `gsapi_init_with_args' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::revision(gsapi_revision_s*)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:219: undefined reference to `gsapi_revision' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::revision()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:219: undefined reference to `gsapi_revision' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::error_name(int)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:369: undefined reference to `gs_error_names' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::revisionstr[abi:cxx11]()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:219: undefined reference to `gsapi_revision' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::~Ghostscript()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:266: undefined reference to `gsapi_delete_instance' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::new_instance(void**, void*)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:252: undefined reference to `gsapi_new_instance' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::delete_instance()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:266: undefined reference to `gsapi_delete_instance' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::exit()': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:277: undefined reference to `gsapi_exit' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::set_stdio(int (*)(void*, char*, int), int (*)(void*, char const*, int), int (*)(void*, char const*, int))': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:292: undefined reference to `gsapi_set_stdio' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::init_with_args(int, char**)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:307: undefined reference to `gsapi_init_with_args' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::run_string_begin(int, int*)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:319: undefined reference to `gsapi_run_string_begin' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::run_string_continue(char const*, unsigned int, int, int*)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:338: undefined reference to `gsapi_run_string_continue' /usr/bin/ld: libdvisvgm.a(Ghostscript.o): in function `Ghostscript::run_string_end(int, int*)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Ghostscript.cpp:351: undefined reference to `gsapi_run_string_end' /usr/bin/ld: libdvisvgm.a(TrueTypeFont.o): in function `TrueTypeFont::writeWOFF2(std::ostream&) const': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/TrueTypeFont.cpp:140: undefined reference to `woff2::MaxWOFF2CompressedSize(unsigned char const*, unsigned long)' /usr/bin/ld: /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/TrueTypeFont.cpp:144: undefined reference to `woff2::ConvertTTFToWOFF2(unsigned char const*, unsigned long, unsigned char*, unsigned long*, woff2::WOFF2Params const&)' /usr/bin/ld: libdvisvgm.a(Unicode.o): in function `Unicode::aglNameToCodepoint(std::__cxx11::basic_string, std::allocator > const&)': /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/Unicode.cpp:176: undefined reference to `XXH32' collect2: error: ld returned 1 exit status That means, that none of the shlibs (xxhash, brotli, potrace, gs, woff) are added to the load stage. Looking at the adaptions of TeX Live to your sources I don't see any reason for that, though. All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From martin.gieseking at uos.de Fri Sep 7 10:20:41 2018 From: martin.gieseking at uos.de (Martin Gieseking) Date: Fri, 7 Sep 2018 10:20:41 +0200 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <20180907055606.GA27715@burischnitzel.preining.info> References: <201809052126.w85LQUb9025402@freefriends.org> <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> <20180907055606.GA27715@burischnitzel.preining.info> Message-ID: <01220e60-c822-8c3a-ad1c-66f6b0236944@uos.de> Hi Norbert, > sorry for all the bug reports ... That's not a problem. I'll have a look. :-) > I have packages xxhash and uploaded to Debian, and now tried to compile > with libxxhash-dev, libbrotli-dev, libwoff-dev, libpotrace-dev > installed, and running > ../configure --disable-all-pkgs --enable-dvisvgm --disable-native-texlive-build > > ... > /usr/bin/ld: dvisvgm.o: in function `print_version': > /home/norbert/Development/TeX/texlive.git/Build/source/Work/texk/dvisvgm/dvisvgm-src/src/../../../../../texk/dvisvgm/dvisvgm-src/src/dvisvgm.cpp:249: undefined reference to `potrace_version' [...] > collect2: error: ld returned 1 exit status > > That means, that none of the shlibs (xxhash, brotli, potrace, gs, woff) > are added to the load stage. > > Looking at the adaptions of TeX Live to your sources I don't see any > reason for that, though. Unfortunately I'm not very familiar with the details of TeX Live's build system. As far as I understand the linking issue, configure doesn't set the variables FOO_LIBS, like POTRACE_LIBS. The original dvisvgm config script calls PGK_CHECK_MODULES to get the compiler and linker flags required for the system libraries which in turn populates FOO_CFLAGS and FOO_LIBS. The Makefiles generated by the TL build system don't seem to define them anywhere, though. Martin From preining at logic.at Fri Sep 7 13:12:17 2018 From: preining at logic.at (Norbert Preining) Date: Fri, 7 Sep 2018 20:12:17 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <01220e60-c822-8c3a-ad1c-66f6b0236944@uos.de> References: <201809052126.w85LQUb9025402@freefriends.org> <69b9b262-74e3-2cc3-8a2e-5b73e95d1fd4@uos.de> <20180907055606.GA27715@burischnitzel.preining.info> <01220e60-c822-8c3a-ad1c-66f6b0236944@uos.de> Message-ID: <20180907111217.GA27488@burischnitzel.preining.info> Hi Martin, > Unfortunately I'm not very familiar with the details of TeX Live's build > system. As far as I understand the linking issue, configure doesn't set the > variables FOO_LIBS, like POTRACE_LIBS. The original dvisvgm config script > calls PGK_CHECK_MODULES to get the compiler and linker flags required for > the system libraries which in turn populates FOO_CFLAGS and FOO_LIBS. The > Makefiles generated by the TL build system don't seem to define them > anywhere, though. Hmm, AFAIR (but I am not a auto* guru, not even apprentice ;-) we reuse upstream auto* more or less as is. But I might be completely wrong and your local configure did more than we support here. Probably we need to adjust Build/source/texk/dvisvgm/configure.ac to carry over the stuff from Build/source/texk/dvisvgm/dvisvgm-source/configure.ac about the libraries. I hope Karl can comment here ... All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From luigi.scarso at gmail.com Fri Sep 7 16:57:38 2018 From: luigi.scarso at gmail.com (luigi scarso) Date: Fri, 7 Sep 2018 16:57:38 +0200 Subject: [tlbuild] [Dev-luatex] luatex 1.08 in TL cannot be built with --with-system-gmp In-Reply-To: <20180906025530.GE21614@bulldog.preining.info> References: <20180906013015.GC4225@bulldog.preining.info> <20180906025530.GE21614@bulldog.preining.info> Message-ID: On Thu, Sep 6, 2018 at 8:41 AM Norbert Preining wrote: > Reposting to dev-luatex, seems to be the appropriate place. > > On Thu, 06 Sep 2018, Norbert Preining wrote: > > Hi Luigi, hi all, > > > > configuring current TL sources with > > --with-system-gmp > > I get an error: > > gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c > -I/usr/include/libpng16 > -I/home/norbert/Development/TeX/texlive.git/Build/source/foo/texk > -I/home/norbert/Development/TeX/texlive.git/Build/source/texk > -I../../../texk/web2c/mplibdir -Wimplicit -Wreturn-type -g -O2 -MT > libmplibcore_a-mpmathbinary.o -MD -MP -MF > .deps/libmplibcore_a-mpmathbinary.Tpo -c -o libmplibcore_a-mpmathbinary.o > `test -f 'mpmathbinary.c' || echo '../../../texk/web2c/'`mpmathbinary.c > > In file included from ../../../texk/web2c/mplibdir/mpmathbinary.w:28: > > ../../../texk/web2c/mplibdir/mpmathbinary.w:44:10: fatal error: > gmp/config.h: No such file or directory > > #include > > ^~~~~~~~~~~~~~ > > compilation terminated. > > > > > > Debian's libgmp-dev does not ship > > gmp/config.h > > only > > gmp.h > > > > Is it now necessary to build with the TL shipped libgmp? > > Best > > Norbert > > > the buildfarm looks ok now : http://build.contextgarden.net/waterfall?tag=c/texlive The red ones are offline. can you check if --with-system-gmp works for your ? Here $> ./Build --debug --with-system-gmp fails with "" checking requested system `gmp' library... ok configure: error: you can not use system libraries for a native TeX Live build "" -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Fri Sep 7 22:59:19 2018 From: karl at freefriends.org (Karl Berry) Date: Fri, 7 Sep 2018 20:59:19 GMT Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <20180907111217.GA27488@burischnitzel.preining.info> Message-ID: <201809072059.w87KxJRo019687@freefriends.org> Build/source/texk/dvisvgm/configure.ac to carry over the stuff from Build/source/texk/dvisvgm/dvisvgm-source/configure.ac It's not just configure.ac, but the Makefile.am's. Dvisvgm's wide use of other libraries means a system build of dvisvgm is harder to support in TL than other programs, and I did not see a good way to support both. At least without a whole lot of work with conditionals, etc. If you want to put in the work, and you are willing to maintain them in perpetuity or Martin is willing to accept the changes, go right ahead :). I feel like I've put in my time struggling with this, and Martin has put in his time making the native TL build easier in the first place. Meanwhile, if/since you want to build dvisvgm standalone, my advice is to --disable-dvisvgm when doing the TL build and download/install the program separately from the original source in Debian. -k From preining at logic.at Sat Sep 8 02:42:34 2018 From: preining at logic.at (Norbert Preining) Date: Sat, 8 Sep 2018 09:42:34 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <201809072059.w87KxJRo019687@freefriends.org> References: <20180907111217.GA27488@burischnitzel.preining.info> <201809072059.w87KxJRo019687@freefriends.org> Message-ID: <20180908004234.GA8267@bulldog.preining.info> On Fri, 07 Sep 2018, Karl Berry wrote: > I've put in my time struggling with this, and Martin has put in his time > making the native TL build easier in the first place. Ok, all fine with me, but at least we should have --enable-bundled-libs be set automatically unless overriden on the commandline of configure, independently from --disable-texlive-native-build. All the best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From karl at freefriends.org Sat Sep 8 23:26:49 2018 From: karl at freefriends.org (Karl Berry) Date: Sat, 8 Sep 2018 21:26:49 GMT Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <20180908004234.GA8267@bulldog.preining.info> Message-ID: <201809082126.w88LQnpu012291@freefriends.org> be set automatically unless overriden on the commandline of configure, independently from --disable-texlive-native-build. I do nothing with --enable-bundled-libs. If you specify it, I thought it would get passed down everywhere. The AC_ARG_ENABLE in dvisvgm/configure.ac is still there. (Indeed, I tried to minimize the differences between tl's and upstreams configure.ac.) Meanwhile, I had another idea: what if, as a Debian patch, you reverted dvisvgm/configure.ac to dvisvgm-src/configure.ac, and dvisvgm-src/Makefile.am to the original (if desired -- just recurses into tests and doc subdirs, which we don't want for TL), and dvisvgm-src/src/Makefile.am to the original (definitely). You can see the changes I made for TL in dvisvgm/TLpatches/patch-08-makefiles, although they are not especially comprehensible in that (or any other :) form. If you aren't building with --enable-native-texlive, I'd expect the upstream versions should work better for you, modulo the xxhash stuff. (Another patch could be to treat xxhash like clipper I suppose, if you don't want to wait until your xxhash submission is approved or whatever.) I didn't try it ... just an idea ... -k From preining at logic.at Sun Sep 9 15:08:05 2018 From: preining at logic.at (Norbert Preining) Date: Sun, 9 Sep 2018 22:08:05 +0900 Subject: [tlbuild] building for distribution with shared breaks in dvisvgm In-Reply-To: <201809082126.w88LQnpu012291@freefriends.org> References: <20180908004234.GA8267@bulldog.preining.info> <201809082126.w88LQnpu012291@freefriends.org> Message-ID: <20180909130805.GA32669@bulldog.preining.info> Hi Karl, hi all, > I do nothing with --enable-bundled-libs. If you specify it, I thought it > would get passed down everywhere. The AC_ARG_ENABLE in Yes it is, that would fix it. But see below. > Meanwhile, I had another idea: what if, as a Debian patch, you > reverted dvisvgm/configure.ac to dvisvgm-src/configure.ac, No, not revert. Much better idea is to hard-code the libs, see the following patch: --- texlive-bin-2018.20180907.48586.orig/texk/dvisvgm/dvisvgm-src/src/Makefile.am +++ texlive-bin-2018.20180907.48586/texk/dvisvgm/dvisvgm-src/src/Makefile.am @@ -20,8 +20,8 @@ dvisvgm_LDADD += \ ../libs/xxHash/libxxhash.a else dvisvgm_LDADD += \ - $(POTRACE_LIBS) \ - $(XXHASH_LIBS) + -lpotrace \ + -lxxhash endif if ENABLE_WOFF @@ -33,8 +33,8 @@ dvisvgm_LDADD += \ else dvisvgm_LDADD += \ ../libs/ff-woff/libfontforge.a \ - $(WOFF2_LIBS) \ - $(BROTLI_LIBS) + -lwoff2enc -lwoff2dec -lwoff2common \ + -lbrotlienc -lbrotlidec -lbrotlicommon endif endif @@ -43,7 +43,7 @@ dvisvgm_LDADD += \ $(FREETYPE2_LIBS) \ $(FONTFORGE_LIBS) \ $(ZLIB_LIBS) \ - $(LIBGS_LIBS) + -lgs dvisvgm_DEPENDENCIES = $(noinst_LIBRARIES) dvisvgm_DEPENDENCIES += $(KPATHSEA_DEPEND) $(ZLIB_DEPEND) $(FREETYPE2_DEPEND) I added also -lgs because also GSLIB are not set when compiled without --enable-bundled-libs. I am not sure whether both the enc and dec libs are necessary, but I didn't care. With this compilation (after reautoconf) did work. Thanks Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From mojca.miklavec.lists at gmail.com Wed Sep 12 21:35:04 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Wed, 12 Sep 2018 21:35:04 +0200 Subject: [tlbuild] Core dump with image inclusion inside LuaTeX on Sparc Solaris Message-ID: Hi, On Sparc Solaris there's a problem with the luaimage.tex test. Here's the (not too helpful) output: ./luatex -fmt=luaimage luaimage || exit 1 + ./luatex -fmt=luaimage luaimage This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev) restricted system commands enabled. (../../../texk/web2c/luatexdir/tests/luaimage.tex [1<../../../texk/web2c/tests/ 1-4.jpg>]Bus Error - core dumped + exit 1 FAIL luatexdir/luaimage.test (exit status: 1) Mojca From luigi.scarso at gmail.com Wed Sep 12 21:49:52 2018 From: luigi.scarso at gmail.com (luigi scarso) Date: Wed, 12 Sep 2018 21:49:52 +0200 Subject: [tlbuild] Core dump with image inclusion inside LuaTeX on Sparc Solaris In-Reply-To: References: Message-ID: On Wed, Sep 12, 2018 at 9:35 PM Mojca Miklavec < mojca.miklavec.lists at gmail.com> wrote: > Hi, > > On Sparc Solaris there's a problem with the luaimage.tex test. Here's > the (not too helpful) output: > > ./luatex -fmt=luaimage luaimage || exit 1 > + ./luatex -fmt=luaimage luaimage > This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev) > restricted system commands enabled. > (../../../texk/web2c/luatexdir/tests/luaimage.tex > [1<../../../texk/web2c/tests/ > 1-4.jpg>]Bus Error - core dumped > + exit 1 > FAIL luatexdir/luaimage.test (exit status: 1) > > Mojca > ( we have already talked about it coming back from meeting... ) it's an alignment issue of ppheap, same as in ARM. There are some conditional sections for ARM that should solve the problem, I will extend them to solaris. It should be ok for the next 1.09.0 -- luigi -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at freefriends.org Wed Sep 12 23:35:48 2018 From: karl at freefriends.org (Karl Berry) Date: Wed, 12 Sep 2018 21:35:48 GMT Subject: [tlbuild] dvipdfm-x issue on CentOS 6 In-Reply-To: Message-ID: <201809122135.w8CLZmfQ022032@freefriends.org> Nelson - back on this mail from six months ago (ridiculous, I know), I expect you've solved it all by now, but just for the record, responding to various in your email: - exec_prefix is a standard part of the GNU build system, as you know; it's supposed to default to ${prefix}, as set in the top-level Makefile. - the problem below is the -L${exec_prefix}/lib/x86_64-pc-linux-gnu flag, which is apparently being passed as a literal string, without variable expansion. - therefore libtool tries to take the dirname of a strangely-named directory, with that literal dollar sign and braces in it: ./libtool: line 7475: cd: ${exec_prefix}/lib/x86_64-pc-linux-gnu: No such file or directory which clearly fails, regardless of the suffix or value of exec_prefix. - this is being done as part of a configure test (-o conftest), and has nothing to do with what's actually being tested (zlib in this case). libtool is aborting before it gets to the point of actually trying to link anything. - possibly if you ran make AM_MAKEFLAGS=libdir=/usr/local/lib it would propagate down. There are dozens of such variables, as you know, and it would not be feasible to manually list them all in every recursive make just in case they need to be manually overridden. - I think it would probably be more reliable to run configure --libdir=/usr/local/lib to get rid of the unwanted exec_prefix-based value in the first place. - Not that it matters for your environment, but I'll mention for the archive that I did end up building all the non-C++11-dependent programs on CentOS6 and the resulting tarball is linked from tug.org/texlive/bugs.html. (The most important missing programs are xetex, luatex, dvisvgm.) Best, Karl Date: Thu, 1 Mar 2018 19:11:46 -0700 From: "Nelson H. F. Beebe" To: "TLbuilders" Cc: beebe at math.utah.edu Subject: [tlbuild] dvipdfm-x issue on CentOS 6 My earlier CentOS 7 builds have succeeded completely. I've made considerable progress in getting my texlive-20180227 snapshot to build on GNU/Linux CentOS 6, for which several system components are too old for the demands of some TeX Live 2018 configure scripts. I'll report on CentOS 6 more fully later, but I have hit a stumbling block that perhaps others on this list can see how to solve. My builds reach the point of the dvipdfm-x directory, then die like this: configure:15964: ./libtool --mode=link --tag=CC /usr/local/bin/gcc-6 \ -o conftest -I${prefix}/include \ -I/var/tmp/build/bare/texlive-20180227/source/Work/libs/zlib/include \ -I/var/tmp/build/bare/texlive-20180227/source/Work/texk \ -I/var/tmp/build/bare/texlive-20180227/source/texk -DNO_DEBUG \ -I${prefix}/include -L${exec_prefix}/lib/x86_64-pc-linux-gnu \ -Wl,-rpath,${exec_prefix}/lib/x86_64-pc-linux-gnu conftest.c \ /var/tmp/build/bare/texlive-20180227/source/Work/libs/zlib/libz.a \ /var/tmp/build/bare/texlive-20180227/source/Work/texk/kpathsea/libkpathsea.la \ -lm >&5 \ ./libtool: line 7475: cd: ${exec_prefix}/lib/x86_64-pc-linux-gnu: No such file or directory libtool: error: cannot determine absolute directory name of '${exec_prefix}/lib/x86_64-pc-linux-gnu' configure:15964: $? = 1 configure: failed program was: ... configure:15967: error: Sorry, you need zlib with compress2 The local library /usr/local/lib6/libz.a has the symbol compress2, as does the source/Work/libs/zlib/libz.a. The symbol exec_prefix is set to /usr/local, as shown by earlier contents of the config.log file. However, neither of these /usr/lib/x86_64-pc-linux-gnu /usr/local/lib/x86_64-pc-linux-gnu exist as directories on my CentOS 6 systems. It would appear that if I create an empty directory with the second name above, that might fix the problem. It does not. Because that directory does not exist, it should not even be referenced in the Makefiles, but it is, starting at the top-level one, which has libdir = ${exec_prefix}/lib/x86_64-pc-linux-gnu I therefore restarted the make with make libdir='${prefix}/lib' world That failed in dvipdfm-x as before. I tried again without a variable expansion, like this: env libdir=/usr/local/lib make -e world and that failed the same way. I next tried one level down: cd texk env libdir=/usr/local/lib make -e world I get the same failure in dvipdfm-x. It would appear some Makefile, or libtool script, along the way is not correctly propagating the value of libdir set on the command line, or imported from the global variable environment, but instead, is overriding those settings with a wrong value for libdir. From mojca.miklavec.lists at gmail.com Thu Sep 13 07:03:28 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Thu, 13 Sep 2018 07:03:28 +0200 Subject: [tlbuild] Core dump with image inclusion inside LuaTeX on Sparc Solaris In-Reply-To: References: Message-ID: On Wed, 12 Sep 2018 at 21:50, luigi scarso wrote: > On Wed, Sep 12, 2018 at 9:35 PM Mojca Miklavec wrote: >> >> Hi, >> >> On Sparc Solaris there's a problem with the luaimage.tex test. Here's >> the (not too helpful) output: >> >> ./luatex -fmt=luaimage luaimage || exit 1 >> + ./luatex -fmt=luaimage luaimage >> This is LuaTeX, Version 1.09.0 (TeX Live 2019/dev) >> restricted system commands enabled. >> (../../../texk/web2c/luatexdir/tests/luaimage.tex [1<../../../texk/web2c/tests/ >> 1-4.jpg>]Bus Error - core dumped >> + exit 1 >> FAIL luatexdir/luaimage.test (exit status: 1) >> >> Mojca > > ( we have already talked about it coming back from meeting... ) I just didn't have the error message available at that point (the compilation takes forever). > it's an alignment issue of ppheap, same as in ARM. > There are some conditional sections for ARM that should solve the problem, I will extend them to solaris. > It should be ok for the next 1.09.0 Once you fix this, please also push the change to the TeX Live repository (and let me know, so that I can check). Thank you, Mojca From karl at freefriends.org Tue Sep 18 23:29:19 2018 From: karl at freefriends.org (Karl Berry) Date: Tue, 18 Sep 2018 21:29:19 GMT Subject: [tlbuild] tl branch rebuild again Message-ID: <201809182129.w8ILTJrU018636@freefriends.org> All TL builders - please rebuild off the branch again (r48691), and commit/send me binaries as usual. There are fixes to dvipdfmx, dvips, luatex, and pdftex. Nothing else has been changed since last time. Do not rebuild off the trunk, that has had tons of unrelated changes we don't want to inflict on the world. Thanks, Karl From karl at freefriends.org Wed Sep 19 01:03:38 2018 From: karl at freefriends.org (Karl Berry) Date: Tue, 18 Sep 2018 17:03:38 -0600 Subject: [tlbuild] tl branch rebuild again Message-ID: <86fty6v25x.fsf@frenzy.freefriends.org> Just in case you don't have an svn checkout of the branch already, you can get it with (for instance): svn co svn://tug.org/texlive/branches/branch2018/Build/source Or you can get it by rsync this way if you prefer that: mkdir tl18branch cd tl18branch rsync -a --delete --exclude=.svn tug.org::tlbranch . The only thing in that branch directory via rsync is the compilable sources. Thanks, Karl