Is the Visual Studio build guide outdated?

killall -9

Moderator: Developers

Post Reply
User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Is the Visual Studio build guide outdated?

#1

Post by Asriel » Sat Oct 20, 2018 3:36 am

Howdy!

Recently, I've been wanting to get a grasp of the Zandronum source code. I know that Zandronum has many lines of source code spread across many different files, so I understand that trying to comprehend it would be a very long task, especially since I have very little programming experience. In order to try to understand the Zandronum source code better, I decided loading it into an IDE would be very helpful (for debugging/breakpoints, looking up function and object definitions, etc). When following the instructions on the wiki, I came across a couple of obstacles.

Windows Platform SDK
The link provided on the wiki appears to be dead, implying that version 7.0 and earlier of the Windows SDK is no longer available to download. Someone told me they were able to build Zandronum with a more modern version of the Windows SDK; implying that the old version of the Windows SDK linked to on the wiki is mainly for backwards compatibility with Windows XP and maybe even older. Since I personally don't need Zandronum to be backwards compatible, I'm assuming this information is mostly relevant to the developer who builds the official stable and test releases that get uploaded onto the website.

OpenGL Header Files
The wiki says to put the header files into the C:\Program Files\Microsoft SDKs\Windows\v6.1\includes\gl directory. Since I'm using a 64 bit version of Windows, I checked both the Program Files and Program Files (x86) directories, but the gl directory wasn't there. After searching around my hard drive (and a little help from Google), I found my gl directory in C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\um. Is this where I should put the OpenGL header files?
The Absolute GOD of Hyperdeath!

User avatar
Torr Samaho
Lead Developer
Posts: 1496
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

Re: Is the Visual Studio build guide outdated?

#2

Post by Torr Samaho » Sat Oct 20, 2018 1:00 pm

Asriel wrote:
Sat Oct 20, 2018 3:36 am
The link provided on the wiki appears to be dead, implying that version 7.0 and earlier of the Windows SDK is no longer available to download.
Just that the link is dead doesn't imply that the old SDK is not available for download anymore. Perhaps it is, but it's equally likely that the link just changed.
Asriel wrote:
Sat Oct 20, 2018 3:36 am
Someone told me they were able to build Zandronum with a more modern version of the Windows SDK; implying that the old version of the Windows SDK linked to on the wiki is mainly for backwards compatibility with Windows XP and maybe even older. Since I personally don't need Zandronum to be backwards compatible, I'm assuming this information is mostly relevant to the developer who builds the official stable and test releases that get uploaded onto the website.
I'm still using the old SDK, but newer versions may work. Feel free to try a newer version. If you encounter problems, please post them here. Then we can have a look at the problems together.
Asriel wrote:
Sat Oct 20, 2018 3:36 am
The wiki says to put the header files into the C:\Program Files\Microsoft SDKs\Windows\v6.1\includes\gl directory. Since I'm using a 64 bit version of Windows, I checked both the Program Files and Program Files (x86) directories, but the gl directory wasn't there. After searching around my hard drive (and a little help from Google), I found my gl directory in C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\um. Is this where I should put the OpenGL header files?
Possibly, depends on which SDK you are using. It shouldn't hurt to put the files there, as long as you don't overwrite anything. If it's not the correct folder for your setup, you'll get a missing include error.

jwaffe
Forum Regular
Posts: 217
Joined: Sun Jun 03, 2012 11:45 pm
Location: Just beyond the line horizon
Contact:

Re: Is the Visual Studio build guide outdated?

#3

Post by jwaffe » Sat Oct 20, 2018 4:25 pm

Oh hi Asriel, (him and I were talking about this in #support in the Zandronum discord early this month).

I misspoke the last time I was looking at this, I think I directed Asriel to use the solution file that comes from source control when really the wiki recommends using cmake to generate a new one (sorry about that). When I opened the cmake generated VS solution (and fixed a couple OpenSSL problems on my end) Zand compiled successfully with version 10.0.17763.0 of the Windows SDK.

From what I've read it seems like the Windows 10 SDK should support Windows 7 SP1 (which is what I'm using).
Supported operating systems
Windows 10 App Development (UWP)
Windows 10 version 1507 or higher: Home, Professional, Education, and Enterprise (LTSB and S are not supported)
Windows Server 2012 R2 (Command line only) Windows Server 2016 (Command Line only)
Win32 Development
Windows 10 version 1507 or higher
Windows Server 2016: Standard and Datacenter
Windows 8.1
Windows Server 2012 R2
Windows 7 SP1
(Not all tools are supported on earlier operating systems)
I was able to compile and run Zandronum with 10.0.17763.0 with the windows SDK.

