I hate correcting myself. You do not need the --export-all-symbols Using it will cause all non-static symbols to be exported (even without a specific dllexport) just like using -shared on unices.
--- 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 Keith Medcalf >Sent: Thursday, 2 April, 2015 17:51 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >NXCheck - DBCheck > > >BTW, I have verified that these options all work as described and the >options are recognized and processed properly by Windows, and that >BinScope is happy: > >Failed checks >d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL ) > >Passed checks >d:\source\sqlite\sqlite3.dll - NXCheck ( PASS ) >d:\source\sqlite\sqlite3.dll - DBCheck ( PASS ) > >(Note, position independent code (PIC) is by definition loadable at any >base. Microsoft is just several decades behind in generating position >independent code.) > >--- >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 Keith Medcalf >>Sent: Thursday, 2 April, 2015 17:43 >>To: General Discussion of SQLite Database >>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >>NXCheck - DBCheck >> >> >>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 >> >> >> >>_______________________________________________ >>sqlite-users mailing list >>sqlite-users at mailinglists.sqlite.org >>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > >_______________________________________________ >sqlite-users mailing list >sqlite-users at mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
