Mirror of forum.nim-lang.org

9928 :: Garbage Collectors and Shared Libraries

• sls1005 (orginal) [2023-02-22T12:04:48+01:00] view original

  Rececently I saw some posts related with this topic, and then I viewed https://peterme.net/dynamic-libraries-in-nim.html, but there're still something not very clear.

  So I started a test.

  First, I went to lib/nim, using the command nim c -d:release lib/nimrtl.nim to generate libnimrtl.so, then moved it to the lib path of the system.

  Also I wrote two files:

  #test1.nim
  proc f(x: int64) {.nimcall, exportc, dynlib.} =
    echo "x = " & $x
  Run

  cmopiled with nim c --mm:refc --app:lib --noMain -d:useNimRtl test1.nim, and

  #test0.nim
  proc f(x: int64) {.importc, nimcall, dynlib: "./libtest1.so".}
  proc initModuleTest1() {.importc: "NimMain", dynlib: "./libtest1.so".}
  
  initModuleTest1()
  f(1)
  Run

  compiled with nim c --mm:refc -d:useNimRtl test0.nim.

  Output:

  
  x = 1
  Run

  I guess if I don't use -d:useNimRtl on both modules, there'll be two instances of GC, because the main module has one, and nimrtl creates another one.

  Also I found that a segmentation fault can happen if all of the followings are true:

  • initModuleTest1 is not called.
  • The memory strategy is refc.
  • When compiling the library, --noMain is passed. (If it isn't passed, the so's NimMain will be called automatically. This might be Linux-only.)

  That's all.

---

• PMunch (orginal) [2023-02-22T12:19:31+01:00] view original

  It should be mentioned as well though that if you compile with ARC/ORC you don't need nimRtl. I would highly recommend this approach if you're writing dynamic libraries. Although there is a small gotcha which will hopefully be fixed: https://github.com/nim-lang/Nim/issues/21403

---