[SOLVED] C::B 13.12 -static not working

[dcbdbis]

My solution is not the most desired solution.

The wxWidgets folks are unwilling to assist in the linking issues.

I have received support here.....for which I am appreciative......but there remains is no succinct solution available.

To lower my headache factor....I have gone with the QT tooset and development environment for fixing my Windows issues. I've used QT several times before....successfully, but I am not a big QT fan.

Under FreeBSD/Linux....C::B and wxWidgets works flawlessly.  Under Widows.....wxWidgets is just too much hassle and it's burning too much of my time.

If C::B were to allow me to use the QT libraries (the wiki didn't include QT as a supported toolset)...I would stick with C::B under windows.

So for me and my looming deadline.....QT will have to suffice for Windows.

I apologize I couldn't come up with a different solution...I have certainly tried.


Sincerely and respectfully,

Dave

[Jenna]

I just did a quick test with a stically build wx2.8 and it seems to work flawlessly.
I just build wx with "SHARED=0" and did not change anything else.
But I also used a unicode.build, not an ansi one.
I did nothing complex, just build the wx-sample.

I can run it from the output-folder from inside a cmd-window with empty path.

[Jenna]

Just for the record I did not use the -static option, just linked with static libs.
It also runs flawlessly under wine on my FC20 64-bit and on a W2K-VM without even MinGW installed.

[Jenna]

Next test with ansi-build of wx also works fine.

Make sure, that you do a full rebuild after switching to the static libs.

If it still does not work, can you provide a sample project that fails ?

[stahta01]

FYI:

Switching to doing a Monolithic build from doing a Multilib build of wxWidgets can result in very weird errors.

I often have to delete all the object and library files manually to get builds to work once more.
(make clean is NOT enough to fix the problem.)

No idea if the poster might have done a Multilib build of wxWidgets or not.

Tim S.
 

[dcbdbis]

Thank you all for the replies. I do appreciate it.

Unfortunately, I have already been doing things I see in the recent posts.

For example, when I "clean", I manually delete the gcc_dll and gcc_lib directories, then go into the build\msw directory and manually delete all the object file directories...then afterwards, I will allow the compiler to do it's own clean.

The one post that intrigues me is the multi_lib comment. I think I'll explore that further once I'm out from under the deadline.....


Again,

Thank you all very much.


Sincerely and respectfully,

Dave

[dcbdbis]

I have reopened the issue. I bought myself some time from my client...

Question:

I am doing this all from  Windows 7 x64 VM running in VirtualBox, under FreeBSD.....Is there any possibility that GCC doesn't appreciate being ran under emulation?

Thanks!

I am devoting the rest of the day to getting this squared away.........


Sincerely and respectfully,


Dave

[stahta01]

I have reopened the issue. I bought myself some time from my client...

Question:

I am doing this all from  Windows 7 x64 VM running in VirtualBox, under FreeBSD.....Is there any possibility that GCC doesn't appreciate being ran under emulation?

Thanks!

I am devoting the rest of the day to getting this squared away.........


Sincerely and respectfully,


Dave

Yes, there is a possibility. But, without a build log no one can help you!

Did you post a build log on the wxForum? Because without one no one can help you.

Tim S.
 

[Jenna]

I have reopened the issue. I bought myself some time from my client...

Question:

I am doing this all from  Windows 7 x64 VM running in VirtualBox, under FreeBSD.....Is there any possibility that GCC doesn't appreciate being ran under emulation?

Thanks!

I am devoting the rest of the day to getting this squared away.........


Sincerely and respectfully,


Dave

I use Windows 7 Pro 64 bit in a Qemu/KVM VM and there are no issues.
Which gcc-version do you use ?

[dcbdbis]

I use the bundled compiler in the C::B setup. I wanted to remain in an "orthodox" configuration.

The exact download I used is: codeblocks-13.12mingw-setup.exe

I have cleaned the VM, use utilities to clean the registry and such......and am starting over....

Only this time..I am going to log each step I take....then post the entire trail of what I am doing to the forum...This way all will see exactly what I am doing right, or what I am doing wrong....

Thanks!

Sincerely and respectfully,

Dave

[dcbdbis]

1)   Removed the MS SDK for Windows 7, and the additional stuff that gets installed with it. Then using a suite of utilities, cleaned the disk of junk files, and cleaned my registry of the ~282 junk entries left behind.

