Hello,

I think the issue is that the libguile.h file does not help downstream packages isolate themselves from libgc completely. There are many static functions related to bdwgc in gc-inline.h, which will be combined with downstream code as a whole to compile, similar to using gc directly in your code.

Best regards


On Sat, Oct 5, 2024, 21:08 Tomas Volf <~@wolfsden.cz> wrote:

Hello,

this might be obvious to some, but I am curious why guile puts -lgc to
the linker flags:

--8<---------------cut here---------------start------------->8---
$ guile-config link
-L/gnu/store/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9/lib -L/gnu/store/pr73chdirm3jc2j7npc6hqzmcwjs7l8m-libgc-8.2.4/lib -lguile-3.0 -lgc -lpthread -ldl
--8<---------------cut here---------------end--------------->8---

Why is it necessary?  My guile extension interacts only with the
libguile, no?  Even the GC-related functions are called via their scm_
interface, I am never directly interacting with the Boehm GC.  I even
thought that the fact that Boehm GC is used is an implementation detail,
not an ABI thing.

I would have thought that just libguile linking with the libgc is
enough, but I am far from expert in this area.  So I would appreciate if
someone could enlighten me.

(I am not sure about the -lpthread and -ldl neither, but the -lgc is the
one that caused me some problems, so I am asking about that one.)

Thanks and have a nice day,
Tomas

PS: So once we switch to whippet, all extensions will need to be rebuilt
due to linking against -lgc, which will no longer be Guile's dependency?
So I guess .so version bump will be used for that?

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.