Author Topic: building CodeBlocks with M$ VC++ Toolkit 2003 (Read 28035 times)

tiwag · « **on:** May 16, 2005, 05:54:59 pm »

has anybody tried to convert or already converted the
CodeBlocks.cbp (wxWidgets 2.4.2 build) project file
to use it with the M$ VC++ Toolkit 2003 ?

GCC is a little bit "slow" ... so i would prefer to use VC7

if nobody has done it already but somebody is interested to do
it with me, please post here.

thanks
--tiwag

CrazyAbbot · « **Reply #1 on:** May 18, 2005, 01:25:53 pm »

I've been trying, but its giving me some wierd compile errors, and sometimes it gets stuck on linking tinyxml.lib. although i can get it to work fine in visual studio.

however VC++ breaks on sdk\managedthread.cpp
'__ctor' is not a member of wxThread. line21

It dosn't like the SANITY_CHECK() macro much either.

tiwag · « **Reply #2 on:** May 19, 2005, 12:33:26 pm »

Quote from: CrazyAbbot

I've been trying, but its giving me some wierd compile errors, and sometimes it gets stuck on linking tinyxml.lib. although i can get it to work fine in visual studio.

however VC++ breaks on sdk\managedthread.cpp
'__ctor' is not a member of wxThread. line21

It dosn't like the SANITY_CHECK() macro much either.

hehe

the same as here by me: error C2039

Code: [Select]

Compiler  : Microsoft Visual C++ Toolkit 2003 (called directly)
Directory : D:\cpp\_projects\Codeblocks\CodeBlocks_src_vc\
--------------------------------------------------------------------------------
Switching to target: sdk
...
sdk\managedthread.cpp(20) : error C2039: '__ctor': Ist kein Element von 'wxThread'
        D:\wx242\include\wx\thread.h(423): Siehe Deklaration von 'wxThread'
Process terminated with status 1 (0 minutes, 1 seconds)
1 errors, 0 warnings

@crazyAbbot: Have you managed to build *any* plugin dll with VC ?
can you please send me a visual studio project file, which is working by you ?

thanks
--tiwag

CrazyAbbot · « **Reply #3 on:** May 20, 2005, 10:34:13 am »

I havn't been able to get it working at all. Since the entire project was written using GCC then it's to be expected that visual studio won't like it. the source will probably need to be fixed with some #ifdefs. however i don't understand the source code well enough to fix it

tiwag · « **Reply #4 on:** May 20, 2005, 12:20:12 pm »

Quote from: CrazyAbbot

I've been trying, but its giving me some wierd compile errors, and sometimes it gets stuck on linking tinyxml.lib.
although i can get it to work fine in visual studio.
....

aahh, i thought you meant the hole project, not only the single target
sorry for misunderstanding

tiwag

rickg22 · « **Reply #5 on:** June 02, 2005, 07:29:05 pm »

tiwag: I'm the one who put those SANITY_CHECK() macros. They're defined in the sanitycheck.h file. No, I didn't test them with other compilers, so If you could find a way to fix them....

