MUSHclient : General : Compiling mushclient from source.

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
General
Compiling mushclient from source.

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Compiling mushclient from source.
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	Message to be posted (in English, please) Maximum of 6000 characters. Text only please, no HTML.
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3 4

Posted by

Fiendish USA (848 posts)

bio Global Moderator

Date

Sun 05 Jun 2011 10:52 PM (UTC) [ quote ]

Message

It looks like it is actually possible to build MFC with express editions with a few steps. See here:
http://www.codeproject.com/KB/MFC/MFCinVisualStudioExpress.aspx

And if you already have MFC includes and libraries, like from VC6, you can use those instead of dealing with the DDK section and it works better.

Quote:
If you have a VC++ 6 installed, you can use that instead of the DDK.

Follow the instructions in the article, but where it tells you to add the "$(DDK_directory)\inc\mfc42" directory, use the "C:\Program Files\Microsoft Visual Studio\VC98\MFC\Include" folder instead. Same goes for the other include and lib directories (e.g., "C:\Program Files\Microsoft Visual Studio\VC98\MFC\Lib" for the lib).

You do not need to install the DDK. Also you can build and run in debug mode, when you have the original VC++ 6 installed.

http://aardwolfclientpackage.googlecode.com/

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Thu 07 Jan 2010 08:01 PM (UTC) [ quote ]

Message

Twisol said:

Ah... yes, I did. Recompiling in Release mode fixes the memory issues. I sure feel stupid now.

It's not your fault their debug version works so badly. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by Nick Gammon Australia (18,769 posts) bio Forum Administrator

Date Thu 07 Jan 2010 08:00 PM (UTC) [ quote ]

Message

Twisol said:

Since MUSHclient uses a different version of zlib now, Nick, would you be able to update your zlib.zip download?

The zlib files are the same as downloaded from:

http://www.zlib.net/

(version 1.2.3)

Except that at the start of zconf.h change:


#ifndef ZCONF_H
#define ZCONF_H

to:


#ifndef ZCONF_H
#define ZCONF_H

#undef ZLIB_DLL      // NJG

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,229 posts)

Date

Thu 07 Jan 2010 07:03 PM (UTC) [ quote ]

Message

Ah... yes, I did. Recompiling in Release mode fixes the memory issues. I sure feel stupid now.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Thu 07 Jan 2010 06:57 PM (UTC) [ quote ]

Message

Did you make a Debug executable? They tend to be memory hogs.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,229 posts)

Date

Thu 07 Jan 2010 06:21 PM (UTC) [ quote ]

Message

This is really odd. First, please note that I commented out all of my changes to make sure they weren't causing this (and double-checked with WinMerge diffs). Every time the mouse moves, clicks, whatever, while within the output area, MUSHclient.exe's memory usage goes up about 4K in the Task Manager and doesn't come back down. Even stranger is that I left the .exe with my changes running overnight, and when I woke up, MUSHclient had almost 50% of my RAM. When I closed MUSHclient (not end task, just normally), it didn't leave the Task Manager; it sat there eating up more and more memory, on its own.

I can't reproduce this with the official 4.45 executable, and since I did disable my changes while testing, I was basically compiling it as it was. I suppose it must be the compilation process and/or the newer version of MFC, rather than any changes I introduced to the source...

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Twisol USA (2,229 posts)

Date

Thu 07 Jan 2010 08:41 AM (UTC) [ quote ]

Message

Okay, all fixed by using the new project file, and downloading zlib 1.2.3. Since MUSHclient uses a different version of zlib now, Nick, would you be able to update your zlib.zip download?

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by Twisol USA (2,229 posts) bio

Date

Thu 07 Jan 2010 08:10 AM (UTC) [ quote ]

Amended on Thu 07 Jan 2010 08:26 AM (UTC) by Twisol

Message

Removing the /Fr flag cleared up the second error, but I am boggled by the first. If I go to where it says the error occured, and artificially #define LINK_SIZE 2 right before it's checked, a whole bunch of other undeclared identifiers crop up in the pcre files.

Some more sleuthing reveals that the pcre files don't seem to be #include'ing config.h, which predefines LINK_SIZE and the other identifiers mentioned. Apparently it's only included if HAVE_CONFIG_H is defined... clearly, you have this define set in stdafx.h, but testing shows that it's not defined when the pcre files need it.

Adding a compiler flag /D "HAVE_CONFIG_H" seems to expose the symbol properly to the pcre files. The only remaining issue is that pcre_ucp_searchfuncs.c doesn't include config.h, but it does include pcre_internal.h (which is where the LINK_SIZE error originates). I patched in an #include to config.h in it, but it leaves a bad taste to be editing an external library when it's supposed to compile fine...

... and of course, that's not the end of the errors.

Error	308	error LNK2019: unresolved external symbol __pcre_ucd_stage2 referenced in function _match	pcre_exec.obj
Error	311	error LNK2019: unresolved external symbol __pcre_ucd_stage1 referenced in function _match	pcre_exec.obj
Error	305	error LNK2019: unresolved external symbol __pcre_ucd_records referenced in function _match	pcre_exec.obj
Error	307	error LNK2001: unresolved external symbol __pcre_ucd_stage2	pcre_compile.obj
Error	309	error LNK2001: unresolved external symbol __pcre_ucd_stage2	pcre_xclass.obj
Error	310	error LNK2001: unresolved external symbol __pcre_ucd_stage1	pcre_compile.obj
Error	312	error LNK2001: unresolved external symbol __pcre_ucd_stage1	pcre_xclass.obj
Error	304	error LNK2001: unresolved external symbol __pcre_ucd_records	pcre_compile.obj
Error	306	error LNK2001: unresolved external symbol __pcre_ucd_records	pcre_xclass.obj

