Trunk discussion / complains

fixed

I canā€™t link Filestream.cpp. The line

fill_fopen64_filefunc(&MinizipFilefunc);

Seem to use function from other project minizip.

However, when I add MINIZIP_EXPORT to fill_fopen64_filefunc definition, I get crash at launch - no such procedure found in minizip.dll.

How is that supposed to be linked together?

Look like fill_fopen64_filefunc should have also ā€œexternā€ modifier. (No idea how it work in my case.)

Didnā€™t work :frowning:

Also, why do we use 64-bit (?) function in first place when thereā€™s alternative? VCMI is 32-bit application.

64bit zip is nothing about 64bit OS. Actually minizip will use ā€œ64bitā€ functions internally anyway.

Then do hardcore :slight_smile: Just copy ioapi functions from ioapi.c to FileStream.cpp. FileIO will be rewritten in MapFormat branch anyway.

Warmonger, lets make develop branch history linear. Please do not merge upstream develop to your local develop use pull fast-forward only or rebase local changes.

What about merging develop into branches?

Tried Ivanā€™s serialization branch:

Error	2	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector	2144
Error	3	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	4	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	5	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	6	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	7	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	8	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	9	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	10	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611

Not very informative. Hereā€™s compilation log:

pastebin.com/hSRE1vVG

This is different question.(Also, I do not care about branches.) As for me I rebase small and my own branches and merge large long-term branches and branches with more than one contributor.

I recently tried to compile VCMI via MinGW/CMake and encountered this error:

  1%] Built target minizip
  1%] Building CXX object lib/CMakeFiles/vcmi.dir/filesystem/FileStream.cpp.obj

D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp: In function 'void* fopen64_file_func(voidpf, const void*, int)':
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp:22:58: error: 'fopen64' was not declared in this scope
 #define FOPEN_FUNC(filename, mode) fopen64(filename, mode)
                                                          ^
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp: In function 'fpos_t ftell64_file_func(voidpf, voidpf)':
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp:23:44: error: 'ftello64' was not declared in this scope
 #define FTELLO_FUNC(stream) ftello64(stream)
                                            ^
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp: In function 'long int fseek64_file_func(voidpf, voidpf, fpos_t, int)':
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp:24:76: error: 'fseeko64' was not declared in this scope
 #define FSEEKO_FUNC(stream, offset, origin) fseeko64(stream, offset, origin)
                                                                            ^
lib\CMakeFiles\vcmi.dir\build.make:357: recipe for target 'lib/CMakeFiles/vcmi.dir/filesystem/FileStream.cpp.obj' failed
mingw32-make[2]: *** [lib/CMakeFiles/vcmi.dir/filesystem/FileStream.cpp.obj] Error 1
CMakeFiles\Makefile2:139: recipe for target 'lib/CMakeFiles/vcmi.dir/all' failed
mingw32-make[1]: *** [lib/CMakeFiles/vcmi.dir/all] Error 2
Makefile:148: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

Is there a way to fix it?

I think update MinGW is the only solution. What is your versions of MinGW itself and gcc?

Iā€™m currently using gcc 5.1.0, but if there is newer version Iā€™ll certainly update it, thanks.
BTW, I didnā€™t install Qt5 package, which is needed just by launcher (if Iā€™m not mistaken), and version 5.1.0 of gcc seems to be still the latest one for windows.

gcc 5.1.0 is more than enough, but what is ā€œversion of MinGW itselfā€?

Also try add

#define __USE_MINGW_ANSI_STDIO 0

before

#include <cstdio>

In FileStream.cpp

Hmm, honestly I donā€™t know how to figure it out :blush:. Iā€™m using TDM-GCC package, which has required toolchain included. For now I managed to get version of mingw32-make, which is 3.82.90; in other hand headers and libraries are from version 3.20.

Im using [MinGW-w64](https://sourceforge.net/projects/mingw-w64/), never tried TDM. May be its a TDM bug.

Ok, seems like it works now :slight_smile: with your package, many thanks.

Anyway, please report this in tracker. We should support TDM too.

If that wasnā€™t done before Iā€™m think itā€™s worth to block force push for develop branch:
github.com/blog/2051-protected- ā€¦ tus-checks

We never had problem with that before, but I think itā€™s would be handy to make it impossible to damage develop accidentally. Important for me since Iā€™m sometimes force push to my branches and each time itā€™s give me similar feeling like using ā€œrm -rfā€ do. :-/