The sanity checks are required to prevent C::B from crashing under certain conditions. (Some events are processed recursively, and this won't be changed unless most ppl vote for it after 1.0-FINAL is released)

CrazyAbbot · « **Reply #6 on:** June 04, 2005, 02:22:22 pm »

The Sanity Check macro isn't causing the compile to break. however there are many times when you call the macro with no parameters, which causes the compiler to generate a warning.

It's the managedthread.cpp which causes things to snap.
I havn't had much time to look at it right now because of university etc.
any clues as to why it's doing that?

rickg22 · « **Reply #7 on:** June 04, 2005, 04:20:09 pm »

Apparently the offending part is:

Code: [Select]


ManagedThread::ManagedThread(bool* abortflag) : 
wxThread::wxThread(wxTHREAD_JOINABLE),
m_pAbort(abortflag)

It's in the constructor part. What I don't get is, how does this thing tell me that the constructor "wxThread::wxThread(wxTHREAD_JOINABLE)" isn't part of wxThread?

Hmmm maybe it's got to do with not having a default constructor. But this is the only way that I could derive from wxThread, since the thread type variable is private :x

rickg22 · « **Reply #8 on:** June 08, 2005, 06:37:40 pm »

Guys I'm thinking. Maybe we should ask about this particular problem in the wxWidgets forums? Maybe someone could give us a hand.

Urxae · « **Reply #9 on:** June 08, 2005, 07:04:20 pm »

Hey, I was wondering, why is that second line

Code: [Select]

wxThread::wxThread(wxTHREAD_JOINABLE), instead of just

Code: [Select]

wxThread(wxTHREAD_JOINABLE),?

Normally you only need the name of the class in an initializer list, that you're calling the constructor is sort of implied

rickg22 · « **Reply #10 on:** June 08, 2005, 07:42:37 pm »

You do? :oops: Oh man, I guess I need to fix that (but i'm at work now). Can somebody change this line of code and try to compile with VC++ toolkit, to see if it works now?

Urxae · « **Reply #11 on:** June 08, 2005, 09:09:21 pm »

Sorry, can't help you on that one, I just have MinGW here...

rickg22 · « **Reply #12 on:** June 08, 2005, 09:39:10 pm »

Oh, well in the meantime you can remove that "wxThread::" part in the constructor and see if it compiles ok

rickg22 · « **Reply #13 on:** June 11, 2005, 06:23:34 pm »

OK guys i removed the "wxThread::" in the constructor. Mind checking if it compiles now?

CrazyAbbot · « **Reply #14 on:** June 15, 2005, 12:50:53 pm »

Ah yep that fixed that problem. There are a few other issues. I'll see if i can fix them

EDIT:

What is libwxxrc and libstc?

how are they made?

David Perfors · « **Reply #15 on:** June 15, 2005, 02:54:31 pm »

for wx 2.4.2 look into the contrib dir. (see installatio instructions in the wiki)
for wx 2.6.* you will find the stc in the contrib dir and xrc with USE_XRC option in the normal build (again look into the wiki)

CrazyAbbot · « **Reply #16 on:** June 15, 2005, 04:57:52 pm »

Ok ive done that, both the stc and xrc librarys compiled as a DLL and linked in

It's been giving me a few more errors now, in trying to link codeblocks.dll
I've sorted out most of them, but these ones remain.

Some of them look like functions/classes in the dll itself, why are they causing link errors?

I'm using wx 2.4.2

Code: [Select]


cbeditor.obj : error LNK2001: unresolved external symbol "protected: static struct wxEventTable const wxStyledTextCtrl::sm_eventTable" ([email protected]@@[email protected]@B)
cbeditor.obj : error LNK2001: unresolved external symbol "char const * const wxSTCNameStr" ([email protected]@3PBDB)
editorconfigurationdlg.obj : error LNK2001: unresolved external symbol "char const * const wxSTCNameStr" ([email protected]@3PBDB)
cbeditor.obj : error LNK2001: unresolved external symbol "public: static class wxClassInfo wxStyledTextCtrl::sm_classwxStyledTextCtrl" ([email protected]@@[email protected]@A)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_USERLISTSELECTION" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_DWELLEND" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_DWELLSTART" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_CHARADDED" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_CHANGE" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_UPDATEUI" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_MARGINCLICK" ([email protected]@3HB)
projectmanager.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
projecttemplateloader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
xtra_res.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
configmanager.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
filegroupsandmasks.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
pipedprocess.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
projectbuildtarget.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
cbplugin.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected]) referenced in function "void __cdecl wxPostEvent(class wxEvtHandler *,class wxEvent &)" ([email protected]@[email protected]@[email protected]@@Z)
cbproject.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])
compiler.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected]) referenced in function "public: void __thiscall RegExArray::Add(struct RegExStruct const &,unsigned int)" ([email protected]@@[email protected]@[email protected])
compilerfactory.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl wxAssert(int,char const *,int,char const *,char const *)" ([email protected]@[email protected])

