Created attachment 511916 [details] emerge --info During a world re-emerge as part of the 17.0 profile migration, lilypond failed to emerge for me, stating “mf2pt1: You'll need either to install t1utils and rerun mf2pt1 or find another way to convert feta11.pt1 to feta11.pfb”. Removing the auto-deletion of the temporary directory, I could reproduce the mf2pt1 invocation and found it to segfault. Still more time spent debugging essentially sane source code until I found this in the compile output of t1utils: t1asmhelp.h: In function ‘set_lenIV’: t1asmhelp.h:13:13: warning: implicit declaration of function ‘memmem’; did you mean ‘memset’? -Wimplicit-function-declaration] char* p = memmem(line, line_len, "/lenIV ", 7); ^~~~~~ memset t1asmhelp.h:13:13: warning: initialization makes pointer from integer without a cast [-Wint-conversion] t1asmhelp.h: In function ‘set_cs_start’: t1asmhelp.h:37:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion] if ((p = memmem(line, line_len, "string currentfile", 18)) ^ The latter is essentially the cause of my problems, as the value p returned there is not a valid pointer. Probably assumed to return a 32bit int instead of a 64bit void*. This is using gcc-7.2.0 and glibc-2.26-r3. I would assume a glibc incompatibility issue which should be blocking bug 628768 for tracking. See https://github.com/kohler/t1utils/commit/3f1ddda424353f0f926dd28efa47b0ac for something that looks like an upstream fix to this, albeit a somewhat ugly one in my opinion as it provides its own declaration instead of enabling the official declaration of memmem. Nevertheless, workaround should be # mkdir -p /etc/portage/patches/app-text/t1utils # cd /etc/portage/patches/app-text/t1utils # wget https://github.com/kohler/t1utils/commit/3f1ddda424353f0f926dd28e.patch # emerge -1 app-text/t1utils
Next time, please remember to attach the full build.log.
Created attachment 513134 [details] t1utils build log Build log without the mentioned patch, showing the undefined symbol. And I'm curious to learn how browsers will render the color-changing escape sequences in this log. Sorry if that makes for hard reading; if so I'll consider applying https://unix.stackexchange.com/q/4527/20807 in the future.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd4f80ff24cc83d1aeabb699c973bf1879d29b81 commit dd4f80ff24cc83d1aeabb699c973bf1879d29b81 Author: Karl Linden <karl.j.linden@gmail.com> AuthorDate: 2017-12-31 15:30:18 +0000 Commit: Alexis Ballier <aballier@gentoo.org> CommitDate: 2018-01-07 05:40:19 +0000 app-text/t1utils: apply memmem patch from upstream Closes: https://bugs.gentoo.org/630710 Closes: https://bugs.gentoo.org/642586 Package-Manager: Portage-2.3.19, Repoman-2.3.6 app-text/t1utils/files/t1utils-1.41-memmem.patch | 27 +++++++++++++++++++++++ app-text/t1utils/t1utils-1.41-r2.ebuild | 28 ++++++++++++++++++++++++ 2 files changed, 55 insertions(+)
