Post by Chris Iverson on Jun 7, 2020 17:14:37 GMT -5
This actually applies on all versions that I can test(Windows, Linux, etc.)
I don't know if this is something that Carl can actually affect/fix, since this may be internal to how VisualWorks works.
When trying to open the library while searching for it, it tries to open the library with the FILE open command, not the LIBRARY open command. This would be open64() on Linux, some form of CreateFile() on Windows.
This is equivalent to "open "sqlite" for input as #file", instead of "open "sqlite" for DLL as #file".
The reason this makes a difference is, when trying to load a library("for DLL", in API terms, dlopen() on Linux, and LoadLibrary() on Windows), the system automatically looks in other places for the shared library. Windows searches the PATH(various places, including system32, etc), Linux searches LD_LIBRARY_PATH(as well as configured library paths using the ldconfig command).
"for INPUT" will only search for the file at the exact location specified(or the current directory, if no direct path is specified). This means, if it's not in the lb5alpha folder, it won't find it, even if a proper load would find it.
You get this same behavior of not finding the file if you move the sqlite3.dll from the LB5alpha folder on Windows to the System32 or SysWOW64 folders.
On Linux, if you copy the library to the lb5alpha folder, it works.
Even weirder, if you make an EMPTY file with the same name as the sqlite library("libsqlite3.so.0") in the lb5alpha folder, it will work perfectly!
The open64() call will find the empty file, and continue to try to load the library using dlopen().
dlopen() doesn't search the current folder when looking for libraries, unless an explicit path is given. So it won't try to load the empty file. Instead, it will start searching the system folders first. It will find the proper sqlite library, and load it successfully!
This trick doesn't actually work on Windows, because Windows searches the application directory before any other system directories. (This is so your application can provide a custom version of a library without conflicting with the rest of the system.)
(Also, I still see the behavior of it trying and failing to load a nonexistent sqlite library between every successful call into the actual, opened sqlite library. Don't know why it does that, but it seems to ignore it, anyway.)
I don't know if this is something that Carl can actually affect/fix, since this may be internal to how VisualWorks works.
When trying to open the library while searching for it, it tries to open the library with the FILE open command, not the LIBRARY open command. This would be open64() on Linux, some form of CreateFile() on Windows.
This is equivalent to "open "sqlite" for input as #file", instead of "open "sqlite" for DLL as #file".
The reason this makes a difference is, when trying to load a library("for DLL", in API terms, dlopen() on Linux, and LoadLibrary() on Windows), the system automatically looks in other places for the shared library. Windows searches the PATH(various places, including system32, etc), Linux searches LD_LIBRARY_PATH(as well as configured library paths using the ldconfig command).
"for INPUT" will only search for the file at the exact location specified(or the current directory, if no direct path is specified). This means, if it's not in the lb5alpha folder, it won't find it, even if a proper load would find it.
You get this same behavior of not finding the file if you move the sqlite3.dll from the LB5alpha folder on Windows to the System32 or SysWOW64 folders.
On Linux, if you copy the library to the lb5alpha folder, it works.
Even weirder, if you make an EMPTY file with the same name as the sqlite library("libsqlite3.so.0") in the lb5alpha folder, it will work perfectly!
The open64() call will find the empty file, and continue to try to load the library using dlopen().
dlopen() doesn't search the current folder when looking for libraries, unless an explicit path is given. So it won't try to load the empty file. Instead, it will start searching the system folders first. It will find the proper sqlite library, and load it successfully!
This trick doesn't actually work on Windows, because Windows searches the application directory before any other system directories. (This is so your application can provide a custom version of a library without conflicting with the rest of the system.)
(Also, I still see the behavior of it trying and failing to load a nonexistent sqlite library between every successful call into the actual, opened sqlite library. Don't know why it does that, but it seems to ignore it, anyway.)