rickg22 · « **Reply #17 on:** June 15, 2005, 11:27:44 pm »

Check out the latest CVS and see if the errors are reduced. I think it's got to do with a DLLIMPORT clause missing.

Regarding the wxAssert, it seems (IMHO) you're using the DEBUG build of wxwidgets. Check out the wiki for wxwidgets compilation instructions.

Oh, found similar warnings in the web. Look!

http://lists.wxwidgets.org/archive/wxPython-users/msg04275.html

Quote

>but now I am getting unresolved externals.
> A bunch of unresolved externals involving wxAssert like this:
> windows.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) v
> void __cdecl wxAssert(int,char const *,int,char const *,char const *)" (__imp_?wx
[email protected]@[email protected])

>as well as a bunch about wxObject new:

> wx.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public
: static void * __cdecl wxObject::operator new(unsigned int,char const *,int)" (
[email protected]@[email protected])

You need to rebuild everything. It looks like at lease some of your wxPython .obj files were built with hybrid settings.

CrazyAbbot · « **Reply #18 on:** June 16, 2005, 03:39:24 am »

Ok, i've downloaded the code from cvs and i'm using that.

ive found a little oddity in your code, its nothing major but the compiler complains about it.

in toolsmanager.h you have struct Tool{} but you prototype it elsewhere as class Tool;

I've done this in toolsmanager.h to shut it up.

Code: [Select]


class Tool
{
public:
	Tool(){ menuId = -1; }
	wxString name;
	wxString command;
	wxString params;
	wxString workingDir;
	int menuId;
};

I'm not using a debug build of wxwidgets or any other library and i'm linking it with libtinyxml, wxxrc stcdll and the wxwidgets dll.

I'm defining these preprocessor symbols. Is there anything im missing?

__WX__
__WIN32__
__WINDOWS__
WINDOWS
WXMSW
__WXMSW__
WXUSINGDLL
EXPORT_LIB
EXPORT_EVENTS
_USRDLL

The build errors are a bit different now. they seem to be about the styled text control. Thats built as a dll.

The wiki isnt completey clear, should the stc and xrc be build as static libraries?

compiling and linking stc staticly seems to generate even more linker errors.

Code: [Select]


------ Build started: Project: codeblocks_dll, Configuration: Release Win32 ------

Linking...
   Creating library Release/codeblocks_dll.lib and object Release/codeblocks_dll.exp
cbeditor.obj : error LNK2001: unresolved external symbol "protected: static struct wxEventTable const wxStyledTextCtrl::sm_eventTable" ([email protected]@@[email protected]@B)
cbeditor.obj : error LNK2001: unresolved external symbol "char const * const wxSTCNameStr" ([email protected]@3PBDB)
editorconfigurationdlg.obj : error LNK2001: unresolved external symbol "char const * const wxSTCNameStr" ([email protected]@3PBDB)
editormanager.obj : error LNK2001: unresolved external symbol "char const * const wxSTCNameStr" ([email protected]@3PBDB)
cbeditor.obj : error LNK2001: unresolved external symbol "public: static class wxClassInfo wxStyledTextCtrl::sm_classwxStyledTextCtrl" ([email protected]@@[email protected]@A)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_USERLISTSELECTION" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_DWELLEND" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_DWELLSTART" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_CHARADDED" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_CHANGE" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_UPDATEUI" ([email protected]@3HB)
cbeditor.obj : error LNK2001: unresolved external symbol "int const wxEVT_STC_MARGINCLICK" ([email protected]@3HB)
Release/codeblocks_dll.dll : fatal error LNK1120: 10 unresolved externals

