IRC channel logs

2025-02-21.log

back to list of logs

<rlb>gss
<rlb>oops :)
<rlb>Do we have release (archive/tag) signature verification instructions posted anywhere?
<humm>I’m wondering how to properly package C extensions. The packages are using autotools with libtool; make install puts .a, .la, and .so.0.0 in the extension dir. On Linux even a .so symlink; on this non-Linux, I can do that manually. There isn’t any reason to keep anything beside the shared object, is there? And there isn’t any reason to let it have an soname, is there?
<humm>s,C extensions,libraries using their own &,
<wingo>good morning
<rlb>morning
<wingo>humm: generally speaking you declare the extensions as _LTLIBRARIES in the makefile.am and pass -module as _LDFLAGS
<wingo>and just rely on libtool's make install. usually you put them in a directory that's not in the library search path and you don't allow people to link against them, so no need for soname
<wingo>i miss some sort of group-by operator in the stdlib
<humm>wingo: I’m not writing a library, but trying to package fibers (for OpenBSD). I’m wondering what should go in the package.
<humm>(_LTLIBRARIES, btw, doesn’t, by default, install a shared object without version suffix on all platforms.)
<humm>I think I’ll just install the *.so files in extensions/.
<wingo>humm: with -module it should install a shared object without a version suffix, right?
<wingo>one day we will be free from autotools :P
<humm>wingo: No, -module doesn’t change the file name suffix.
<humm>wingo: Hah! libtool --mode=link cc -module -avoid-version!
<wingo>ah :)
<humm>I guess I suggest you add -avoid-version to upstream fibers. Idk if you should take care not to install .la and .a, but I won’t put them in my OpenBSD package.
<humm>(I’m not quite sold on using libtool at all: Abstracting how libraries works doesn’t seem very useful when the use of the libraries is as concrete as “dlopen the file asdf.so”.)
<wingo>yes. we don't use libtool to dlopen. but we do use it to build libraries. changing to not do that is possible eventually but gnarly
<wingo>i will see about adding -avoid-version
<lloda>doc doesn't say what type seed->random-state takes. Apparently it takes strings, but if you pass a number (of any kind) it'll convert it to a string internally
<lloda>maybe that's too ugly to document
<cow_2001>BEHOLD! D:< https://codeberg.org/kakafarm/guile-bytevector-peg/commit/6fe76e66d40757608cc731f227e09f4109f0bf5b9b1390eb581d1cb05db1c687
<cow_2001>added (utf8 "moo"), (utf16 "boo"), and (utf32 "goo") kind of rules
<cow_2001>also just a literal string is interpreted as utf8
<civodul>bytevector-peg, woow!
<rlb>wingo: did you see the -ffat-lto-objects discussion? It sounds like we might want to be adding that alongside -flto if we're going to be handling -flto. Unless there are concerns, I'll probably investigate a bit more and then try it (add that to main).