Old info: It looks like there's a bug in version 10.0.17134.0 of the Windows SDK that caused _get_pgmptr to not function properly, which causes zand to crash on startup
Spoiler: (Open)
Though when I start it, I get an access violation here.

It looks like _get_pgmptr is returning zero indicating success, but program has a value of "", I'm not sure why this is, tracing the call stack up Zand was started through WinMain so according to the docs it shouldn't do this. Do you guys know why this is happening?

Since I can run a prebuilt Zand 3.0 binary on Windows 7, _get_pgmptr shouldn't be something introduced with Windows 10. Though there may still be something weird going on because "Target Platform" in Project Properties -> General is stuck on "Windows 10".

I can reproduce this in a small test program

Code: Select all

#include <stdlib.h>

int main()
{
	char* test;
	errno_t errorNumber = _get_pgmptr(&test);

	return 0;
}
And also it looks like this is a known issue in Windows 10 at least,

https://developercommunity.visualstudio ... -in-w.html
Thanks for reporting this!

This will be fixed on a future windows update.
https://developercommunity.visualstudio ... -to-1.html
This is an regression that started in Windows 10 1803...
EDIT: Also, I wasn't able to find a way to select any version of the Windows SDK before 10 in Visual Studio 2017 (15.8.1), even though I have 7.1 installed. Also note that users that download Visual Studio 2017 will also usually get some 10.X version of the Windows SDK. I vaguely remember Visual Studio 2015 was able to select version 7.1 of the Windows SDK but I'm not able to test that at the moment.
Last edited by jwaffe on Sat Oct 20, 2018 6:58 pm, edited 6 times in total.
Image

User avatar
Sean
FNF Team
Posts: 878
Joined: Thu Jan 16, 2014 9:09 pm
Location: England
Clan Tag: [TSPG]
Contact:

Re: Is the Visual Studio build guide outdated?

#4

Post by Sean » Sat Oct 20, 2018 6:48 pm

Regarding the SDK, have you tried https://www.microsoft.com/en-gb/downloa ... px?id=8442? Seems to be the same thing.

Also you can just create the gl folder, I'll update the wiki to mention that now

Code: Select all

<Decay> csnxs try being less bitter and actually helpful to the community, thanks


User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#5

Post by Asriel » Sun Oct 21, 2018 3:28 am

Sean wrote:
Sat Oct 20, 2018 6:48 pm
Regarding the SDK, have you tried https://www.microsoft.com/en-gb/downloa ... px?id=8442? Seems to be the same thing.
I thought about it, but ultimately decided not to do it because the wiki said "7.0 or older" and that's technically newer. I should've at least tried, but it seems to build fine using 8.1 and newer except for the Zandronum project.

My best guess is that I probably don't have the OpenGL header files working right. Visual Studio seems to default to version 8.1 of the Windows SDK but I put the OpenGL header files in the folder for version 10.0.17134.0 of the Windows SDK. Maybe if I could change the Windows SDK version for the whole solution instead of for each individual project that could help.

If that doesn't work then maybe C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\um\gl isn't the correct folder? If I put the header files in a non-default folder, will I have to specify the directory in CMake?

Something I feel that I should mention is that I'm apparently building a 64-bit version of Zandronum. I noticed that official and development builds of 64-bit Zandronum for Windows don't exist. Can 64-bit Windows versions of Zandronum be built?
The Absolute GOD of Hyperdeath!

User avatar
Sean
FNF Team
Posts: 878
Joined: Thu Jan 16, 2014 9:09 pm
Location: England
Clan Tag: [TSPG]
Contact:

Re: Is the Visual Studio build guide outdated?

#6

Post by Sean » Sun Oct 21, 2018 1:47 pm

Just put your GL headers in the 8.1 SDK folders?
Also Zandronum doesn't officially support 64-bit, use 32-bit.

