Creating the sqlite3.exe stand-alone w/o cygwin dependency

[Michael Soegtrop]

Hi José,

Yes, I did. I think you missed one of my emails. But, here is what I did:
> $ ldd sqlite3.exe
>          ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffc1d6f0000)
>          ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x778c0000)
>          wow64.dll => /cygdrive/c/Windows/System32/wow64.dll (0x7ffc1c830000)
>          wow64win.dll => /cygdrive/c/Windows/System32/wow64win.dll (0x7ffc1d540000)

Ah, you compiled a 32 bit executable - I guess on a 64 bit install of 
cygwin.

Try

./configure --host=x86_64-w64-mingw32 CFLAGS=-shared CFLAGS=-static-libgcc

instead of

./configure --host=i686-w64-mingw32 CFLAGS=-shared CFLAGS=-static-libgcc

Of course you need to install the corresponding tool chain in cygwin.

As far as I can tell compiling 32 bit apps on 64 bit cygwin did never 
work (easily). Afair the reason is that certain DLLs like 
SYSTEM32/ntdll.dll have 2 copies under the same file name, a 32 bit and 
a 64 bit variant (a Windows file system hack). Which one you get depends 
on if the calling process is 32 bit or 64 bit. Now if you try to link a 
32 bit executable with a 64 bit linker, it gets the wrong DLL, so your 
32 bit app ends up being linked to a 64 bit DLL.

One could only compile 32 bit Windows apps with 32 bit cygwin - since 
this is no longer supported, I would say 32 bit MinGW is neither. There 
are hacks around this (use a 32 bit executable to copy the DLLs from 
System32 somewhere else and redirect the linker to these files). But the 
better choice is to stop compiling for 32 bit.

Best regards,

Michael