4 ms·
I see an API fail coming. It seems plugin.Load takes the filename WITH extension where it shouldn't. Okay, right now it seems it's only supported on Linux but i
by speps 10y ago
I see an API fail coming. It seems plugin.Load takes the filename WITH extension where it shouldn't. Okay, right now it seems it's only supported on Linux but it ends up in Windows, you'd have to patch code to remove the .so. Mono handles it pretty well, the extension is optional.
- regecks 10y agoNot necessarily. https://tip.golang.org/src/plugin/plugin_dlopen.go https://tip.golang.org/src/plugin/plugin_dlopen.go " 5 // +build linux,cgo" The Windows version isn't there yet - it could encapsulate that logic.
- IshKebab 10y agoI don't think so. I think it is better that the file naming is handled in the application. It is less restrictive, e.g. you can use custom extensions this way. Consider another instance where file names are automatically mangled: GCC linking with libraries with the switch -lfoo. That has honestly caused me no end of problems. It would have been better if they required an explicit -llibfoo.so from the start. Go already has several easy methods for OS-specific code if you want.
- dvirsky 10y agoNot sure it should be be part of this package, but it's trivial to write a function that exposes something like "SharedLibraryFile(libname string) string". Depending on the OS it just formats the default shared object name. For extra runtime speed you could build OS specific versions of that function using build flags, so for each target OS it has one implementation and you have no switch/case or anything in runtime.
- dsl 10y agoAssuming or magically guessing file extensions leads to all sorts of confusion attacks that could result in arbitrary code execution. I would go so far as to say an absolute path should be required.