I might give it a go with wx widgets 2.6 later on

rickg22 · « **Reply #19 on:** June 16, 2005, 07:21:09 am »

OK, updated CVS with your Tool code. Did you remember to copy the libstc.a to your mingw path, or add its directory to your linker dir?

tiwag · « **Reply #20 on:** June 16, 2005, 09:05:57 am »

Quote from: rickg22

... Did you remember to copy the libstc.a to your mingw path, or add its directory to your linker dir?

hey rick ! please remember : in this thread MSVC compiler is used

rickg22 · « **Reply #21 on:** June 16, 2005, 06:35:56 pm »

Ack! Yes, you're right. :oops: OK I'll rephrase. "Did you remember to copy the libstc.lib to your compiler path, or add its directory to your linker dir?"

CrazyAbbot · « **Reply #22 on:** June 17, 2005, 02:53:04 am »

yeah im linking with libstc, libtinyxml and libwxxrc

do i complie stc and xrc as dll's or static libraries?

niether way works, i'll have to fiddle with it a bit more.
im not too familar with creating DLL's.

rickg22 · « **Reply #23 on:** June 17, 2005, 05:53:50 am »

According to the codeblocks compilation instructions they have to be linked statically.

CrazyAbbot · « **Reply #24 on:** June 17, 2005, 04:37:34 pm »

Ok ive got it all to compile and link etc, i've built the codeblocks exe

It loads the splash screen and then crashes.

I'll have a look at this in more detail later on to see what is going on. i think i might be forgetting to do link or compile something.

rickg22 · « **Reply #25 on:** June 17, 2005, 06:35:42 pm »

Hmmm. Perhaps you should debug it and see what's the offending line.

BTW, did you try getting latest CVS? I discovered a missing DLLIMPORT clause that crashed whenever I added event handling to certain classes. Maybe this missing DLLIMPORT causes VC++ builds to crash, too.

CrazyAbbot · « **Reply #26 on:** June 18, 2005, 05:21:17 am »

I tried it again with the CVS code and sort of have it working now, without any plugins.

The main problem is the codeblocks.dll MSVC won't build it as a dll and the plugins need to link against it

I got around this by linking it as a static library. however this wont work with the plugins.

You seem to be doing some odd stuff that MSVC dosn't like with regard to your dll exports. some classes appear to be defined in macros and i think they need to be marked as DLL export, im not certian. I'll look into this later. but are you aware of doing anything nonstandard with regard to this?

in the header file settings.h you have MSVC define DLLIMPORT as nothing. defining as the proper declspec gives this error when trying to make the DLL. (for just about every class exported by codeblocks.dll)

Quote

class 'FileSetArray' needs to have dll-interface to be used by clients of class 'ProjectTemplateLoader'

Also, I've noticed a lot of strange things in the code, you seem to be casting pointers to longs and vice versa, why is this? its pretty poor practice and not 64 bit portable. (not to insult the devs or anything, i know how tricky large projects can be)

rickg22 · « **Reply #27 on:** June 18, 2005, 05:41:37 am »

yeah, well. According to Yiannis, NULL isn't defined for all compilers and this is supposed to be cross-platform. But I'm sure we can argue that NULL is indeed defined for MSVC, and needed for 64-bit platforms.

So, what do you think, chief?

Anyway, CrazyAbbot, how do you define a dll import in MSVC?

CrazyAbbot · « **Reply #28 on:** June 18, 2005, 06:41:25 am »

NULL? wtf ?!

anyway,

defining dll imports and exports is the same as for mingw
MSDN linky

It's these classes declared here in the macros that have the problem, are they exported into the DLL? if not then that may be the problem.

example:
WX_DECLARE_OBJARRAY(ConfigurationPath, Configurations);

I've gone through the header files right into the mess of #defines in the wxwidgets library and maybe its something going on there? does it generate dllexport linkages when the macros generate the class?

