add the following linker options with MinGW: -static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-symbols
You may or may not need -static-libgcc or the linker -Bstatic options unless you are also enabling things that require MingW DLL runtime support (such as using the -mthreads option to make the DLL thread exception safe). -Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the linker (so you can add them to the shell tool and other pre-built executables as well). Files also need to export the symbol table (hence the --export-all-symbols). --large-address-aware sets the (you guessed it) large address aware flag which basically means that you are using unsigned pointers and not signed pointers (that is, you understand that neither disk space nor memory comes in negative sizes) and don't diddle with your pointers (eg, assigning magical meaning to bits in the pointer). This allows use of more than 2GB of virtual address space per process on systems that support it (ie, 32-bit userland on a 64-bit Windows -- on 64-bit Windows windows does not co-habitate with 32-bit processes, instead a wee trampoline is installed in the top 100MB or so of the virtual space to thunk back and forth to the OS -- making it impossible to insert code into the OS from a 32-bit process, while 64-bit processes on 64-bit windows have full and complete access to the OS as it resides in each processes address space) or if the /3GB boot option is set on 32-bit OSes (so the OS is forced to shoehorn into the top 1GB of each process). The only thing this does not fix is the Exception Handlers. But that particular protection is not implemented by gcc (not needed because of non-ill-conceived design?). However, you might still want to add -mthreads and the static linking options to the build so that the GCC threadsafe exception handlers are used. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >bounces at mailinglists.sqlite.org] On Behalf Of Richard Hipp >Sent: Thursday, 2 April, 2015 14:25 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >NXCheck - DBCheck > >On 4/2/15, Random Coder <random.coder at gmail.com> wrote: >> >> I'd recommend the SQLite team turn them on for the version of the DLL >> they distribute, but I'm honestly not sure if there are negative side >> effects to doing so. > >That's not possible, unfortunately, We compile the published DLL >(the 32-bit DLL at least) with MinGW so that they will work on older >versions of Windows. If we used a recent MSVC then the resulting DLL >will not work on WinXP, I am told. > >If the published DLL is not to your liking, it is simple to make your >own. I suggest you do so. You can start with the amalgamated source >code file "sqlite3.c". All you need is to compile that one file into >a DLL that the security checker approves of. How hard can that be? > >-- >D. Richard Hipp >drh at sqlite.org >_______________________________________________ >sqlite-users mailing list >sqlite-users at mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