Code: Select all

<Decay> csnxs try being less bitter and actually helpful to the community, thanks


User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#7

Post by Asriel » Sun Oct 21, 2018 3:42 pm

Sean wrote:
Sun Oct 21, 2018 1:47 pm
Zandronum doesn't officially support 64-bit, use 32-bit.
Oh, well I downloaded the 64-bit versions of all the libraries. I'll download the 32-bit versions if I have to.

Edit:

This is something I should've done earlier, I've attached my build log to this post for your perusal.
Sean wrote:
Sun Oct 21, 2018 1:47 pm
Just put your GL headers in the 8.1 SDK folders?
That doesn't work apparently.
You do not have the required permissions to view the files attached to this post.
The Absolute GOD of Hyperdeath!

User avatar
Torr Samaho
Lead Developer
Posts: 1496
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

Re: Is the Visual Studio build guide outdated?

#8

Post by Torr Samaho » Sun Oct 21, 2018 7:25 pm

Asriel wrote:
Sun Oct 21, 2018 3:42 pm
This is something I should've done earlier, I've attached my build log to this post for your perusal.

Code: Select all

19>e:\archives\document archive\software projects\zandronum\src\gl\hqnx_asm\hq2x_asm.cpp(37): error C4235: nonstandard extension used: '__asm' keyword not supported on this architecture
The hqnx asm code doesn't work in x64, so you will not be able to build x64 binaries unless the code is adapted. Try to build 32bit binaries instead.

User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#9

Post by Asriel » Sun Oct 21, 2018 7:34 pm

Then isn't it odd that there is a 64-bit version of Zandronum for GNU/Linux? Learning x86 assembly has been on my backlog anyway, in the meantime I'll try to build a 32-bit version of Zandronum. Will I need 32-bit versions of the libraries (like FMOD)?
The Absolute GOD of Hyperdeath!

User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#10

Post by Asriel » Mon Oct 22, 2018 8:29 pm

So I downloaded 32-bit versions of all the libraries including python and built a 32-bit version of Zandronum. This would imply it is safe to have 32-bit and 64-bit versions of the libraries and Python coexisting on the same computer. It appears to have built successfully using version 8.1 of the Windows SDK. I've attached my build log for your perusal.

If I wanted to execute the version of Zandronum I built, can I use the debug/start without debugging options in Visual Studio or will I have to run the executable file directly?
You do not have the required permissions to view the files attached to this post.
The Absolute GOD of Hyperdeath!

User avatar
Sean
FNF Team
Posts: 878
Joined: Thu Jan 16, 2014 9:09 pm
Location: England
Clan Tag: [TSPG]
Contact:

Re: Is the Visual Studio build guide outdated?

#11

Post by Sean » Mon Oct 22, 2018 11:08 pm

Asriel wrote:
Mon Oct 22, 2018 8:29 pm
If I wanted to execute the version of Zandronum I built, can I use the debug/start without debugging options in Visual Studio or will I have to run the executable file directly?
It's basically the same thing, running from VS just automatically attaches the debugger.

Code: Select all

<Decay> csnxs try being less bitter and actually helpful to the community, thanks


User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#12

Post by Asriel » Tue Oct 23, 2018 2:58 am

When I debug Zandronum, I get a system error saying "the program can't start because LIBEAY32.dll is missing from your computer. Try reinstalling the program to fix this problem"
The Absolute GOD of Hyperdeath!

User avatar
Torr Samaho
Lead Developer
Posts: 1496
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

Re: Is the Visual Studio build guide outdated?

#13

Post by Torr Samaho » Tue Oct 23, 2018 6:07 am

Asriel wrote:
Sun Oct 21, 2018 7:34 pm
Then isn't it odd that there is a 64-bit version of Zandronum for GNU/Linux?
Only seemingly so. The Linux version (both 32-bit and 64-bit) simply doesn't use the hqnx asm code at all, since it only works in Win32. One could also exclude this code from the Win64 version to fix the compile problem you encountered, but I never did this since there is no real need for a Win64 version.
Asriel wrote:
Tue Oct 23, 2018 2:58 am
When I debug Zandronum, I get a system error saying "the program can't start because LIBEAY32.dll is missing from your computer. Try reinstalling the program to fix this problem"
Looks like you dynamically linked OpenSSL. In this case, you have to make sure that LIBEAY32.dll is in the search path or in the same directory as your binary.