It looks like the member classes created in the macro's are not being exported.

CrazyAbbot · « **Reply #29 on:** June 18, 2005, 08:00:26 am »

Hmm ok i just managed to get the codeblocks.dll to build and i managed to link it with the codeblocks.exe (albiet with 600+ warnings, but working none the less)

To get the DLL to link with the exe i had to declare the MessageManager class with the DLLIMPORT macro. (it was causing link errors in the main exe otherwise)

one question

in the file startherepage.cpp what is this class for?

Code: [Select]

class DLLIMPORT MyHtmlWin : public wxHtmlWindow

I had to remove the DLLIMPORT macro for it to compile

When codeblocks starts up now, it complains that its unable to open the requested document "start_here.zip#zip:start_here.html"
is this something new that was added in recently?

tiwag · « **Reply #30 on:** June 18, 2005, 08:40:16 am »

Quote from: CrazyAbbot

... ok i just managed to get the codeblocks.dll to build and i managed to link it with the codeblocks.exe (albiet with 600+ warnings, but working none the less)...

Great !
can you upload the diffs & project files somewhere ?
i would like to have a closer look too.

thanks, tiwag

rickg22 · « **Reply #31 on:** June 18, 2005, 05:35:31 pm »

Quote

in the file startherepage.cpp what is this class for?
Code: [Select]
class DLLIMPORT MyHtmlWin : public wxHtmlWindow
I had to remove the DLLIMPORT macro for it to compile

You're right! DLLIMPORT should only be used for files belonging to the SDK! I'm gonna remove it right now. I'm also adding the DLLIMPORT to messagemanager.

As a final note, can you report a bug ( Correction: feature request) at sourceforge about the 600 warnings? Please upload a file, too. Thanks

mandrav · « **Reply #32 on:** June 18, 2005, 06:21:03 pm »

Quote from: rickg22

As a final note, can you report a bug at sourceforge about the 600 warnings? Please upload a file, too. Thanks

This is not a bug Rick!
It's the code he edited to compile with an unsupported (yet) compiler. What makes you think I should be hunting down bugs from source code outside the CVS tree, instead of fixing existing (and real) bugs?

Yiannis.

rickg22 · « **Reply #33 on:** June 18, 2005, 06:51:04 pm »

Oh, sorry. Then it should be a feature request then. Anyway I'm installing the MSVC Toolkit. Actually I'm beginning to think I should have installed it from the beginning (as to give more support to VC++ users). I got this curiosity for since the bug reports about importing msvc projects.

This way, I think I could offer windows support as Yiannis' field is Linux

Anyway - Tiwag, mind giving me a hand with this? You were the one who started this whole "compiling with msvc" business. And you're OBVIOUSLY a msvc++ user, so....

CrazyAbbot · « **Reply #34 on:** June 19, 2005, 03:37:46 am »

Well, it is the code from the CVS, I just had to fix a few bugs to get it to compile.

Anyway there are a few major types of warnings that appear:

Implict cast from size_t to int (nothing important)
Calling the SANITY_CHECK() macro, but not giving it any parameters.
Cast from pointer to a long.
Using magic numbers, instead of a boolean true or false

and the main one with making codeblocks.dll

Take this bit of code from configmanager.h

Code: [Select]


WX_DECLARE_OBJARRAY(ConfigurationPath, Configurations);

I ran the header file through the preprocessor to see what it did and this is the declaration of the class it generated

Code: [Select]


class Configurations : protected wxArrayPtrVoid

so this macro is creating a class called Configurations.

If a class is declared as being exportable (in this case, ConfigManager), then all the member classes of that class must be exportable as well (class Configurations).

so MSVC wants this class to be declared as DLLEXPORT. however it seems to be working fine without it. is class Configurations ever used from OUTSIDE the dll? if it's only for internal use (IE, within the DLL) then that is probably ok.

