Problems to create 3.5.1 with TDM-GCC MinGW about wxsqlite3 HOT 12 CLOSED

Hi Boris,

thanks for reporting the problems you have with the modified build system of wxSQLite3.

I have some problems with the Makefile for your very nice library.
There are some changes since 3-3.3.1, the last version what I used.

Yes, I overhauled the complete build system. Since the bakefile tool, on which the previous build system was based, is heavily outdated and doesn't support newer compilers like MSVC 2010 and higher, this step was unavoidable, unfortunately.

1. Missing compiler in config.gcc
   Compiler is not defined inside config.gcc, the variables are empty.
   #Add to config.gcc
   CC = gcc
   CXX = g++

Usually the make tool should implicitly define CC and CXX. However, it seems that at least CC is not defined correctly for mingw-make. Adding those defines in config.gcc is not a problem, of course. And I will do it.

2. Include folder
   wxsqlite3.make expects include folder under wqlite3 ("-I../sqlite3/include") but folder is not exist.
   Additionally two files must be in the folder
   sqlite3.h
   sqlite3userauth.h

Oops, my fault. The specification of the include path is no longer sqlite3/include - it should now be sqlite3/secure/src. I'll have to adjust the premake5 script accordingly. Interestingly, I could nevertheless build wxSQLite3 with the wrong include path without problems. Otherwise, I certainly would have detected this flaw myself.

But the story is go on.

3. MONOLITHIC build is gone
   With current Makefile it is not possible to use wxWidgets build as MONOLITHIC library.

I have to admit that I never used the monolithic wxWidgets library myself, since I started to work with wxWidgets about 12 years ago - I always preferred the multilib variant. Obviously bakefile generated support for monolithic, but I never tested it.

Not sure, how to overcome this.

4. Library name end extension is changes
   The versions up to 3-3.3.1 used
   libwxcode_msw31u_wxsqlite3.a for Release
   libwxcode_msw31ud_wxsqlite3.a for Debug

Now I will get wxsqlite3d.lib or wxsqlite3.lib

The name change was on purpose. I was aware of that this will not make everybody happy. I moved away from wxCode over a year ago. Although the idea behind wxCode was certainly good, IMHO the project is almost dead. Therefore dropping the wxcode prefix seemed to be a logical step. Carrying the wxWidgets platform and version (msw31) in the library name was never extremely useful either. And several Linux distributions, that offer wxSQLite3 packages, drop those name components, too. Therefore I intend to change the library name for Linux platforms, too.

First the expected extension for GCC is .a not .lib and the second the name is changed what is not acceptable.

This didn't catch my attention, I have to admit. I really thought, premake5 would handle this automatically correctly. However, inspecting the premake5 code I see that it uses .lib on Windows regardless of the compiler.

This could be overwritten by explicitly setting the library prefix and extension.

In reality, I cannot change every project to use new name.

Come on, how many projects do you have, that changing the library name is out of the question? In the past, you also had to change the name when moving to another wxWidgets version.

However, I could try to add options to tweak the library name through the config.gcc file. Would that help?

from wxsqlite3.

Hi Ulrich,

Thanks for fast response.
Super, first two remarks are solved.

I follow the logic as is used in CodeLite and CodeBlock. Monolithic wxWidgets on Windows, multilib on Linux. Simply to avoid double version.

Adding monolithic wxWidgets to your library, is not hard to solve. Add the same logic as is done for "config".
Put into config.gcc
MONOLITHIC ?= 0

In the *.make files, this will be one if/else statement around LIBS +=

Regardless to my wish, to have back compatibility with the name convention, I can agree, the "wxcode" is not needed in the library name.
But, if you build your library as .dll or .so, you will need msw31ud or msw31u (or gtk2u-2.8 or gtk3u-3.1) to distinguish libraries build with wxWidgets 2.8, or 3.0 or 3.1.
All of them could be located in the same folder (system32 or /usr/local/lib)
Normally you will make lib (.a) with the same name as dll.

Regards,
Boris

from wxsqlite3.

Hi Boris,

I follow the logic as is used in CodeLite and CodeBlock. Monolithic wxWidgets on Windows, multilib on Linux. Simply to avoid double version.

As said I don't use monolithic wxWidgets myself. Of course, I'm not against supporting it for wxSQLite3. However, I probably won't set up an additional environment for testing it.

Adding monolithic wxWidgets to your library, is not hard to solve. Add the same logic as is done for "config".
Put into config.gcc
MONOLITHIC ?= 0

