Compiler Issues
From WxWiki
Contents |
[edit] Borland Free Commandline Compiler
[edit] How to compile a large program with BCC with a debug version of wxWidgets
There is an upper limit on the size of a standalone-executable that can be linked by Borland's ILINK32 linker. When your app is small (about under 2.5megs total) it can be linked in with both the debug and non-debug builds of the library. However, beyond that, you will find that the linker won't be able to link the program together in a debug library (will still work in the non-debug library though). To link your big program to the debug library, do these steps:
- Clean and rebuild the wxWidgets library in debug mode, as a DLL
$ cd /wx/msw/src $ make makefile.b32 clean $ make makefile.b32 DLL=1
- Build any contrib libraries, such as the XML resource library, using the wx DLL and building a DLL (Note: there won't be a XRC dll anywhere, the wxxrc.lib will be correct though:
$ cd /wx/contrib/src/xrc $ make -f makefile.b32 clean $ make -f makefile.b32 WXUSINGDLL=1 WXBUILDDLL=1
- Build your application:
$ cd to your application's directory $ make -f makefile.b32 WXUSINGDLL=1
You now have a executable of your program. Note that at runtime, it will look for 2 DLLs:
- wx.dll (the wxWidgets debug library that you built, located in wx/lib/)
- cc3250mt.dll [the BCC runtime, which can be found in your Borland/bcc55/bin directory].
For running your app, both these DLLs need to be either somewhere in the searched path, or in the same directory as your executable. Distributing with the DLLs in the same directory as the executable makes for easier distribution, since your wx.dll may be different from other people's wx.dll.
[edit] Proper use of pragma hdrstop directive
In your headers for the .cpp files of a project, every single file should have the same included files above the hdrstop pragma. Borland can use cached headers to vastly decrease compile time, but it will only work if every file uses the same thing above the hdrstop pragma. Put all the headers that are only required for that particular .cpp file after the pragma hdrstop
[edit] GCC
[edit] Proper use of pragma interface and pragma implementation
- Note: It is not advised to use pragma interfaces at all, as for any reasonable gcc version (2.95 and up, or so) it perhaps only reduces debug enable build sizes, but other than that can lead to all kind of various problems. wxWidgets-2.7 development series will stop using these pragmas as well, until which time the chosen interface names could collide with application chosen names and cause even more interesting problems. - MR
By default, GCC will include debug code about every other .cpp file into each and every object file. This makes compile times, code size, and debug speed all worse.
It is thus strongly recommended to use the interface/implementation pragmas. There needs to be a interface directive in each header and a implementation directive in each .cpp file of your project. For example, say you had a PreferencesDialog class that you described in prefsdlg.cpp and prefsdlg.h:
- Put a pragma interface "prefsdlg.h" at the top of the prefsdlg.h file (just below the standard #ifdef __PREFSDLG_H__ that you use to only include that header file once).
- (Nitpicking here, but: You really shouldn't use identifiers like __PREFSDLH_H__ in your code. Identifiers containing __, or starting with _ and a capital letter (like _T), or _ followed by anything at global scope, are reserved to the implementation (compiler) and shouldn't be used.)
- Put a pragma implementation "prefsdlg.h" at the very top of the prefsdlg.cpp file
Each of the pragma interface/implementations should go inside an ifdef so that they are only used by GCC.
Now the compiler knows when it includes prefsdlg.h from some other .cpp file besides prefsdlg.cpp, that it shouldn't worry about including any debugging info, that it can instead wait, and the debug info can just be done once in prefsdlg.cpp
Note that if you ever get a "virtual table" error on GCC, this is nothing to do with event tables. It means you haven't set up your pragma interface/implementation correctly.
[edit] Strange error about conversion
Was porting xMule to win32 using Cygwin, and got this strange error:
invalid conversion from `int (*)(long int, long int, long int)` to `int(*)(long int, long int, long int)`
The line causing this error was:
SortItems(SortProc, sortItem + (sortAscending ? 0:100));
What came out that SortProc was a function defined as follows:
static int SortProc(long lp1,long lp2,long lpSort);
And that caused such strange error. Solution was to change the SortProc function definition to
static int wxCALLBACK SortProc(long lp1,long lp2,long lpSort);
I don't know why it had to be done like this, but I someone figures out *why*, then by all means, edit this text :).
- The reason is that wxCALLBACK changes the calling convention from the default to __stdcall (on Windows). The rather useless gcc error is indicating (or failing to) that the calling conventions differ.
[edit] Apple Project Builder / Free Dev Tools
[edit] Can't use #pragma interface/implementation on DevTools [from late 2002]
The GCC in late 2002 will fail with GCC #pragma interface and #pragma implementation. Therefore need to check that the GCC isn't apple's. For example:
#if defined(__GNUG__) && ! defined(__APPLE__) #pragma implementation "main_frame.h" #endif
[edit] VC++
[edit] Name Conflicts
If you are using VC++ and MFC in combination with the wxWidgets, the new (in wxWidgets 2.3.3) wxTopLevelWindowMSW class has a CreateDialog member function. This is a macro in the depths of Windows headers (WINUSER.H) and creates a conflict. Since the product hasn't been released yet, I thought it might be good to mention so there's a chance to fix it.
- This is still a problem in wxWidgets 2.4, when using any program that includes <windows.h> -- not just with MFC or VC++. It appears to manifest as errors like "syntax error before numeric constant" in wxWidgets headers. The solution is to always include all wxWidgets headers before <windows.h> (if you have many include files in your project, consider creating a single header which includes all the wx headers and then the windows headers, rather than doing it separately in every file).
[edit] Code optimization issues
If you have installed VC++ 6 ServicePack 5 + Processor Pack, you must know its code optimizer is quite buggy, at least when you set optimizations to "maximize speed". You have two options: turn off optimizations, OR not installing processor pack... until Microsoft fixes it.
