Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Development
➜ Compiling mushclient from source.
|
Compiling mushclient from source.
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
3
4
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #45 on Thu 07 Jan 2010 08:10 AM (UTC) 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 | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #46 on Thu 07 Jan 2010 08:41 AM (UTC) |
| 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 | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #47 on Thu 07 Jan 2010 06:21 PM (UTC) |
| 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #48 on Thu 07 Jan 2010 06:57 PM (UTC) |
| Message
| | Did you make a Debug executable? They tend to be memory hogs. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #49 on Thu 07 Jan 2010 07:03 PM (UTC) |
| 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #50 on Thu 07 Jan 2010 08:00 PM (UTC) |
| 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 | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #51 on Thu 07 Jan 2010 08:01 PM (UTC) |
| 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 | | Top |
|
| Posted by
| Fiendish
USA (2,555 posts) Bio
Global Moderator |
| Date
| Reply #52 on Sun 05 Jun 2011 10:52 PM (UTC) |
| 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. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
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.
205,959 views.
This is page 4, subject is 4 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
3
4
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top