In the *.make files, this will be one if/else statement around LIBS +=

That would be indeed simple, if the make files would be hand-crafted. The question is whether premake5 can be convinced somehow to emit make files matching this requirement. At the moment I doubt it. And it would be a bit cumbersome to adjust the make files manually, each time they are regenerated.

Additionally, I have to find out the wxWidgets library name(s) in case of monolithic build.

Regardless to my wish, to have back compatibility with the name convention, I can agree, the "wxcode" is not needed in the library name.

But, if you build your library as .dll or .so, you will need msw31ud or msw31u (or gtk2u-2.8 or gtk3u-3.1) to distinguish libraries build with wxWidgets 2.8, or 3.0 or 3.1.

Is that a common use case for you, to have support for several wxWidgets versions at the same time?

BTW, under Linux I haven't changed the naming scheme yet. I know that some package maintainers choose to add just the wxWidgets version number to the name (like wxsqlite3-3.1). However, I find this quite confusing, since one might think that the number is the version number of wxSQLite3 itself.

All of them could be located in the same folder (system32 or /usr/local/lib)
Normally you will make lib (.a) with the same name as dll.

At least in my projects under Windows the wxWidgets libraries are not installed in system32, but in the application's directory. And in fact just adding msw31u to the DLL name is not a generic solution. One would still have conflicts, if 2 independent applications would require different wxSQLite3 versions for the same underlying wxWidgets version installed in a common directory.

However, if it helps you and possibly other users, I can make the library name configurable, so that a library name like wxsqlite3_msw31u resp. wxsqlite3_msw31ud could be used.

from wxsqlite3.

Hi Ulrich,

I newer used premake5 in my life but it is obvious, the part related to Monolithic wxWidgets goes to wxwidgets.lua file, around line 215
If you build monolithic wxWidgets you have 2 libraries in monolithic version (funny).
In my case for Release:
wxmsw310u_gcc_492-x64_kes.dll
wxmsw310u_gl_gcc_492-x64_kes.dll
Debug:
wxmsw310ud_gcc_492-x64_kes.dll
wxmsw310ud_gl_gcc_492-x64_kes.dll

For me, is normal case to use parallel several wxWidgets in the same time, even build with different compiler. E.g. wxWidgets same version, with gcc and with VC.
Code::Blocks is nice developing environment but still stuck on wxWidgsts 2.8. Together with CodeLite I use the programs parallel on Windows and Linux.

If you have naming convention as is written in your example wxsqlite3-3.1, this is version number of wxSQLite3, not wxWidgets number.
The best will be name something as:

wxsqlite35_msw310u(+ optional COMP_VERSION_VENDOR_NAME).dll

I think the WXSQLITE3_RELEASE_NUMBER could be avoid.

Best regards,

Boris

from wxsqlite3.

Hi Boris,

I newer used premake5 in my life but it is obvious, the part related to Monolithic wxWidgets goes to wxwidgets.lua file, around line 215

The problem is that I haven't found a way, how the library dependencies could be specified in premake5 based on a conditional. It could be solved using additional configurations, but that would in fact double the number of configurations. I'd really like to avoid that.

If you build monolithic wxWidgets you have 2 libraries in monolithic version (funny).

For GL support one has to explicitly link the wx GL support library. For wxSQLite3 I probably would get away with just the normal monolithic wx library.

For me, is normal case to use parallel several wxWidgets in the same time, even build with different compiler. E.g. wxWidgets same version, with gcc and with VC.
Code::Blocks is nice developing environment but still stuck on wxWidgsts 2.8. Together with CodeLite I use the programs parallel on Windows and Linux.

For which development environments would you need support for the wx monolithic build? Just gcc? Or MSVC, too?

If you have naming convention as is written in your example wxsqlite3-3.1, this is version number of wxSQLite3, not wxWidgets number.

I have no intention to use that naming scheme. It is however used by some Linux package maintainers.

The best will be name something as:

wxsqlite35_msw310u(+ optional COMP_VERSION_VENDOR_NAME).dll

I think the WXSQLITE3_RELEASE_NUMBER could be avoid.

I intend to offer something like wxsqlite3 plus an optional postfix, for which the default could be _msw31u + optional compiler and vendor. That is, no wxSQLite3 version number and only 2 digit wx version number (as for the wx link libraries).

from wxsqlite3.

Hi Ulrich,