User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#14

Post by Asriel » Wed Oct 24, 2018 2:39 am

When I tell CMake to use the libraries in the static folder, I get a build error (see attached build log). The ones I've noticed are from lines 762 to 880.

Code: Select all

19>libeay32MDd.lib(bn_rand.obj) : warning LNK4217: locally defined symbol __time32 imported in function _bnrand
19>libeay32MDd.lib(mem_dbg.obj) : warning LNK4049: locally defined symbol __time32 imported
19>libeay32MDd.lib(a_time.obj) : warning LNK4049: locally defined symbol __time32 imported
19>libeay32MDd.lib(x509_vfy.obj) : warning LNK4049: locally defined symbol __time32 imported
19>libeay32MDd.lib(bn_print.obj) : warning LNK4217: locally defined symbol _isdigit imported in function _BN_dec2bn
19>libeay32MDd.lib(b_print.obj) : warning LNK4049: locally defined symbol _isdigit imported
19>libeay32MDd.lib(obj_dat.obj) : warning LNK4049: locally defined symbol _isdigit imported
19>libeay32MDd.lib(x509_vfy.obj) : warning LNK4049: locally defined symbol _isdigit imported
19>libeay32MDd.lib(bn_print.obj) : warning LNK4217: locally defined symbol _isxdigit imported in function _BN_hex2bn
19>libeay32MDd.lib(ui_lib.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(v3_info.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(a_mbstr.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(v3_alt.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(v3_ncons.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(err.obj) : warning LNK4217: locally defined symbol _strchr imported in function _ERR_error_string_n
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(conf_mod.obj) : warning LNK4049: locally defined symbol _strchr imported
19>libeay32MDd.lib(err.obj) : warning LNK4217: locally defined symbol _strerror imported in function _build_SYS_str_reasons
19>libeay32MDd.lib(dso_win32.obj) : warning LNK4049: locally defined symbol _strncpy imported
19>libeay32MDd.lib(evp_key.obj) : warning LNK4049: locally defined symbol _strncpy imported
19>libeay32MDd.lib(err.obj) : warning LNK4217: locally defined symbol _strncpy imported in function _build_SYS_str_reasons
19>libeay32MDd.lib(v3_info.obj) : warning LNK4049: locally defined symbol _strncpy imported
19>libeay32MDd.lib(x509_obj.obj) : warning LNK4049: locally defined symbol _strncpy imported
19>libeay32MDd.lib(v3_alt.obj) : warning LNK4049: locally defined symbol _strncpy imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fclose imported in function _file_free
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4049: locally defined symbol _fclose imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _feof imported in function _file_ctrl
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4049: locally defined symbol _feof imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _ferror imported in function _file_read
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4049: locally defined symbol _ferror imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fflush imported in function _file_ctrl
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4049: locally defined symbol _fflush imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fgets imported in function _file_gets
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4049: locally defined symbol _fgets imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol __fileno imported in function _file_ctrl
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fopen imported in function _file_fopen
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4217: locally defined symbol _fopen imported in function _open_console
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fread imported in function _file_read
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fseek imported in function _file_ctrl
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _ftell imported in function _file_ctrl
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol _fwrite imported in function _file_write
19>libeay32MDd.lib(a_strex.obj) : warning LNK4217: locally defined symbol _fwrite imported in function _do_esc_char
19>libeay32MDd.lib(b_dump.obj) : warning LNK4049: locally defined symbol _fwrite imported
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol __wfopen imported in function _file_fopen
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol __errno imported in function _BIO_new_file
19>libeay32MDd.lib(bss_file.obj) : warning LNK4217: locally defined symbol __setmode imported in function _file_ctrl
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol __exit imported in function _OpenSSLDie
19>libeay32MDd.lib(conf_api.obj) : warning LNK4049: locally defined symbol _getenv imported
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol _getenv imported in function _OPENSSL_cpuid_setup
19>libeay32MDd.lib(eng_list.obj) : warning LNK4049: locally defined symbol _getenv imported
19>libeay32MDd.lib(conf_mod.obj) : warning LNK4049: locally defined symbol _getenv imported
19>libeay32MDd.lib(x509_vfy.obj) : warning LNK4049: locally defined symbol _getenv imported
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol _strtoul imported in function _OPENSSL_cpuid_setup
19>libeay32MDd.lib(a_strnid.obj) : warning LNK4049: locally defined symbol _strtoul imported
19>libeay32MDd.lib(ocsp_ht.obj) : warning LNK4049: locally defined symbol _strtoul imported
19>libeay32MDd.lib(asn1_gen.obj) : warning LNK4217: locally defined symbol _strtoul imported in function _asn1_str2tag
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol _wcsstr imported in function _OPENSSL_isservice
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol _sscanf imported in function _OPENSSL_cpuid_setup
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4217: locally defined symbol _sscanf imported in function _X509V3_get_value_bool
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol __vsnprintf imported in function _OPENSSL_showfatal
19>libeay32MDd.lib(cryptlib.obj) : warning LNK4217: locally defined symbol _raise imported in function _OpenSSLDie
19>libeay32MDd.lib(mem_dbg.obj) : warning LNK4217: locally defined symbol __localtime32 imported in function _localtime
19>libeay32MDd.lib(stack.obj) : warning LNK4217: locally defined symbol _qsort imported in function _internal_find
19>libeay32MDd.lib(o_names.obj) : warning LNK4217: locally defined symbol _qsort imported in function _OBJ_NAME_remove
19>libeay32MDd.lib(tasn_enc.obj) : warning LNK4049: locally defined symbol _qsort imported
19>libeay32MDd.lib(a_set.obj) : warning LNK4049: locally defined symbol _qsort imported
19>libeay32MDd.lib(eng_ctrl.obj) : warning LNK4217: locally defined symbol _strtol imported in function _ENGINE_ctrl_cmd_string
19>libeay32MDd.lib(tb_asnmth.obj) : warning LNK4217: locally defined symbol __strnicmp imported in function _ENGINE_get_pkey_asn1_meth_str
19>libeay32MDd.lib(ameth_lib.obj) : warning LNK4049: locally defined symbol __strnicmp imported
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4049: locally defined symbol __strnicmp imported
19>libeay32MDd.lib(v3_conf.obj) : warning LNK4049: locally defined symbol _isspace imported
19>libeay32MDd.lib(ocsp_ht.obj) : warning LNK4049: locally defined symbol _isspace imported
19>libeay32MDd.lib(asn_mime.obj) : warning LNK4049: locally defined symbol _isspace imported
19>libeay32MDd.lib(obj_dat.obj) : warning LNK4217: locally defined symbol _isspace imported in function _OBJ_create_objects
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4049: locally defined symbol _isspace imported
19>libeay32MDd.lib(conf_mod.obj) : warning LNK4049: locally defined symbol _isspace imported
19>libeay32MDd.lib(x_name.obj) : warning LNK4049: locally defined symbol _isspace imported
19>libeay32MDd.lib(obj_dat.obj) : warning LNK4217: locally defined symbol _isalnum imported in function _OBJ_create_objects
19>libeay32MDd.lib(rsa_pmeth.obj) : warning LNK4217: locally defined symbol _atoi imported in function _pkey_rsa_ctrl_str
19>libeay32MDd.lib(dh_pmeth.obj) : warning LNK4217: locally defined symbol _atoi imported in function _pkey_dh_derive
19>libeay32MDd.lib(dsa_pmeth.obj) : warning LNK4217: locally defined symbol _atoi imported in function _pkey_dsa_ctrl
19>libeay32MDd.lib(ec_pmeth.obj) : warning LNK4217: locally defined symbol _atoi imported in function _pkey_ec_ctrl_str
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4217: locally defined symbol _isupper imported in function _string_to_hex
19>libeay32MDd.lib(asn_mime.obj) : warning LNK4217: locally defined symbol _isupper imported in function _asn1_write_micalg
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4217: locally defined symbol _tolower imported in function _string_to_hex
19>libeay32MDd.lib(x_name.obj) : warning LNK4217: locally defined symbol _tolower imported in function _x509_name_ex_i2d
19>libeay32MDd.lib(asn_mime.obj) : warning LNK4049: locally defined symbol _tolower imported
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4217: locally defined symbol _memchr imported in function _X509_check_email
19>libeay32MDd.lib(ocsp_ht.obj) : warning LNK4049: locally defined symbol _memchr imported
19>libeay32MDd.lib(x509_vpm.obj) : warning LNK4217: locally defined symbol _memchr imported in function _X509_VERIFY_PARAM_set1_policies
19>libeay32MDd.lib(asn_mime.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(pem_lib.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(v3_pci.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(v3_ncons.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(v3_conf.obj) : warning LNK4217: locally defined symbol _strncmp imported in function _X509V3_EXT_add_nconf_sk
19>libeay32MDd.lib(asn1_gen.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(v3_utl.obj) : warning LNK4217: locally defined symbol _strncmp imported in function _name_cmp
19>libeay32MDd.lib(conf_mod.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(a_strnid.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(v3_crld.obj) : warning LNK4049: locally defined symbol _strncmp imported
19>libeay32MDd.lib(cfb64ede.obj) : warning LNK4217: locally defined symbol _memmove imported in function _DES_ede3_cfb_encrypt
19>libeay32MDd.lib(bio_b64.obj) : warning LNK4217: locally defined symbol _memmove imported in function _b64_free
19>libeay32MDd.lib(dh_key.obj) : warning LNK4217: locally defined symbol _memmove imported in function _DH_compute_key_padded
19>libeay32MDd.lib(e_des3.obj) : warning LNK4049: locally defined symbol _memmove imported
19>libeay32MDd.lib(bss_mem.obj) : warning LNK4049: locally defined symbol _memmove imported
19>libeay32MDd.lib(wrap128.obj) : warning LNK4049: locally defined symbol _memmove imported
19>libeay32MDd.lib(conf_mod.obj) : warning LNK4217: locally defined symbol _strrchr imported in function _module_find
19>libeay32MDd.lib(o_time.obj) : warning LNK4217: locally defined symbol __gmtime32_s imported in function _OPENSSL_gmtime
19>libeay32MDd.lib(dso_win32.obj) : warning LNK4217: locally defined symbol _sprintf imported in function _win32_name_converter
19>libeay32MDd.lib(dso_win32.obj) : warning LNK4217: locally defined symbol _strstr imported in function _win32_name_converter
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4217: locally defined symbol _signal imported in function _popsig
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4217: locally defined symbol _fprintf imported in function _read_string
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4217: locally defined symbol _fputs imported in function _read_string
19>libeay32MDd.lib(ui_openssl.obj) : warning LNK4217: locally defined symbol __getch imported in function _noecho_fgets
19>libeay32MDd.lib(cryptlib.obj) : error LNK2019: unresolved external symbol __imp____iob_func referenced in function _OPENSSL_stderr
19>libeay32MDd.lib(ui_openssl.obj) : error LNK2001: unresolved external symbol __imp____iob_func
19>E:\Archives\Document Archive\Software Projects\Zandronum Out\Debug\zandronum.exe : fatal error LNK1120: 1 unresolved externals
Am I linking against the wrong libraries?

My CMake OpenSSL paths are:

Code: Select all

LIB_EAY_DEBUG   E:/OpenSSL-Win32/lib/VC/static/libeay32MDd.lib
LIB_EAY_RELEASE E:/OpenSSL-Win32/lib/VC/static/libeay32MD.lib

SSL_EAY_DEBUG   E:/OpenSSL-Win32/lib/VC/static/ssleay32MDd.lib
SSL_EAY_RELEASE E:/OpenSSL-Win32/lib/VC/static/ssleay32MD.lib
Edit:
While this didn't fix my issue, I still think it's worth mentioning that I corrected a few mistakes I made when configuring the CMake file. These mistakes include:
  • Using the OpenSSL libraries in the VC directory instead of the parent lib directory specified on the wiki.
  • Forgetting to set the NASM path in the CMake GUI.
  • Using a 64-bit version of Python to build a 32-bit version of Zandronum.
I think I'll just copy and paste the DLL files into the Zandronum directory for now.
You do not have the required permissions to view the files attached to this post.
The Absolute GOD of Hyperdeath!

User avatar
Torr Samaho
Lead Developer
Posts: 1496
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

Re: Is the Visual Studio build guide outdated?

#15

Post by Torr Samaho » Sat Oct 27, 2018 10:50 am

Asriel wrote:
Wed Oct 24, 2018 2:39 am
Am I linking against the wrong libraries?
I think so. Are you using the precompiled ones? IIRC they are dynamic only.

If you want to statically link, you need to compile OpenSSL yourself:
https://wiki.zandronum.com/Compiling_Za ... ng_OpenSSL

This is what I do for the official binaries.

User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#16

Post by Asriel » Sun Oct 28, 2018 7:11 am

When I copied libeay32.dll from the bin folder into the debug folder where zandronum.exe is, and ran Zandronum by doing debug->start debugging, I got the error:

"The application was unable to start correctly (0xc000007b). Click OK to close the application."

On an unrelated note, as cool as learning 64-bit x86 is, would it be more practical if the assembly code was ported to a high level language? While I'm personally more familiar with C, porting it to C++ appears to be more consistent with the rest of the code-base.
The Absolute GOD of Hyperdeath!

User avatar
Torr Samaho
Lead Developer
Posts: 1496
Joined: Fri May 25, 2012 6:03 pm
Location: Germany

Re: Is the Visual Studio build guide outdated?

#17

Post by Torr Samaho » Sun Oct 28, 2018 1:06 pm

Asriel wrote:
Sun Oct 28, 2018 7:11 am
When I copied libeay32.dll from the bin folder into the debug folder where zandronum.exe is, and ran Zandronum by doing debug->start debugging, I got the error:

"The application was unable to start correctly (0xc000007b). Click OK to close the application."
Likely, there is another DLL missing. Did you copy all OpenSSL dlls into the folder?
Asriel wrote:
Sun Oct 28, 2018 7:11 am
On an unrelated note, as cool as learning 64-bit x86 is, would it be more practical if the assembly code was ported to a high level language? While I'm personally more familiar with C, porting it to C++ appears to be more consistent with the rest of the code-base.
There already is a C++ version of this code. The assembler version is just faster, that why it's the default. Our version of the build mechanism is simply missing the proper handling for x64 under Windows. As far as I can tell, the advantages of Win64 over Win32 for Zandronum are negligible. That's why I never spent time on this. What do you hope to gain from Win64 over Win32 for Zandronum?

User avatar
Asriel
 
Posts: 35
Joined: Sun Nov 26, 2017 8:10 pm
Clan Tag: *GOD* & [RG]

Re: Is the Visual Studio build guide outdated?

#18

Post by Asriel » Mon Oct 29, 2018 8:24 am

Torr Samaho wrote:
Sun Oct 28, 2018 1:06 pm
Likely, there is another DLL missing. Did you copy all OpenSSL dlls into the folder?
Apparently I didn't. After copying all of the DLLs from the \bin directory into the \debug directory Zandronum works fine now. Thank you!
Torr Samaho wrote:
Sun Oct 28, 2018 1:06 pm
There already is a C++ version of this code. The assembler version is just faster, that why it's the default. Our version of the build mechanism is simply missing the proper handling for x64 under Windows. As far as I can tell, the advantages of Win64 over Win32 for Zandronum are negligible. That's why I never spent time on this. What do you hope to gain from Win64 over Win32 for Zandronum?
I just thought that an x64 or C/C++ port would've been useful depending on if performance or portability was more important respectively. I appreciate you taking the time to clear this up for me. I guess this is more of an experimental thing that I should do on my own.

Hopefully when I get a better grasp of the code-base I could do something more useful.
The Absolute GOD of Hyperdeath!

User avatar
Sean
FNF Team
Posts: 878
Joined: Thu Jan 16, 2014 9:09 pm
Location: England
Clan Tag: [TSPG]
Contact:

Re: Is the Visual Studio build guide outdated?

#19

Post by Sean » Wed Oct 31, 2018 9:21 pm

This reminds me, I should probably remove the VS 2005 part of the build guide, given that Zandronum needs C++11 nowdays...

Code: Select all

<Decay> csnxs try being less bitter and actually helpful to the community, thanks


Post Reply