Mirror of forum.nim-lang.org

6181 :: Creating dynamic libraries as nimble package

• cmc (orginal) [2020-04-09T10:07:29+02:00] view original

  Hello, all!

  I created a command line tool that uses dynamic libraries to do different kinds of text processing so you can create a processor in your own tree.

  Getting nimble to package it was workable but kind of nontrivial so I thought I'd share. I've got a plugin folder with .nimf files that will expose an interface, and the following .nimble

  # mytool.nimble
  version       = "0.1.0"
  author        = "Me Myself I"
  description   = "A command line tool with some build in dynamic libraries"
  license       = "MIT"
  bin           = @["mytool"]
  backend       = "c"
  installExt    = @["nim", "nimf", "nims", "so", "dylib", "dll"]
  
  requires "nim >= 1.0.0"
  
  import os, strutils
  
  before build:
    for file in listFiles( "plugins" ):
      if file[^5 .. ^1] == ".nimf":
        echo "Building " & file
        let cmd = "nim " & backend & " --app:lib" & " -o:" & (DynlibFormat % ("mytool" & lastPathPart(file)[0 .. ^6])) & " " & file
        echo cmd
        exec cmd
  Run

  So now dynamic lib is built and installed alongside the binary (but not symlinked anywhere). On Windows that's all there is to it, but linux and OSX need some linker options in the main binary so its directory is in the load path

  # mytool.nims
  when defined(macosx):
    switch("passL", "-rpath @loader_path") # researched but untested, can you confirm?
  elif defined(posix):
    switch("passL", "-Wl,-rpath,\\$ORIGIN")
  Run

  I believe the nim core developers have a very long to do list that is occasionally made even longer by interesting ideas from the commun ity. I am happy to oblige! :)

  • I would love to have a nim switch that will generate platform specific linker options to load dynlibs from binary's location, like on

  Windows. This could be considered as default behavior for nim programs.

  • I would love to have a dynlib build target, analogous to binary, that builds and copies but does not link dynlibs, and a well-known lo

  cation in the directory structure

  Thanks for reading! Carlo

---

• leorize (orginal) [2020-04-09T21:34:27+02:00] view original

  I would love to have a nim switch that will generate platform specific linker options to load dynlibs from binary's location, like on Windows. This could be considered as default behavior for nim programs.

  Depends on who you ask, using this as the default behavior have possible security implications.

---

• federico3 (orginal) [2020-04-09T21:42:10+02:00] view original

  A benefit of shared/dynamic libraries is that they can receive security updates from the OS without having to rebuild and deploy all impacted applications. It's crucial in many scenarios.

---

• rayman22201 (orginal) [2020-04-10T01:42:12+02:00] view original

  cool script. Thanks for sharing.

  I would love to have a nim switch that will generate platform specific linker options to load dynlibs from binary's location, like on Windows. This could be considered as default behavior for nim programs.

  This is a bad ida IMO. The behavior is different on the other platforms for a reason. (Security being one of them). You should try to fit in with the platform you are targeting, not make the platform do non-standard things for your program.

  I would love to have a dynlib build target, analogous to binary, that builds and copies but does not link dynlibs, and a well-known location in the directory structure

  This is a good idea. I like it :-)

---

• cmc (orginal) [2020-04-10T14:11:18+02:00] view original

  @leorize @federico3 @rayman22201 Thank you for your insightful comments!

  What you are saying about security and consistency makes sense. After having swallowed that pill it would appear the best idea would be to just place .dll files into nimbles' bin on Windows, and automatically add an rpath of "../lib" to binaries that have at least one dynamic library dependency on osx/linux/bsd. OS packagers would need to remember to disable the nimble rpath and use whatever they usually do.

  This would make sense for my plugin use case as well, because as is my hypothetical plugin authors need to manually copy their binary into pkg/mytool-0.0.1, which gets deleted when uninstalled.

---