Build issues with GCC and Linux

[Willena]

Hi @utelle !

I've been trying to build the project today, but it wasn't successful. I've updated the premake5.lua to support linux build, in hope that it will work like before.

The premake5.lua file I used is accessible here: https://gist.github.com/Willena/c970c5575dab9b83689ef93a69b09f9a

I have also ran the patchsqlite3.sh script and the rekeyvacum.sh script before building.

Bellow the GCC log if it can help. At the end you have my GCC version.

Thanks

guillaume@master:~/SQLite3MultipleCiphers$ ../premake5 gmake
Building configurations...
Running action 'gmake'...
Generated build/Makefile...
Generated build/sqlite3lib.make...
Generated build/sqlite3so.make...
Generated build/sqlite3shell.make...
Done (103ms).
guillaume@master:~/SQLite3MultipleCiphers$ cd build/
guillaume@master:~/SQLite3MultipleCiphers/build$ make
==== Building sqlite3lib (debug_linux32) ====
Creating obj-gcc/Linux32/Debug/sqlite3lib
sqlite3mc.c
In file included from ../src/sqlite3mc.c:113:0:
../src/cipher_common.c:32:1: error: static declaration of ‘sqlite3mcGetCipherParameter’ follows non-static declaration
 sqlite3mcGetCipherParameter(CipherParams* cipherParams, const char* paramName)
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/codec_algos.c:10:0,
                 from ../src/sqlite3mc.c:106:
../src/cipher_common.h:75:12: note: previous declaration of ‘sqlite3mcGetCipherParameter’ was here
 extern int sqlite3mcGetCipherParameter(CipherParams* cipherParams, const char* paramName);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/cipher_config.c:11:0,
                 from ../src/sqlite3mc.c:114:
../src/cipher_config.h:25:20: error: static declaration of ‘sqlite3mcFileControlPragma’ follows non-static declaration
 SQLITE_PRIVATE int sqlite3mcFileControlPragma(sqlite3* db, const char* zDbName, int op, void* pArg);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/sqlite3mc.c:65:0:
../src/sqlite3patched.c:124791:14: note: previous declaration of ‘sqlite3mcFileControlPragma’ was here
   extern int sqlite3mcFileControlPragma(sqlite3*, const char*, int, void*);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/cipher_config.c:11:0,
                 from ../src/sqlite3mc.c:114:
../src/cipher_config.h:26:20: error: static declaration of ‘sqlite3mcHandleAttachKey’ follows non-static declaration
 SQLITE_PRIVATE int sqlite3mcHandleAttachKey(sqlite3* db, const char* zName, const char* zPath, sqlite3_value* pKey, char** zErrDyn);
                    ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/sqlite3mc.c:65:0:
../src/sqlite3patched.c:108405:16: note: previous declaration of ‘sqlite3mcHandleAttachKey’ was here
     extern int sqlite3mcHandleAttachKey(sqlite3*, const char*, const char*, sqlite3_value*, char**);
                ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/sqlite3mc.c:116:0:
../src/codecext.c:13:20: error: static declaration of ‘sqlite3mcCodecAttach’ follows non-static declaration
 SQLITE_PRIVATE int sqlite3mcCodecAttach(sqlite3* db, int nDb, const void* zKey, int nKey);
                    ^~~~~~~~~~~~~~~~~~~~
In file included from ../src/sqlite3mc.c:114:0:
../src/cipher_config.c:900:14: note: previous declaration of ‘sqlite3mcCodecAttach’ was here
   extern int sqlite3mcCodecAttach(sqlite3*, int, const void*, int);
              ^~~~~~~~~~~~~~~~~~~~
In file included from ../src/sqlite3mc.c:116:0:
../src/codecext.c:14:21: error: static declaration of ‘sqlite3mcCodecGetKey’ follows non-static declaration
 SQLITE_PRIVATE void sqlite3mcCodecGetKey(sqlite3* db, int nDb, void** zKey, int* nKey);
                     ^~~~~~~~~~~~~~~~~~~~
In file included from ../src/sqlite3mc.c:114:0:
../src/cipher_config.c:901:15: note: previous declaration of ‘sqlite3mcCodecGetKey’ was here
   extern void sqlite3mcCodecGetKey(sqlite3*, int, void**, int*);
               ^~~~~~~~~~~~~~~~~~~~
