0

I want to use the Go plugin facility, and if I call plugin.Open("…") with an absolute path, this works fine. Still, the original docs give the example plugin.Open("plugin_name.so"), thus, it should also work with the simple filename.

However, the docs fail to say what is the search path for these plugins. Do the same rules apply as for any shared library? FWIW, copying my plugin to /usr/lib and calling ldconfig was not sufficient.

Torsten Bronger
  • 9,899
  • 7
  • 34
  • 41
  • The same as every relative path: in CWD. – Adrian Mar 01 '21 at 14:29
  • Erm … there are so many exceptions from this rule – I don’t even know where to start. – Torsten Bronger Mar 01 '21 at 18:47
  • Any examples? I can't think of anything in the standard library that accepts a file path which does not root relative paths in CWD. – Adrian Mar 01 '21 at 20:38
  • Besides the fact that you did not mention the standard library in your initial statement, the standard lib does not have a global policy about search paths. — Counter-example in the Go ecosystem: I develop this plugin for a Beego web service, and Beego templates are looked for in `./views`. – Torsten Bronger Mar 01 '21 at 21:17
  • The third-party ecosystem is effectively infinite; any library could appear at any time and do anything, and isn't representative of Go, it's representative of that library; so it doesn't make sense to include that. The Go plugin system is part of Go itself. You didn't say anything about a "global policy", only that "there are so many exceptions", none of which I've seen. Having a global policy seems unnecessary, as broadly in all of computing, relative paths are rooted in CWD by default; any other behavior is an exception. – Adrian Mar 01 '21 at 22:28
  • Your limitation to the standard lib is arbitrary. Go’s “plugin” is part of Go’s stdlib, part of Go’s ecosystem, and part of POSIX (where it runs on only). The only written convention amongst those has FHS with .so’s looked for in /usr/lib. Therefore we have SO to ask, I did so, now it is at least here documented. – Torsten Bronger Mar 02 '21 at 06:48

1 Answers1

2

If an absolute path is not provided in the plugin path, it is treated as a relative path and as such is always resolved against the current, working directory. So if you pass "plugin_name.so", it must be in the working directory. Normally it is the same folder where the executable binary is, unless the binary was launched from another folder, or the working directory was changed after that.

icza
  • 389,944
  • 63
  • 907
  • 827