IRC channel logs
2025-02-16.log
back to list of logs
<apteryx>should stexi->texi always put a @menu on a newline? <apteryx>currently it appends it without prepending a \n; you can see the bug when building guile-lib, which runs stexi->texi over doc/guile-library.scm <apteryx>cbaines: was my reply w.r.t. the new log formatter procedure signature useful? <cbaines>apteryx, maybe, I think at least the #:key _ #:allow-other-keys bit addresses the problems I had trying to just add #:allow-other-keys <cbaines>I think I'd prefer if breaking changes like this aren't in patch releases though <graywolf>Interesting, there is no λ* syntax form. <old>anyway to check if a method is defined for an object in GOOPS? <rlb>civodul wingo: I'm not deeply familiar with gcc -flto yet, but lintian's claiming that libguile*.a is unusable because we're not specifying --ffat-lto-objects, i.e. related to https://bugs.debian.org/963057 and so wondered if we might want/need to adjust. <Arsen>it is generally a bad idea to package up GCC LTO bytecode into .a files <Arsen>but I'd consider this a distribution problem, not an upstream one <Arsen>fedora (and gentoo eventually if I ever have free time again) fix this by using -ffat-lto-object (which emits both bytecode and machine code) and then strip the LTO bytecode out of the installed .a files <rlb>Right, but might that mean that we should be building with --ffat-lto-object when we're using -flto? <rlb>at least for the .a file, if that's handled separately wrt the option? <Arsen>I don't see any -flto upstream <rlb>Well, whatever we use to build is adding -flto. <rlb>i.e. I'm pretty sure that's not a debian thing, but I'll double-check. <rlb>I'll have to remember how we get the options, but I thought I remembered *us* adding -flto. <rlb>Yeah, there it is (the start anyway): 6ed66f42cbd492df88ffd35a7406a9d7065b0447 <Arsen>ACTION thinks upstream shouldn't be doing this <rlb>Do you happen to know whether -ffat-lto-object would be a "global" option, or just one for the .a? <Arsen>it'd need to be in the CFLAGS for libguile-....la <rlb>So can it just be in the "global" cflags too, or does it have to be more narrowly construed? (Asking because I might fix it in debian in the short term less precisely if that'll work.) <Arsen>it can be global, yes, that won't be a problem <rlb>e.g. CFLAGS=... ./configure... <Arsen>well, that's how i'd expect -flto to be passed also, but apparently not ;P <Arsen>now I wonder whether gentoo handles --enable-lto properly.. I have LTO enabled on my system so I don't think I ever tried libguile without it <rlb>So sounds like we might also just be able to adjust the existing cases where we mention -flto to add -ffat-lto-object as a "quick fix"? <rlb>Hmm, do we support clang too -- because if so, then that won't quite work. Or rather, the clang manpage doesn't mention -ffat-lto-objects, but does mention -flto=(full|thin|...). <rlb>Ahh, so maybe just an incomplete manpage. <Arsen>yes, clang docs are pretty bad.. <Arsen>the code for LTO support seems quite ordinary, so ordinary I see no reason to put in special support <Arsen>so yeah, I'd just remove it, but adding the flag if supported would also work <rlb>Not sure I follow you -- you mean that we could just leave that in the cflags up to the builder? <rlb>"leave adding that to the cflags" <rlb>OK, so assuming we don't think we care (for now) about compilers that have -flto but not -ffat-lto-objects, one option might be to just add the latter everywhere alongside -flto. <Arsen>I mean that I'd remove --enable-lto if it were up to me, that's a builder concern <rlb>ACTION will perhaps let that be a separable question :) <Arsen>upstream takes LTO support seriously (which is better than most..), so that should be good enough <rlb>To start, perhaps I'll just fix debian. In any case, thanks again. <rlb>(then we'll see if all the buildds are still happy, etc.) <lechner>daviid / Hi, any chance I could ask you, perhaps privately, a question about the package name in Guix? Thanks!