Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

building CodeBlocks with M$ VC++ Toolkit 2003

<< < (6/9) > >>

rickg22:
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:
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'

--- End quote ---


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:
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:
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:
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: ---class DLLIMPORT MyHtmlWin : public wxHtmlWindow
--- End code ---


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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page