Hi,
here is some minor issue on MS Windows, did somebody experienced something like the following?
GRASS was not starting for one student on MS Windows. The reported error was that it cannot find some symbol/procedure in sqlite3.dll. The problem was possible to workaround by finding another sqlite3.dll on disk and renaming it to something arbitrary.
The strange think is that GRASS directory extrabin should be, and indeed is, at the beginning of PATH variable, so it should look first there. However, because of the error and fix it seems that it is looking elsewhere first.
What was also strange is that the other DLL was in SysWoW64 directory and I don’t see this directory on PATH (in or outside GRASS session) but if I understand correctly, there is some magic which makes system32 directory (which contains 64bit libs on 64bit system) to link to SysWoW64 (where are 32bit DLLs) for 32bit applications. Wow!
Still, there is no reason why it should pick the system directory, unless it is using some other magic.
Any ideas?
Vaclav
Related:
The procedure entry point sqlite3_rtree_geometry_callback couldn’t be located
http://trac.osgeo.org/grass/ticket/2197#comment:1
WoW64
http://en.wikipedia.org/wiki/WoW64
How to fix “The entry point for the procedure sqlite3_open_v2 cannot be found in the dynamic link library sqlite3.dll”
http://gis.stackexchange.com/questions/30432/how-to-fix-the-entry-point-for-the-procedure-sqlite3-open-v2-cannot-be-found-in
All I know is that "system32" is the default
"go-to" path for many 32-bit programs. It seems to
me that many applications are hard-linked to that
directory. If you have any such candidate in your
toolchain, then "system32", and thus "SysWoW64",
are "sucked" into your PATH, whether you like it
or not. Welcome to DLL hell.
Best,
Ben
On 06/10/14 21:16, Vaclav Petras wrote:
Hi,
here is some minor issue on MS Windows, did somebody experienced
something like the following?
GRASS was not starting for one student on MS Windows. The reported error
was that it cannot find some symbol/procedure in sqlite3.dll. The
problem was possible to workaround by finding another sqlite3.dll on
disk and renaming it to something arbitrary.
The strange think is that GRASS directory extrabin should be, and indeed
is, at the beginning of PATH variable, so it should look first there.
However, because of the error and fix it seems that it is looking
elsewhere first.
What was also strange is that the other DLL was in SysWoW64 directory
and I don't see this directory on PATH (in or outside GRASS session) but
if I understand correctly, there is some magic which makes system32
directory (which contains 64bit libs on 64bit system) to link to
SysWoW64 (where are 32bit DLLs) for 32bit applications. Wow!
Still, there is no reason why it should pick the system directory,
unless it is using some other magic.
Any ideas?
Vaclav
Related:
The procedure entry point sqlite3_rtree_geometry_callback couldn't be
located
http://trac.osgeo.org/grass/ticket/2197#comment:1
WoW64
http://en.wikipedia.org/wiki/WoW64
How to fix "The entry point for the procedure sqlite3_open_v2 cannot be
found in the dynamic link library sqlite3.dll"
http://gis.stackexchange.com/questions/30432/how-to-fix-the-entry-point-for-the-procedure-sqlite3-open-v2-cannot-be-found-in
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org