2)   Navigated to http://www.codeblocks.org/downloads/26. Downloaded the codeblocks-13.12minggw-setup.exe and performed a "full install" of the same.

3)   Then I ensured the mingw path was properly added to WIndows by following the wiki at : http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef

4)   I downloaded wxWidgets by following this verbiage and the embedded link on this same wiki: "... The current recommended version of wxWidgets to use is 2.8.12. Click here to download the wxWidgets 2.8.12 sources for Windows (wxMSW-2.8.12-Setup.exe; 12.2 MB...." I installed the same taking all the defaults in the installer.

5)   In building wxWidgets in this same wiki...I installed my preferences in the config.gcc file...instead of passing it on the cli. Purpose: So I don't have to remember the exact cli for clean operations. File is included below.

//------------------------------------------------------

Code

# =========================================================================
#     This configuration file was generated by
#     Bakefile 0.2.9 (http://www.bakefile.org)
#     Beware that all changes made to this file will be overwritten next
#     time you run Bakefile!
# =========================================================================


# -------------------------------------------------------------------------
# These are configurable options:
# -------------------------------------------------------------------------

# Compiler flags to link shared library 
LINK_DLL_FLAGS ?= -static

# Compiler flags to link loadable module 
LINK_MODULE_FLAGS ?= -static

# C compiler 
CC = gcc

# C++ compiler 
CXX = g++

# Standard flags for CC 
CFLAGS ?= 

# Standard flags for C++ 
CXXFLAGS ?= -fno-keep-inline-dllexport

# Standard preprocessor flags (common for CC and CXX) 
CPPFLAGS ?= 

# Standard linker flags 
LDFLAGS ?= 

# The C preprocessor 
CPP ?= $(CC) -E

# What type of library to build? [0,1]
SHARED ?= 0

# Build wxUniversal instead of native port? [0,1]
WXUNIV ?= 0

# Compile Unicode build of wxWidgets? [0,1]
UNICODE ?= 0

# Use MSLU library when building Unicode version. [0,1]
MSLU ?= 0

# Type of compiled binaries [debug,release]
BUILD ?= release

# Should debugging info be included in the executables? The default value
# "default" means that debug info will be included if BUILD=debug
# and not included if BUILD=release. [0,1,default]
DEBUG_INFO ?= default

# Should __WXDEBUG__ be defined? The default value "default" means that it will
# be defined if BUILD=debug and not defined if BUILD=release. [0,1,default]
DEBUG_FLAG ?= default

# Multiple libraries or single huge monolithic one? [0,1]
MONOLITHIC ?= 1

# Build GUI libraries? [0,1]
USE_GUI ?= 1

# Build wxHTML library (USE_GUI must be 1)? [0,1]
USE_HTML ?= 1

# Build multimedia library (USE_GUI must be 1)? [0,1]
USE_MEDIA ?= 1

# Build wxXRC library (USE_GUI must be 1)? [0,1]
USE_XRC ?= 1

# Build wxAUI library (USE_GUI must be 1)? [0,1]
USE_AUI ?= 1

# Build wxRichTextCtrl library (USE_GUI must be 1)? [0,1]
USE_RICHTEXT ?= 1

# Build OpenGL canvas library (USE_GUI must be 1)? [0,1]
USE_OPENGL ?= 0

# Build ODBC database classes (USE_GUI must be 1)? [0,1]
USE_ODBC ?= 0

# Build quality assurance classes library (USE_GUI must be 1)? [0,1]
USE_QA ?= 0

# Enable exceptions in compiled code. [0,1]
USE_EXCEPTIONS ?= 1

# Enable run-time type information (RTTI) in compiled code. [0,1]
USE_RTTI ?= 1

# Enable threading in compiled code. [0,1]
USE_THREADS ?= 1