I will try to stuff about with the wx widgets header files to get their macro to declare the class as DLLEXPORT and see if that stops the compiler warnings.

rickg22: What do you want me to upload?

rickg22 · « **Reply #35 on:** June 19, 2005, 07:21:13 am »

CrazyAbbot: Actually just the info about the warnings, but it seems you just listed it here.

The macros declare arrays, so i don't think it'll be a problem. They're data-only classes and they're MSVC-safe.

Anyway I modified the latest CVS with some of your dllimport modifications.

Hey, I have an idea that Yiannis might like. In the stdafx.h we could check for NULL and define it as 0L depending on the configuration, if it's not set.

NOTE:
Regarding my installation of the platform SDK, it seems i'm the first to experience an awful error with windows installer 3.1v2. No matter what package i'm installing, it aborts unexpectedly. It could be something in my config, or it could be one of the infamous "updates". Until Microsoft fixes this issue (i submitted an automated report), I'm afraid I won't be able to install the platform SDK nor try to compile codeblocks by myself. Sorry, you're on your own for now

tiwag · « **Reply #36 on:** June 19, 2005, 09:37:19 am »

Quote from: rickg22

... I modified the latest CVS ...

Would it be possible to create and maintain a web-log where one can read about the latest cvs-changes ?

or is it possible to automatically create a log of all check-in comments of all newly modified files ?

@rick: what kind of help do you need regarding MSVC ?

mandrav · « **Reply #37 on:** June 19, 2005, 09:44:58 am »

Quote from: CrazyAbbot

so MSVC wants this class to be declared as DLLEXPORT. however it seems to be working fine without it. is class Configurations ever used from OUTSIDE the dll? if it's only for internal use (IE, within the DLL) then that is probably ok.

Try replacing

Code: [Select]

WX_DECLARE_OBJARRAY(ConfigurationPath, Configurations) with

Code: [Select]

WX_DECLARE_USER_EXPORTED_OBJARRAY(ConfigurationPath, Configurations, DLLIMPORT) and see if it works.

Yiannis.

CrazyAbbot · « **Reply #38 on:** June 19, 2005, 10:17:17 am »

rickg22: What are you talking about with the null macro? every compiler i've seen defines it, its in the standard library.

mandrav:
That fixed it

Would you mind if I went through the source code and fixed just about all the warnings that MSVC is generating? and put a few pragmas in to turn off the size_t cast warnings?

It shouldn't cause the GCC compile to break, and I can always test it and fix that.

mandrav · « **Reply #39 on:** June 19, 2005, 11:59:24 am »

Quote from: CrazyAbbot

Would you mind if I went through the source code and fixed just about all the warnings that MSVC is generating? and put a few pragmas in to turn off the size_t cast warnings?

It shouldn't cause the GCC compile to break, and I can always test it and fix that.

Patches are always welcome

Just make sure you work on recent CVS.

Yiannis.

rickg22 · « **Reply #40 on:** June 20, 2005, 03:31:43 am »

CrazyAbbot: I'm talking about the NULL macro because many pointer to integer conversion warnings are caused by the 0L (instead of null) present in many functions. (Right Yiannis?).

Anyway, all changes you make should be posted in the "patch requests" at sourceforge (it's right after 'RFE')

tiwag: Just testing MSVC builds and possible bugs / misconfigurations. Making a tutorial on "compiling codeblocks and wxwidgets with MSVC" wouldn't be bad, either

rickg22 · « **Reply #41 on:** June 21, 2005, 05:49:31 am »

I just reinstalled windows on my machine and fixed the registry with some tool.

Still doesn't work. So VC++ is now officially not-supported-by-me.

CrazyAbbot · « **Reply #42 on:** June 21, 2005, 06:37:04 am »

I can probably do it,
It's more or less working now, there is just a few dll export issues to clean up

News:

Author Topic: building CodeBlocks with M$ VC++ Toolkit 2003 (Read 28035 times)