Hi, I am trying to understand why Nim compiler thinks that my windows CPU is 32 bits.
I ran into this while trying to sue sqlite where the smallest reproducible error would be:
import db_sqlite
var db = open(connection="test.db", user="test", password="",
database="test")
and the error of the compiler is could not load: sqlite3_32.dll. I did try to understand if this was a path problem but the dll are correct so I suppose it is due to the fact that the library selected is the wrong one and it should try to load sqlite3_64.dll.
in fact if I run echo hostCPU the result is i386 and I see from source that it is due to compiler magic.
My Windiws system instead thinks that my cpu is this one: https://en.wikichip.org/wiki/intel/core_i5/i5-8350u
yes, sure.
-v
Nim Compiler Version 1.0.6 [Windows: i386]
Compiled at 2020-01-23
Copyright (c) 2006-2019 by Andreas Rumpf
git hash: 89b39ee8fe271d0e1b75c15a4c6cf82eb9c13aea
active boot switches: -d:release
-v
Using built-in specs.
COLLECT_GCC=C:\Users\ppeterlongo\.choosenim\toolchains\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/Users/ppeterlongo/.choosenim/toolchains/mingw32/bin/../libexec/gcc/i686-w64-mingw32/6.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-6.3.0/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-sjlj-exceptions --with-dwarf2 --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-pkgversion='i686-win32-dwarf-rev1, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/include -I/c/mingw630/prerequisites/i686-zlib-static/include -I/c/mingw630/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/include -I/c/mingw630/prerequisites/i686-zlib-static/include -I/c/mingw630/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/include -I/c/mingw630/prerequisites/i686-zlib-static/include -I/c/mingw630/prerequisites/i686-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/lib -L/c/mingw630/prerequisites/i686-zlib-static/lib -L/c/mingw630/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware'
Thread model: win32
gcc version 6.3.0 (i686-win32-dwarf-rev1, Built by MinGW-W64 project)
I actually did a fresh install using latest released choosenim (for windows 64 bit).
thank you, I did download mingw64 (I actually used the one which would have been downloaded from choosenim at url https://nim-lang.org/download/mingw64.7z) and now I have a different error message when compiling a simple echo "hello" program which is quite explicit (nim compiler and gcc do not agree on target architecture):
In file included from C:\Users\ppeterlongo\nimcache\hello_d\@mhello.nim.c:9:0:
C:\Users\ppeterlongo\.choosenim\toolchains\nim-1.0.6\lib/nimbase.h:457:13: error: size of array 'Nim_and_C_compiler_disagree_on_target_architecture' is negative
typedef int Nim_and_C_compiler_disagree_on_target_architecture[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8 ? 1 : -1];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So it appears I am back to square one. Even if my gcc compiler is a 64 bit one now, nim compiler still thinks I am on a 32 bit architecture (which is probably also the reason why chooesnim installed mingw32 instead of mingw64).
You need to install the 64bit version of Nim to match your new gcc. If you didn't have gcc when you started, choosenim would install 32bit by default. This was recently improved but you probably have an older choosenim.
Regardless of arch, the problem is the dll so please try copying it to the same dir as the exe and try that. You don't need to fiddle with arch unless you have a specific need that depends on arch.
today to try and solve this issue I did remove all previous nim folders and I installed it again using the most recent choosenim I could find: the release choosenim-0.5.1_windows_amd64 from github. I would assume that to install the 64bit version of Nim but maybe I am wrong (or maybe choosenim tries to infer the architecture and install the version he thinks is the correct).
Regardless of arch, even moving the dll sqlite3_32.dll in the same folder as my nim test file (and the resulting .exe) the error is still (when running the exe): could not load sqlite3_32.dll
I just tried your test on my Windows setup and it worked fine for me. Following are the md5sum of the DLLs that got installed by choosenim.
md5sum sqlite3_32.dll => 943d354608f9b87ad5e6c5c632e7272c
md5sum sqlite3_64.dll => d25af52d213f114aefa16370ec699f88
Not sure what else to tell you.
Yes, good suggestion, thank you. It worked and I was able to compile and run the test script! Also when compiling a running a simple echo hostCPU with the 64 bit compiler I do get amd64 as an answer.
After this succesful experiment my tentative answer to "How does nim infer that a cpu on windows is 64-bit" would be that it is not inferred at all, but instead it is baked in the compiler (both for nim and gcc).
A still outstanding issue is how come the choosenim released version choosenim-0.5.1_windows_amd64.zip has a i386 baked in instead of amd64. But this I guess it belongs to choosenim issue tracker. I will open an issue there.
And I think I found my answer in this closed issue in choosenim: https://github.com/dom96/choosenim/issues/128
It appears that if it finds a gcc 32 bit compiler, choosenim will download the 32 bit Nim compiler. I did have in my path only the gcc 32 bit compiler so it was expected behaviour of choosenim.
Both finish and choosenim use the same method to detect arch.
So your actual issue was that you had a corrupt sqlite dll or perhaps that 32bit sqlite is broken.