# Enable wxCairoContext for platforms other than Linux/GTK. [0,1]
USE_CAIRO ?= 0

# Link with gdiplus.lib? (Needed for wxGraphicsContext, will also set wxUSE_GRAPHICS_CONTEXT) [0,1]
USE_GDIPLUS ?= 0

# Is this official build by wxWidgets developers? [0,1]
OFFICIAL_BUILD ?= 0

# Use this to name your customized DLLs differently 
VENDOR ?= custom

#  
WX_FLAVOUR ?= 

#  
WX_LIB_FLAVOUR ?= 

# Name of your custom configuration. This affects directory
# where object files are stored as well as the location of
# compiled .lib files and setup.h under the lib/ toplevel directory. 
CFG ?= 

# Compiler flags needed to compile test suite in tests directory. If you want
# to run the tests, set it so that the compiler can find CppUnit headers. 
CPPUNIT_CFLAGS ?= 

# Linker flags needed to link test suite in tests directory. If you want
# to run the tests, include CppUnit library here. 
CPPUNIT_LIBS ?= 

# Version of C runtime library to use. You can change this to
# static if SHARED=0, but it is highly recommended to not do
# it if SHARED=1 unless you know what you are doing. [dynamic,static]
RUNTIME_LIBS ?= static

# Set the version of your Mingw installation here.
#     "3" ...... this is for Mingw 2.0 or newer (comes with gcc3)
#     "2.95" ... for Mingw 1.1 or any of the older versions [3,2.95]
GCC_VERSION ?= 3

//-----------------------------------------------------------------------------

6)   Opened a cli in Windows, and navigated to "c:\wxWidgets-2.8.12\build\msw", then issued the following command in the cli: "mingw32-make -f makefile.gcc clean"

7)   Once the cleaning operation was completed, I then issued: "mingw32-make -f makefile.gcc"

8   The build proceeded without errors. I ended up with a "gcc_lib" subdirectory with the following files in it:
//-----------------------------------------------------------------
c:\wxWidgets-2.8.12\lib\gcc_lib>dir
 Volume in drive C is CB
 Volume Serial Number is 04FF-04B1

 Directory of c:\wxWidgets-2.8.12\lib\gcc_lib

08/07/2014  03:03 PM    <DIR>          .
08/07/2014  03:03 PM    <DIR>          ..
08/07/2014  02:56 PM           197,168 libwxexpat.a
08/07/2014  02:55 PM           142,960 libwxjpeg.a
08/07/2014  03:03 PM        17,579,396 libwxmsw28.a
08/07/2014  02:55 PM           166,664 libwxpng.a
08/07/2014  02:55 PM            74,928 libwxregex.a
08/07/2014  02:56 PM           328,452 libwxtiff.a
08/07/2014  02:55 PM            73,190 libwxzlib.a
08/07/2014  03:03 PM    <DIR>          msw
               7 File(s)     18,562,758 bytes
               3 Dir(s)  30,449,082,368 bytes free

c:\wxWidgets-2.8.12\lib\gcc_lib>

8a. The build.cfg file that the compilation process generated is:

Code

WXVER_MAJOR=2 
WXVER_MINOR=8 
WXVER_RELEASE=12 
BUILD=release 
MONOLITHIC=1 
SHARED=0 
UNICODE=0 
WXUNIV=0 
CFG= 
VENDOR=custom 
OFFICIAL_BUILD=0 
DEBUG_FLAG=default 
DEBUG_INFO=default 
RUNTIME_LIBS=static 
MSLU=0 
USE_EXCEPTIONS=1 
USE_THREADS=1 
USE_GUI=1 
USE_HTML=1 
USE_MEDIA=1 
USE_ODBC=0 
USE_OPENGL=0 
USE_QA=0 
USE_GDIPLUS=0 
COMPILER=gcc 
CC=gcc 
CXX=g++ 
CFLAGS= 
CPPFLAGS= 
CXXFLAGS=-fno-keep-inline-dllexport 
LDFLAGS= 

//--------------------------------------------------------------------