sqlite3lib.make:186 : la recette pour la cible « obj-gcc/Linux32/Debug/sqlite3lib/sqlite3mc.o » a échouée
make[1]: *** [obj-gcc/Linux32/Debug/sqlite3lib/sqlite3mc.o] Erreur 1
Makefile:40 : la recette pour la cible « sqlite3lib » a échouée
make: *** [sqlite3lib] Erreur 2
guillaume@master:~/SQLite3MultipleCiphers/build$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

[utelle]

I've been trying to build the project today, but it wasn't successful. I've updated the premake5.lua to support linux build, in hope that it will work like before.

I will take a look at your modified premake5 script later on. For now, just a quick comment:

The build files produced by the current premake5 script are meant for Windows platforms in the first place. For example, the GNU Make script should work for the MinGW64 toolchain without major platforms (although I haven't tested that yet).

For Linux and MacOS platforms I provide handcrafted files for the autoconf/automake toolchain. Again, I haven't tested them yet, but the goal is that they function properly.

As mentioned in the readme file I developed the new version under Windows up to now, but I will start testing under Linux, too, in the near future.

I have also ran the patchsqlite3.sh script and the rekeyvacum.sh script before building.

I intend to provide the files resulting from the scripts in the repository - as is already the case now. So, running those scripts will only be necessary, if a new version of SQLite is released.

Bellow the GCC log if it can help. At the end you have my GCC version.

I will inspect the log. GCC is usually a bit more picky than Visual C++. I will do my best to address the issues when compiling with GCC.

[Willena]

One more thing, before having a standalone repository for SQLite I used this (https://github.com/Willena/libsqlite3-wx-see/blob/master/premake5-linux.lua) premake5 script and it worked very well.

I intend to provide the files resulting from the scripts in the repository - as is already the case now. So, running those scripts will only be necessary, if a new version of SQLite is released.

I'll try automake and autoconf scripts tonight. Anything special that I need to known to use them ?

I intend to provide the files resulting from the scripts in the repository - as is already the case now. So, running those scripts will only be necessary, if a new version of SQLite is released.

This is good to know.

[utelle]

One more thing, before having a standalone repository for SQLite I used this premake5 script and it worked very well.

If I can adjust the premake5 script, so that the resulting GNU Makefile works for both MinGW64 under Windows and GCC under Linux, I will do so.

I'll try automake and autoconf scripts tonight. Anything special that I need to known to use them ?

You may use the steps as described here. However, ignore the comment about wxWidgets - it doesn't apply here. Simply invoking configure without any options should work.

[utelle]

I've been trying to build the project today, but it wasn't successful. ...

The compile problem arises from the fact that the SQLite amalgamation adds the static attribute to almost all functions through the symbol SQLITE_PRIVATE, so that only API functions are externally visible.

I used the symbol SQLITE_PRIVATE, too, for internal functions that shouldn't be called by applications. However, the symbol is defined at the beginning of the SQLite amalgamation source code.

For my SQLite patches I used the keyword extern for the prototypes of my functions. While Visual C++ is happy with this approach, GCC is not.

I probably have to define the symbol SQLITE_PRIVATE myself, first, so that function prototypes can be defined before including the SQLite amalgamation, so that they are known in the SQLite amalgamation. However, it could be that that doesn't work, because certain types are not defined, before the amalgamation source code was included.

At first I intended to make it possible to compile the code from individual source files. However, in combination with the SQLite amalgamation this doesn't work anyway, because my implementation needs to use several internal SQLite functions, which are invisible to the outside.

I will adjust my code within the next couple of days, so that GCC can compile it without problems, too.

[utelle]

Commit 9e46f07d436219b30d149298b690034df2c1033a should fix the compile issue. At least it works for GCC version gcc (i686-posix-sjlj-rev0, Built by MinGW-W64 project) 8.1.0.

A test with the minimal sample coming with wxSQLite3 was also successful.

[utelle]

Commit 41a9ace96cec07ed03eaf1ff4bbea117351e00f6 eliminates some compile time warnings under Linux. With those changes I could use successfully the autoconf toolchain:

autoreconf
mkdir build-test
cd build-test
../configure
make

In the meantime, I tested also under macOS Catalina 10.15.4. Same procedure as shown above worked flawlessly (except for 3 compile time warnings - 2 regarding signed/unsigned mismatch, 1 regarding deprecated system call).

[Willena]

Tested today and approved. Works now with my gcc too. Thank you !