IRC channel logs
2026-02-12.log
back to list of logs
<mwette>I'm trying to experiment w/ modifying guile C source. I added a C function in init.c but can't get it exposed in libguile.so. It's driving me nuts. Anyone have what is needed? I tried tracing scm_init_guile but don't see how that is exposed. <rlb>mwette: not sure, but wonder if it needs SCM_API (see say strings.h)? <mwette>I added SCm_API init.h (scm_init_guile() has it), but not in init.c (scm_init_guile() does not have that in threads.c). Go figure. But I'll try in .c <rlb>I'm not sure about the details, but just recalled that we might have some fancier linkage stuff now. <rlb>wrt public vs private, etc. <mwette>I guess turning every foo.c into a libguile-foo.so is a path to removing unused symbols somehow. Very mysterious to me. <mwette>Probably something trivial I'm overlooking. <rlb>I also wouldn't have been surprised to learn that init.c was "special" somehow. <mwette>I'm turning `scm_load_startup_files();' into `(*load_startup_files)();' where load_startup_files can be set via setter() prior to calling scm_boot_guile(). <mwette>But the setter() (actually `scm_load_startup_using(thunk)') is not showing up in libguile.so. <rlb>I'm pretty sure I recall civodul or something discussing some kind of symbol filtering (likely wrt INTERNAL vs API), but that's all I (might) know atm. <rlb>s/something/someone/ <gnucode>hello, I'm having trouble getting geiser to work via spacemacs and OpenBSD. <gnucode>I'm getting a "geiser-completion--symbol-begin: Symbol's function definition is void: nil <mwette>OK. Thanks. The symbol appears (i.e., nm returns `T scm_load_startup_using') in libguile_3.0_la-init.o, but not libguile-3.0.so <gnucode>the internet seems to think that I should try updating spacemacs...I'll give that a go. <mwette>I added SCM_API to the ftn definition in the .c file. It now appears. Thanks rlb. <gnucode>hmmm, now running geiser, I get this error in the *Messages buffer* "counsel-M-x-action: Wrong type argument: listp, 6" <rlb>gnucode: no idea, but if you hang around someone might show up who knows. <gnucode>I might mention something in the spacemacs channel <rlb>Without knowing anything directly relevant, I'd guess that sounds like it might be a versioning issue, i.e. differing apis somewhere. <daviid>gnucode: you could ask for help in #geiser (though I see the geiser author in not in the room at the moment ..) <rlb>(differing api expectations wrt version change) <gnucode>I suppose I could always try running geiser in a simple Emacs session. "emacs -q" <ieure>gnucode, M-x toggle-debug-on-error, reproduce your issue, you'll get a stack trace.