VOGONS


First post, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

This question has come up in the past, but I can't find an easy solution. Thanks to advice from Dominus, I was able to build a static-linked DOSBox with screenshot support under OS X, and now I'd like to try doing the same thing with my Win32-based project, which I'm building under Visual C++ 2010 Express.

I downloaded libpng 1.6.5 and zlib 1.2.5 (which is the version that libpng 1.6.5 seems to expect - I haven't figured out how to change 1.2.5 to 1.2.8 in the libpng VC project), and easily built zlib.lib and libpng16.lib, which end up in this directory:

\path\to\my\project\lpng165\projects\vstudio\Release Library

and .obj and other files here:

D:\Development\DOSBoxSVN-unpatched\lpng165\projects\vstudio\libpng\Release Library

In my DOSBox VisualC++ project properties, I added the first path to the top of the Additional Library Directories (under Linker/General) and the second path to the top of Additional Include Directories (under C++/General). In config.h, I defined C_CSSHOT 1.

When I tried to build, I got these errors at the end:

1>hardware.obj : error LNK2019: unresolved external symbol _deflateInit_@16 referenced in function "public: bool __thiscall VideoCodec::SetupCompress(int,int)" (?SetupCompress@VideoCodec@@QAE_NHH@Z)
1>hardware.obj : error LNK2019: unresolved external symbol _inflateInit_@12 referenced in function "public: bool __thiscall VideoCodec::SetupDecompress(int,int)" (?SetupDecompress@VideoCodec@@QAE_NHH@Z)
1>hardware.obj : error LNK2019: unresolved external symbol _deflateReset@4 referenced in function "public: bool __thiscall VideoCodec::PrepareCompressFrame(int,enum zmbv_format_t,char *,void *,int)" (?PrepareCompressFrame@VideoCodec@@QAE_NHW4zmbv_format_t@@PADPAXH@Z)
1>libpng.lib(pngwutil.obj) : error LNK2001: unresolved external symbol _deflateReset@4
1>hardware.obj : error LNK2019: unresolved external symbol _deflate@8 referenced in function "public: int __thiscall VideoCodec::FinishCompressFrame(void)" (?FinishCompressFrame@VideoCodec@@QAEHXZ)
1>libpng.lib(pngwrite.obj) : error LNK2001: unresolved external symbol _deflate@8
1>libpng.lib(pngwutil.obj) : error LNK2001: unresolved external symbol _deflate@8
1>hardware.obj : error LNK2019: unresolved external symbol _inflate@8 referenced in function "public: bool __thiscall VideoCodec::DecompressFrame(void *,int)" (?DecompressFrame@VideoCodec@@QAE_NPAXH@Z)
1>hardware.obj : error LNK2019: unresolved external symbol _inflateReset@4 referenced in function "public: bool __thiscall VideoCodec::DecompressFrame(void *,int)" (?DecompressFrame@VideoCodec@@QAE_NPAXH@Z)
1>libpng.lib(png.obj) : error LNK2001: unresolved external symbol _inflateReset@4
1>libpng.lib(pngwrite.obj) : error LNK2019: unresolved external symbol _deflateEnd@4 referenced in function _png_write_destroy
1>libpng.lib(png.obj) : error LNK2019: unresolved external symbol _crc32@12 referenced in function _png_reset_crc
1>libpng.lib(pngwutil.obj) : error LNK2019: unresolved external symbol _deflateInit2_@32 referenced in function _png_write_IHDR
1>.\Release/dosbox.exe : fatal error LNK1120: 9 unresolved externals

I have no idea of what to do about this, though I see that a similar question came up on the forum about seven years ago, apparently with no clear resolution.

I will be very grateful for any help in sorting this out. Many thanks.

Reply 1 of 5, by bloodbat

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
I downloaded libpng 1.6.5 and zlib 1.2.5 (which is the version that libpng 1.6.5 seems to expect - I haven't figured out how to […]
Show full quote

I downloaded libpng 1.6.5 and zlib 1.2.5 (which is the version that libpng 1.6.5 seems to expect - I haven't figured out how to change 1.2.5 to 1.2.8 in the libpng VC project), and easily built zlib.lib and libpng16.lib, which end up in this directory:

\path\to\my\project\lpng165\projects\vstudio\Release Library

and .obj and other files here:

D:\Development\DOSBoxSVN-unpatched\lpng165\projects\vstudio\libpng\Release Library

In my DOSBox VisualC++ project properties, I added the first path to the top of the Additional Library Directories (under Linker/General) and the second path to the top of Additional Include Directories (under C++/General). In config.h, I defined C_CSSHOT 1.
[...]

For libpng just point your additional libraries and include directories to wherever you compiled the new zlib, and add it to additional dependencies (linker -> input), which could be the problem when compiling DosBox, as it is a linker error; also, make sure everything is compiled using the SAME library (i.e Multi-Threaded /MT if you don't want people having to download and install msvcrt prior to using your build)

Reply 2 of 5, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

*I* would actually go the mungw/msys route and forget about VC. At least that's what I used when I was still on Windows five years ago. Except for some differences you will then use the same way to build dosbox on both systems. But I have no further advice on this anymore (except if you use mingw/msys never mixmatch libs compiled with different gcc versions) forgot most of how to use it 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 3 of 5, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
bloodbat wrote:

For libpng just point your additional libraries and include directories to wherever you compiled the new zlib, and add it to additional dependencies (linker -> input), which could be the problem when compiling DosBox, as it is a linker error; also, make sure everything is compiled using the SAME library (i.e Multi-Threaded /MT if you don't want people having to download and install msvcrt prior to using your build)

I know that Dominus's advice is the right way to go in the long term, but meanwhile, bloodbat's advice seems to have been exactly what I needed. (I'm not quite ready to set up everything under MinGW and compile all the libraries, etc. - but I'll get to it before too long, I hope.)

I'm not sure I completely understood the advice, but this is what I did (omitting a few hours wasted on mistakes), and I ended up with a build that successfully made a screenshot, which is exactly what I was hoping for.

If any of this was wrong, please let me know. I'm writing it all down partly to remind myself of what I did, so I'll be able to reproduce it when I try to do the same thing with my custom project, and also because it might be useful to someone else.

1. I went back and rebuilt libpng165 after changing the properties so that under C++/Additional Include Directories, I included ..\zlib-1.2.5, and under Librarian/Additional Library Directories, I also included ..\zlib-1.2.5. I made sure that I was using MultiThreaded /MT.

As I mentioned above, this built libpng in ..\lpng165\projects\vstudio\libpng\Release Library

2. Then I went back to the DOSBox project, and changed the properties so that under C++/Additional Include Directories, I included ..\lpng165\projects\vstudio\libpng\Release Library, and added the same directory under Librarian/Additional Library Directories.

I found that I was building DOSBox (in this testing project) for DLL, not MultiThreaded /MT, so I fixed that and tried building.

3. A flood of error messages showed me that I had to list MSVCRT under Linker/Input/Ignore Specific Default Libraries.

4. Finally, because bloodbat mentioned it, and I had stupidly left it out earlier, I went to Linker/Input/Additional Dependencies, and put libpng16.lib at the top of the list.

5. I built with no errors and the usual warnings, plus this message, which I had never seen before:

 libpng16.lib(pngwrite.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance

So, after some googling, I figured out that in the DOSBox properties, I needed to go to Linker/Optimization/Link Time Code Generation, and set it to "Link Time Code Generation /LTCG" - and that removed the message.

If any of this is (1) wrong, (2) stupid, or (3) merely unnecessary, I hope someone will let me know. Again, a thousand thanks for sorting this out for me. I could never even have got started without your help.

Reply 4 of 5, by bloodbat

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:

I know that Dominus's advice is the right way to go in the long term, but meanwhile, bloodbat's advice seems to have been exactly what I needed. (I'm not quite ready to set up everything under MinGW and compile all the libraries, etc. - but I'll get to it before too long, I hope.)

While I have a mingw setup, I still prefer Visual C++ for several reasons, including (at least in my tests) speed of the compiled product.

emendelson wrote:
I'm not sure I completely understood the advice, but this is what I did (omitting a few hours wasted on mistakes), and I ended u […]
Show full quote

I'm not sure I completely understood the advice, but this is what I did (omitting a few hours wasted on mistakes), and I ended up with a build that successfully made a screenshot, which is exactly what I was hoping for.

If any of this was wrong, please let me know. I'm writing it all down partly to remind myself of what I did, so I'll be able to reproduce it when I try to do the same thing with my custom project, and also because it might be useful to someone else.

1. I went back and rebuilt libpng165 after changing the properties so that under C++/Additional Include Directories, I included ..\zlib-1.2.5, and under Librarian/Additional Library Directories, I also included ..\zlib-1.2.5. I made sure that I was using MultiThreaded /MT.

As I mentioned above, this built libpng in ..\lpng165\projects\vstudio\libpng\Release Library

2. Then I went back to the DOSBox project, and changed the properties so that under C++/Additional Include Directories, I included ..\lpng165\projects\vstudio\libpng\Release Library, and added the same directory under Librarian/Additional Library Directories.

I found that I was building DOSBox (in this testing project) for DLL, not MultiThreaded /MT, so I fixed that and tried building.

3. A flood of error messages showed me that I had to list MSVCRT under Linker/Input/Ignore Specific Default Libraries.

4. Finally, because bloodbat mentioned it, and I had stupidly left it out earlier, I went to Linker/Input/Additional Dependencies, and put libpng16.lib at the top of the list.

5. I built with no errors and the usual warnings, plus this message, which I had never seen before:

 libpng16.lib(pngwrite.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance

So, after some googling, I figured out that in the DOSBox properties, I needed to go to Linker/Optimization/Link Time Code Generation, and set it to "Link Time Code Generation /LTCG" - and that removed the message.

If any of this is (1) wrong, (2) stupid, or (3) merely unnecessary, I hope someone will let me know. Again, a thousand thanks for sorting this out for me. I could never even have got started without your help.

You're welcome, I'm glad it worked for you. I see nothing wrong in my quasi-zombie state; libpng16 must be compiling with /LTCG by default, link time code generation you probably want anyway, so it's good you enabled it.

Reply 5 of 5, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I've now gone on to try to add the screenshot to my custom project, which (I now remember) is based on dbDOS (www.dbdos.com for source code), which is a modification of Megabuild, complete with parallel port support. After continued work, I'm still getting linker errors, and I'll probably come back and ask for advice, though this question is so specialized that maybe the forum isn't the place to ask it.