Feature request: check for 'lib' prefix for load_extension()
This post has NOT been accepted by the mailing list yet.
load_extension() has the very sensible behavior of:
> So for example, if "samplelib" cannot be loaded, then names like "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might be tried also.
I would like to see that extended to include "libsamplelib.so" since that is the default naming scheme on many *nix platforms. This simple change would allow me to use the same base library name for my extension on both Windows and Linux. Otherwise I have to modify my build system to override its default behavior of adding the lib prefix on Linux.
Re: Feature request: check for 'lib' prefix for load_extension()
On Fri, Aug 04, 2017 at 10:17:33AM +0200, Dominique Devienne wrote:
> On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams <[hidden email]> wrote:
> > You're mistaken.
> > lib<name>.so is NOT "the default naming scheme on many *nix platforms".
> > lib<name>.so is the naming scheme when you want the link-editor (e.g.,
> > ld(1)) to find a library using -l<name>.
> > But loadable modules are almost never meant to be used that way.
> > They're usually meant to be used only through dlopen() and friends.
> While you're technically correct, Matt's request seems completely
> reasonable to me.
Not if it's a result of being mistaken. Now that OP knows about object
naming, he can reconsider and restate his request.
> If SQLite wasn't doing *any* changes to the filename, not adding the
> extension for example, you may have had a point, but since it does,
> trying with the lib prefix on Linux, which is undeniably a common
No, see, the ".so"/".dll" suffix is used in all cases, and it varies by
platform, so it's best if SQLite3 adds it so you can keep your code more
portable. While the "lib" prefix is only ever needed if you want a
link-edit to find the thing as -l<name> -- which you almost never ever
want when <name> is a loadable module.
> naming convention on Linux, seems like a worthwhile addition. [...]
You didn't understand.
> I really don't see what's controversial with Matt's request :)
a) it's borne of a mistake
b) it's not necessary
c) it's more code and more docs
d) it's more likely to lead to accidents
> It's not like load-extension is a performance-critical operation, that
> trying an extra load is that expensive.
This is true, but also irrelevant :)
> And the security consideration that an "attacker" could make it load
> his own library instead, but using a different name tried before the
> actual one is moot IMHO, since extension loading is by nature unsafe.
> In short, I support Matt's request and I hope DRH considers it seriously.
> FWIW :). --DD