9)   I opened my project, cleaned the workspace, rebuilt the workspace, and ended up with this error: "C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_app.o):app.cpp|| undefined reference to `InitCommonControls@0'|" and others like it.

10)   In the global compiler settings I have included all the libraries listed above in::
"Settings->Compiler->Linker Settings->Link libraries" And in the "Other linker options" I have "-static" (minus the quotations).

11) The full build log is included here:

Code

||=== Build: Debug in BicycleGearingCalculator (compiler: GNU GCC Compiler) ===|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_app.o):app.cpp|| undefined reference to `InitCommonControls@0'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_app.o):app.cpp|| undefined reference to `OleInitialize@4'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_app.o):app.cpp|| undefined reference to `OleUninitialize@0'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_msw_spinbutt.o):spinbutt.cpp|| undefined reference to `CreateUpDownControl@48'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_filename.o):filename.cpp|| undefined reference to `CoCreateInstance@20'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_filename.o):filename.cpp|| undefined reference to `IID_IPersistFile'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_resync_to_restart'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_std_error'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_destroy_decompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_CreateDecompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_read_header'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_start_decompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_read_scanlines'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_finish_decompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_destroy_decompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_finish_decompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_destroy_decompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_std_error'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_destroy_compress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_CreateCompress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_set_defaults'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_set_quality'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_start_compress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_write_scanlines'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_finish_compress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imagjpeg.o):imagjpeg.cpp|| undefined reference to `jpeg_destroy_compress'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp|| undefined reference to `CoLockObjectExternal@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp|| undefined reference to `RegisterDragDrop@8'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp|| undefined reference to `CoLockObjectExternal@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp|| undefined reference to `RevokeDragDrop@4'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp|| undefined reference to `CoLockObjectExternal@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp:(.data+0x0)||undefined reference to `IID_IUnknown'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_droptgt.o):droptgt.cpp:(.data+0x4)||undefined reference to `IID_IDropTarget'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_msw_listctrl.o):listctrl.cpp|| undefined reference to `ImageList_GetImageCount@4'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_msw_listctrl.o):listctrl.cpp|| undefined reference to `ImageList_Draw@24'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_msw_listctrl.o):listctrl.cpp|| undefined reference to `ImageList_GetIconSize@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_statbr95.o):statbr95.cpp|| undefined reference to `CreateStatusWindowA@16'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_Destroy@4'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_Create@20'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_GetImageCount@4'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_GetIconSize@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_Add@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_AddMasked@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_ReplaceIcon@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_Replace@16'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_ReplaceIcon@12'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_Remove@8'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_SetBkColor@8'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_Draw@24'|
C:\wxWidgets-2.8.12\lib\gcc_lib\libwxmsw28.a(monolib_imaglist.o):imaglist.cpp|| undefined reference to `ImageList_GetIcon@12'|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build failed: 50 error(s), 0 warning(s) (0 minute(s), 2 second(s)) ===|

Can anyone help with what is going wrong that I cannot generate a statically linked exe?

To be clear...if I generate a shared library, then put the resulting "...custom.dll" in the folders for debug and release...I get a good compile without errors, and a perfectly working application. The issue is that I need to compile this thing statically to meet the criteria I have been given...

I am appreciative for any help,


Sincerely and respectfully,


Dave

[dcbdbis]

THE SOLUTION:


I needed to add certain libraries manually into my build from "c:\Program File (x86)\CodeBlocks\MinGW\lib"

Static compilation of an app then proceeds just fine after you get all the libraries you need from this folder into the linker settings...............

Damn!...Probably par normal for a Windows dev, but for a pretty much purebreed Linux/FreeBSD dev........it didn't come onto my radar.

My previous Windows RAD environments (Borland C++ Builder)...handled all that stuff for you. The erorrs clearly showed I was missing libs....I simply didn't know where to get them in the Windows environment.

Anyway,

My SINCERE THANKS to all who responded.....and I hope this helps others.

As a suggestion......may I recommend that this info finds it way onto the wiki's I used? It would sure help others and perhaps lower traffic on the forum, like mine, with these issues.


Sincerely and respectfully,


Dave

[pirx67]

Hello,

after all I would like to add my experience with static linking here because I had some issues and counterintuitive behavior some weeks ago. This experience is gained only
under Linux atm. but the behavior of GCC should be similar under Linux and Windows.

Unfortunately you only provided the content of the "Build messages" tab and not the content of the "Build log" tab of Code::Blocks. The build log would also contain the command
line so I can do only some guesswork on how GCC was called.

My experience shows that you don't need to use "-static" to link a static library into your executable. If you provide the path to the directory with the static libraries (here the
wxWidgets libs) and you refer to them with -lxxx then they are simply linked in. They are used like another blob of object files. In that case the C runtime libraries will be linked in dynamically. But what makes static linking sometimes surprising is that you must provide your objects and the libraries in the right order.

If you have -lxxx before your objects on the command line the library libxxx.a will be unused at this moment in the first linking pass and therefore skipped by the linker. It is then not available any more in the second pass of the linking stage. If your objects use symbols from the "skipped" library you will get undefined references at the end of the second pass. The cure is to have -lxxx after (!) all your objects so that the linker can see in the first pass the open references from your objects and pull all necessary libraries in that are later specified on the command line.

If you additionally add "-static" as a command line option then also the C runtime library will be linked statically into your executable. This makes your program even bigger.
In my understanding the "-static" must also be the first (!) option on the command line (before any objects) because the linker needs to pull in different start code (header/footer
libraries) if it builds a program that is fully (including the C runtime) static linked.

Perhaps this helps,
    pirx67

PS: I attached a small test project (plain Makefile based) to show the different ways to build a program and a static/dynamic library.
     Look into PrintBufLib/pbtest/buildlog.txt for the compiler (linking) command lines and the (error) output.
     The libraries are built in PrintBufLib/pblib.


[attachment deleted by admin]

[dcbdbis]

Some words of advice for my fellow FOSS developers who may come across a client who needs a windows build. Lessons I have learned in other words.

Initial Comments: This was not a C::B issue. It was an issue between the documentation between wxWidgets, and minGW....where not all of what you need was there to read in a nice concise step by step guide.
In essence, between the different organizations....there are documentation gaps. I had a lot to fill in the gaps on myself with the help of this community. If I had anyone to really play point the finger on...It would probably be MinGW first for not making it obvious, and then wxWidgets for not mentioning this necessary setup step in their guides under MinGW.

This was not a C::B issue.....But the wxWidgets folks didn't want to help....so the folks here did.


a)    Don't built wxWidgets monolithic....You'll spend hours sorting through the libraries under the mingw\lib tree trying to satisfy all the dependencies you will generate. Only link in what you need, and the mingw\lib tree won't require as much searching from you.

b)    Consult MSDN (google/yahoo searches) when an error is clearly a windows lib and not a wxlib. It'll point you to the proper name of the lib to include.

c)    CodeBlocks does not need the "-static" switch in compiler options as previously mentioned. Just adding the libraries to the "linker libraries" section under "linker settings" is enough.

d)    For a base app, I ended up including my libraries in the order in which the errors appeared. This ensured that I was including things in the order the linker needed. Please see attached pic for a base setup that doesn't do anything fancy...It will just gets you the basics.

e)    For Windows builds...you will have to include libraries in the mingw\lib tree. Otherwise you will end up beating your head against a wall like I did. It's a windows thing....


Again, I want to thank the community here for assisting through what may be to win developers basic.....but for a FOSS dev....Who's been using UNIX before the AT&T System V days...when 300 baud modems were exciting....I simply didn't know where to look. I was lost in Windows land for sure......

A lesson learned painfully, is a lesson not soon forgotten.....


Thank you all again,

Sincerely and respectfully,

Dave

[MortenMacFly]

One hint from my side: it is a better style if you do not add the full path to each library but just the libraries name to the list of libs to link against and add the folders to these libs to the link directory options. Furthermore for the future: C::B features project wizards that help you with setting up projects including wxWidgets.