Buildig CodeBlocks using autotools under windows

[Indrekis]

Hi, All!

First of all, I want to thank you for this great project. I am using it (more or less) for a year and still impressed by it's capabilities and rapid progress.

Several weeks ago I decided to try to compile CodeBlocks for  windows using autotools. I do managed to compile (and even to link ;-) ) it. But obtained executable is not useable.

It launches, can load projects (including self CB project). But most (if not all???) plugins fail. For example, if codecompletion plugin is "enabled" (present in plugins folder), CB crushes almost immediately after loading any project with opened in editor files. Crash report in attached in codecompcrush.txt.

Using "Settings/Compiler and debugger" from the main menu  fails when codestat plugin is enabled (codestatcrush.txt).

CodeStat itself fails too. (It occasionally worked fine for HelloWorld project, but only once. Strange... ).
And so on...
wxSmith plugin fails to load. (<CBFOLDER>/trunk/src/output/share/codeblocks/plugins/libwxsmith.dll: not loaded (file exists?) )
On the other hand Astyle plugin works fine. So Class wizard and Plugin wizard do.

 And main problem with compiled that perverted ;-) way CB is that it refuses to compile even simplest project.It straight off proceeds with linking BEFORE compiling:

g++.exe   -o dummy.exe .objs\main.o   
g++.exe: .objs\main.o: No such file or directory
g++.exe: no input files

And tells "Nothing to be done." when I try to "Compile current file".

Could someone help me to resolve (or understand the reason) of this behavour?

Additional information:

OS: WindowsXP SP2
Compiler framework: MSYS 1.0.11 / MinGW based.
gcc 3.4.4
autoconf 2.59
automake 1.8.2
libtool 1.5.20
wxWidgets: 2.6.2
(ANSI, debug, non-monolithic, multi-threaded, native widgets - for now I do not have compiled non-debug wxWidgets)

CodeBlocks - SVN revision  2199.

Patch for build system is attached. I do my best to not break Linux builds, but I cannot test it.

CB was compiled both in-place and in separated folder. For the second case executables and dlls were manually copied into tree, generated by update. Than wx dlls and mingwm10.dll were copied into folder where codeblocks.exe exists. 

configure arguments:

CXXFLAGS="-fmessage-length=0 -Winvalid-pch"
CPPFLAGS="-DHAVE_W32API_H -D__WXMSW__  -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP  -D__WXDEBUG__"
./configure --with-wx-config=<wxWidgets folder>/bin/wx-config --with-wx-prefix=<wxWidgets folder> --enable-contrib --with-platform=win32

Bootstrap was called before the configure.

Additional comments:

• Debug version of wxWidgets produces some warnings.
  
  On startup:
  ../src/common/menucmp.cpp(67): assert "parentMenu != NULL" faile<CBFOLDER>  menuitem should have a menu.
  
  On "Settings/Compiler and Debuger":
  ../src/msw/treectrl.cpp(1142): assert "wxAssertFailure" faile<CBFOLDER> invalid tree item
  
  On "Project/Build options"
  ../src/msw/treectrl.cpp(1142): assert "wxAssertFailure" faile<CBFOLDER> invalid tree item
  then (many times, until cancel in assert window is pressed)
  <wxWidgets folder>/wx/object.h(326): assert "ptr" faile<CBFOLDER> wxStaticCast() used incorrectly
  
  and so on.
  
  
• As for revision 2060 building without precompiled headers is broken. (At least under windows)
  
  
• Necessary defines and options were deduced, using build log from IDE compilation (using supplied project file).
  For plugins, difference in compiler parameters (if I don't missed something important):
  IDE compilation:
  -g
  -pipe
  -fexceptions
  
  autotools:
  
  -DHAVE_CONFIG_H    ;-)
  -DNO_GCC_PRAGMA
  -O2
  -ffast-math
  -fPIC
  -DPIC
  
  
• Am I doing something wrong? When compiling CB using project file, gcc is involved like (arrows are added by me):
  g++.exe <many useful options> -c  =>sdk\as\source\as_anyobject.cpp<= -o .objs\2.6\sdk\as\source\as_anyobject.o
  So compiler does not look for headers in sdk\as\source and headers like as_config.h for the example are not found. I resolved the issue by adding according paths for each target, but it looks like other developers do not have such problems...
  
  

PS. Please, excuse my English - I am not very experienced in this language.


[attachment deleted by admin]

[mandrav]

Well, I never tested the autotools build in anything else than linux. In fact it shouldn't be possible to build without tweaking, but I guess that's what your patches are for

[tomjnx]

I've now succeeded in cross compiling mingw32 binaries on Fedora.

I've attached the patch against current trunk. I've tested that it still builds natively as well as cross compiles for mingw32.

There are some differences to the codeblocks build, namely the DLL names, as libtool really wants library (DLL) names to start with "lib".

I haven't tested native builds using mingw32 on windows, but I suspect this should be close to working.

Tom

[oBFusCATed]

Code

+AM_CFLAGS = $(WX_CFLAGS)
+if WIN32
+AM_CPPFLAGS = $(WX_CPPFLAGS) -DBUILDING_PLUGIN -DWXMAKINGDLL_PROPGRID -DwxPG_USE_WXMODULE=0
+else
+AM_CPPFLAGS = $(WX_CPPFLAGS)
+endif
+AM_CXXFLAGS = $(WX_CXXFLAGS)
+if WIN32
+AM_LDFLAGS = $(WX_LIBS) -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import
+else
+AM_LDFLAGS = $(WX_LIBS)
+endif
+

Why are you doing this all over the place?
Have you tried to put it in the configure.in/.ac?

[tomjnx]

Why are you doing this all over the place?
Have you tried to put it in the configure.in/.ac?

Because not all directories need the same flags.

That is likely the reason why already now the WX flags/libraries are in their separate variables and not in the global CPPFLAGS/LIBS.

Generally I've tried to stay close to the flags used by the C::B windows build.

It's possible that some windows build flags are harmless on unix, so the use of if WIN32 could probably be cut down. But then again I am not yet that familiar with the C::B codebase

[tomjnx]

Version 2 of the patch. I reduced if WIN32 usage a lot, and removed lots of unnecessary defines.

[oBFusCATed]

Why don't you define a CROSS_COMP_CFLAGS/LDFLAGS in the configure.in/.ac and then used them, when they are needed?
If the current compile is not for CrossComp, define them blank.
This way the ifdefs will be only in one file.

[tomjnx]

Why don't you define a CROSS_COMP_CFLAGS/LDFLAGS in the configure.in/.ac and then used them, when they are needed?
If the current compile is not for CrossComp, define them blank.
This way the ifdefs will be only in one file.

That could work for some of the LDFLAGS (namely the auto import/export all options), but it does not work for the CFLAGS, due to the windows dllimport/dllexport stupidity and the way wx conventions handle these. There aren't many CFLAGS conditionals left anyway.

Thinking about how this could help the LDFLAGS case.

[tomjnx]

Ok most conditionals zapped.