I would like to have only two configurations Release or Debug and with different _OPTIONS solve multilib, monolithic, dll or static lib.
You don't need separate configurations for Win32 and x64. I use 32 bits compiler and get 32 bits library and 64 bits compiler to get 64 bits library.
Personally, I never used 64 bits compiler and force it with option -m32

Monolithic wxWidgets with gcc will be enough for me.

I solved my problem, with help of CodeBlocks project. This could be solution for me. I am very satisfied how the wxsqlite3 is done.

During the making of dll version I got one error more. Beginning of sqlite3secure.c

// Enable SQLite debug assertions if requested
#ifndef SQLITE_DEBUG
#if defined(SQLITE_ENABLE_DEBUG) && (SQLITE_ENABLE_DEBUG == 1)
#define SQLITE_DEBUG 1 <-- Add please
#endif
#endif

Otherwise the compiler complains on
#if SQLITE_DEBUG
in sqlite3.c, line 17369

Regards,

Boris

from wxsqlite3.

Monolithic wxWidgets with gcc will be enough for me.

Ok. I have yet to decide how to accomplish this.

During the making of dll version I got one error more. Beginning of sqlite3secure.c

// Enable SQLite debug assertions if requested
#ifndef SQLITE_DEBUG
#if defined(SQLITE_ENABLE_DEBUG) && (SQLITE_ENABLE_DEBUG == 1)
#define SQLITE_DEBUG 1 <-- Add please
#endif
#endif

Otherwise the compiler complains on
#if SQLITE_DEBUG
in sqlite3.c, line 17369

I will add the value 1. However, this seems to be a deficiency in the SQLite code. In almost all places the SQLite code checks whether the symbol SQLITE_DEBUG is defined (#ifdef or #if defined(SQLITE_DEBUG)), but in a few cases the value is checked.

from wxsqlite3.

Hi Boris,

Sorry for the delay.

For GNU make I added support for monolithic wxWidgets build. Please give it a try. Just change the definition of wxMonolithic in file config.gcc.

I also modified the default library name to include the wxWidgets platform information. Can be changed via symbol wxFlavour in file config.gcc.

I changed the definition of symbol SQLITE_DEBUG as mentioned in previous post. Probably with the next release of SQLite3 this change will be obsolete, since the issue has already been fixed on the SQLite3 development trunk.

Please let me know if the build system now works for you as expected. Thanks.

from wxsqlite3.

Hi Ulrich,

I will try your changes beginning of next week. I must first finish some other developing.
Regards,

Boris

from wxsqlite3.

Hi Ulrich,

Nice job. It is working.
I can use monolithic build of wxWidgets.

Small suggestion
You already have wxCfg in config.gcc but it is not use at all
Correct syntax is
wxCfg ?= $(WXCFG)

In my case I have two environments variable.
WXCFG=gcc492-x64_dll\mswu
WXWIN=D:\Dev\wxWidgets-3.1.0

With help of wxCfg you know if you are linking against dynamic or static library.
The are simply two (4 with debug) sets of library and WXCFG is switch between them.
This could reduce the number of configurations.

How I can switch on "verbose" mode without manually changing the makefile?

Best regards,

Boris

from wxsqlite3.

Hi Boris,

It is working. I can use monolithic build of wxWidgets.

Thanks for confirming.

Small suggestion
You already have wxCfg in config.gcc but it is not use at all

No, that's not correct. It is used inside config.gcc (resp. wx_setup.props), namely in the definition of the output directory for the resulting library. And it is done in conformance with wxWidgets itself where you have

wxOutDirName = $(wxCompilerPrefix)$(wxArchSuffix)_$(wxLibTypeSuffix)$(wxCfg)

Correct syntax is
wxCfg ?= $(WXCFG)

In my case I have two environments variable.
WXCFG=gcc492-x64_dll\mswu
WXWIN=D:\Dev\wxWidgets-3.1.0

You will probably have to adjust the following definitions in config.gcc to match your environment:

wxCompilerPrefix = gcc492
wxArchSuffix = -x64

With help of wxCfg you know if you are linking against dynamic or static library.
The are simply two (4 with debug) sets of library and WXCFG is switch between them.
This could reduce the number of configurations.

Unfortunately it's not that easy. Depending on whether you link against dynamic or static wxWidgets libraries you need to specify symbols for exporting symbols on Windows.

How I can switch on "verbose" mode without manually changing the makefile?

I'm not a make expert, but according to the GNU make documentation, passing --debug=v on the make command line should be automatically passed on to the sub-make invocations.

from wxsqlite3.

Thanks, you can close the case.

from wxsqlite3.