What in the world changed to cause this much damage to the compilation process? I don't remember dealing with this the first time I compiled MUSHclient; these are totally new problems.

EDIT: Hang on, feel free to disregard this post for the moment... I realized I was using my outdated project file instead of the new one that came with the source. Trying to get past the zlib undefined externals again at the moment.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by Twisol USA (2,229 posts) bio

Date

Thu 07 Jan 2010 06:41 AM (UTC) [ quote ]

Amended on Thu 07 Jan 2010 07:21 AM (UTC) by Twisol

Message

Under the latest version of the source released (v4.45), I am getting this error 16 times, stating that LINK_SIZE must be 2, 3, or 4. I can't find any references to LINK_SIZE at all in the project source, nor in the project file.

mushclient\pcre_internal.h(368) : fatal error C1189: #error :  LINK_SIZE must be either 2, 3, or 4

I also get this error from the make process:

BSCMAKE: error BK1506 : cannot open file '.\WinDebug\ActivityDoc.sbr': No such file or directory

I'm not sure what to make of either error.

EDIT: It seems that the second error only comes up in debug mode, and apparently .sbr files contain debug info... All of the non-MUSHclient sources (png, sqlite, md5, etc) create them properly, but the build aborts once it tries to build ActivityDoc's .sbr file.

EDIT 2: If I toggle the switch from /Fr to /FR (noting, by the way, that the former is deprecated in VS2005), it gets much further... then has the same error, but on shs.sbr instead.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Kobold (5 posts)

Date

Fri 13 Nov 2009 09:47 AM (UTC) [ quote ]

Amended on Fri 13 Nov 2009 09:48 AM (UTC) by Kobold

Message

For anyone compiling it under VS 2008 or anything that likes to add UAC manifests to the resultant binaries, be sure to take off that option in the Project Configuration. Manifest resource == No compatibility VirtualStore created for MUSHClient == Epic MUSHClient fail (when placed in Program Files).

Posted by

Gwen (2 posts)

Date

Sun 01 Nov 2009 08:49 PM (UTC) [ quote ]

Message

I see. It is running now. Thanks. :)

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sun 01 Nov 2009 01:54 AM (UTC) [ quote ]

Message

See my post on page 1 of this thread, where I say "In order to *run* it you need a couple of other files ...".

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sun 01 Nov 2009 01:49 AM (UTC) [ quote ]

Message

The locale directory is part of the standard MUSHclient distribution. It changes infrequently, so a copy from any recent download would do. Basically it has the resource file in it (which has dialog boxes, menus, etc.).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Gwen (2 posts)

Date

Sun 01 Nov 2009 01:06 AM (UTC) [ quote ]

Message

Hello.

I've gotten MUSHclient to compile and link successfully, but I can't run it. I've read this thread and I need the locale directory. The problem is I don't seem to have that directory.

Posted by Twisol USA (2,229 posts) bio

Date

Tue 28 Jul 2009 07:34 AM (UTC) [ quote ]

Amended on Tue 28 Jul 2009 07:39 AM (UTC) by Twisol

Message

Wow - it works! :D Here's what I did, apart from errors and things you already mentioned, to get it to work:

* Install DirectX SDK (used March 2009 version)
** Add DirectX paths to Visual Studio's directories lists
* Add build options: /D "LUA51" /D "_CRT_SECURE_NO_WARNINGS"
* Add custom build option: /D "_USING_MFC8" -- see error in forcelib.h.

Here's the list of errors I had to change if you want to merge them with the current code.


==configuration.cpp==
-Line 80, missing return value.
    Add 'void' to function header.

==Utilities.cpp==
-Line 1202, redefinition of default second parameter (bSigned) in IsStringNumber.
    Remove '=false' from the function header

==methods.cpp==
-Line 12054, undeclared identifier DSBCAPS_CTRLDEFAULT.
    This flag is no longer supported directly.
    Replace with (DSBCAPS_CTRLPAN | DSBCAPS_CTRLVOLUME | DSBCAPS_CTRLFREQUENCY).

==MUSHclient.cpp==
-Linker error with lua5.1.dll
    Comment out the #pragma comment(linker, *) directive.

==forcelib.h==
-Linker error with mfc42d.lib
    VS2005 uses a newer version of MFC.
    Add an #ifdef branch controlled by _USING_MFC8 (custom identifier):

#ifndef _AFXDLL // this was already here
  // stuff you already have goes here
#else // this was already here
	#ifdef _USING_MFC8
		#ifndef _UNICODE
			#ifdef _DEBUG
				#pragma comment(lib, "mfc80d.lib")
				#pragma comment(lib, "mfcs80d.lib")
			#else
				#pragma comment(lib, "mfc80.lib")
				#pragma comment(lib, "mfcs80.lib")
			#endif
		#else
			#ifdef _DEBUG
				#pragma comment(lib, "mfc80ud.lib")
				#pragma comment(lib, "mfcs80ud.lib")
			#else
				#pragma comment(lib, "mfc80u.lib")
				#pragma comment(lib, "mfcs80u.lib")
			#endif
		#endif
	#else
	  // stuff you already have goes here
	#endif
#endif // this was already here

There's also a whole load of warnings that I'm clearing up, mostly type conversions, but they don't really affect the build.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

18,035 views.

This is page 3, subject is 4 pages long: 1 2 3 4

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )