scottpetrovic wrote:Does boost say it compiled correctly? It should generate that DLL when it is done. It either didn't compile correctly, or it is in a different folder.

Not sure. Command

Code: Select all

cmake --build . --config RelWithDebInfo --target ext_boost

fails with following output:

Code: Select all

[... skipped ten thousands lines ...]

  boost\tr1\tr1\tuple
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\typeinfo
  boost\tr1\tr1\typeinfo
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\type_traits
  boost\tr1\tr1\type_traits
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\unordered_map
  boost\tr1\tr1\unordered_map
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\unordered_set
  boost\tr1\tr1\unordered_set
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\utility
  boost\tr1\tr1\utility
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\valarray
  boost\tr1\tr1\valarray
  Скопировано файлов:         1.
  common.copy \dev\i\include\boost-1_55\boost\tr1\tr1\vector
  boost\tr1\tr1\vector
  Скопировано файлов:         1.
  ...updated 10790 targets...
  No install step for 'ext_boost'
  Performing post_install step for 'ext_boost'
  Error copying file "/dev/i/lib/boost_system-vc-mt-1_55.dll" to "/dev/i/lib/boost_system-vc140-mt-1_55.dll".
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" завершилась с кодом 1. [C:\dev\b\ext_boost\ext_boost.vcxproj]
Сборка проекта "C:\dev\b\ext_boost\ext_boost.vcxproj" завершена (целевые объекты по умолчанию) с ошибкой.


Ошибка сборки.

"C:\dev\b\ext_boost\ext_boost.vcxproj" (целевой объект по умолчанию) (1) ->
(Целевой объект CustomBuild) ->
  C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" завершилась с кодом 1. [C:\dev\b\ext_boost\ext_boost.vcxproj]

    Предупреждений: 0
    Ошибок: 1

Затраченное время: 00:03:53.09


All *.dll files in C:\dev with 'boost' in path:

Code: Select all

find | grep 'dll$' | grep boost -i
./b/ext_boost/ext_boost-prefix/src/ext_boost/build-dir/boost/bin.v2/libs/system/build/msvc-11.0/release/address-model-64/architecture-x86/threading-multi/boost_system-vc110-mt-1_55.dll
./b/ext_boost/ext_boost-prefix/src/ext_boost/libs/filesystem/test/msvc10/exec_monitor_dll
./b/ext_boost/ext_boost-prefix/src/ext_boost/libs/filesystem/test/msvc10/filesystem_dll
./b/ext_boost/ext_boost-prefix/src/ext_boost/libs/filesystem/test/msvc10/system_dll
./b/ext_boost/ext_boost-prefix/src/ext_boost/libs/timer/test/msvc10/chrono_dll
./b/ext_boost/ext_boost-prefix/src/ext_boost/libs/timer/test/msvc10/system_dll
./b/ext_boost/ext_boost-prefix/src/ext_boost/libs/timer/test/msvc10/timer_dll
./i/lib/boost_system-vc110-mt-1_55.dll


You can see the last line of your DLL list and see it there. The automatic copying isn't working for some reason, so you will have to manually duplicate the file and rename it like it says in the error output. The DLLs are the same file, just have different file names.

dobrokotov wrote:I think, that changing line ending for all text files trigger a lot of other unexpected problems for large codebase, better too keep source files identical byte-to-byte. Otherwise build under windows will give different binary files, even when build is platform independent (for example, when packing text files from source to final build resources ).

It seems less dangerous to create wrapper for patch tool or update patch tool ( http://files.kde.org/krita/build/depend ... -7-bin.zip ) itself to take any line endings when such option is given.

Trust me, that config is exactly there to avoid problems between devs that commit from different platforms, it should be the norm; the point of autocrlf is to change line endings only locally, and then commit with whatever line endings there are on git, so no one get their line endings mixed.
Also i don't see how it could give issues since it's a local change and Windows is supposed to work with CRLF line endings and not with LF. And also for the binary difference.. different from what?
All Windows devs should use it, if they all use it, provided that they have the same identical Window setup, the binaries will be identical.
Even for the example of text files you do, if the application is not cross-platform (as in support CRLF on Windows and LF on Linux) that's an application issue that has to be solved.

I can invest some time to fix build errors, which are not known for Krita developers, and specific for my environment. I known, large C++ codebases are very sensitive to little environment differences, and it's hard to debug build on another's computer.

But I don't want to waste time on build problems, which can be fixed in repository with simple known fix, or have known workarounds. Even if workaround is very simple ("dude, just skip this library" or "comment out this line in CMakeLists.txt") - it can take a lot of time to derive it out, when it is unknown.
Thanks to guruguru for concrete steps to solve build problem with crashed "patch" ( "So I had to convert linebreaks for these .patch and .diff files manually" )

Let me create digest of my compilation problems:

Crashed patch: - solved with locally modified files, thanks to guruguru for exact solution help (I had replaced UNIX eols to Windows EOL with sed script,
find ./ -name '*.patch' -or -name '*.diff' | xargs sed -i 's/\([^\r]\|\)$/\1\r/'
)

Boost: update: boost build fixed, see next discussion, thanks to Stefano Bonicatti for invalid compiler version detection hint.
Command: cmake --build . --config RelWithDebInfo --target ext_boost
Error message: Error copying file "/dev/i/lib/boost_system-vc-mt-1_55.dll" to "/dev/i/lib/boost_system-vc140-mt-1_55.dll".
There are only boost_system-vc110-mt-1_55.dll and boost_system-vc110-mt-1_55.dll files in c:\dev\i\lib
More diagnostic - viewtopic.php?f=139&t=131607&sid=c4174f8876953802968056e84969e484#p353476

Libraries ext_lcms2, ext_libraw, ext_openjpeg, similar link errors:
update: there is existing C:\soft\py27\Library\lib\tiff.lib , and CMake generates project files with link to this library. After I had deleted the offending python Lib folder and regenerate project files, build of these dependencies had been successful.

C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\bin\RelWithDebInfo\tificc.exe : fatal error LNK1120: 5 unresolved externals [C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\utils\tificc.vcxproj] [C:\dev\b\ext_lcms2\ext_lcms2.vcxpro
tiff.lib(snprintf.obj) : error LNK2019: unresolved external symbol __imp__vscprintf referenced in function _TIFF_vsnprintf_f [C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\utils\tificc.vcxproj] [C:\dev\b\ext_lcms2\ext_lcms2.vcxproj]
tiff.lib(snprintf.obj) : error LNK2019: unresolved external symbol __imp__vsnprintf_s referenced in function _TIFF_vsnprintf_f [C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\utils\tificc.vcxproj] [C:\dev\b\ext_lcms2\ext_lcms2.vcxproj]
tiff.lib(tif_codec.obj) : error LNK2019: unresolved external symbol __imp_sprintf referenced in function _notConfigured [C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\utils\tificc.vcxproj] [C:\dev\b\ext_lcms2\ext_lcms2.vcxproj]
tiff.lib(tif_unix.obj) : error LNK2019: unresolved external symbol __imp___iob_func referenced in function unixWarningHandler [C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\utils\tificc.vcxproj] [C:\dev\b\ext_lcms2\ext_lcms2.vcxproj]
tiff.lib(tif_unix.obj) : error LNK2019: unresolved external symbol __imp_vfprintf referenced in function unixWarningHandler [C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\utils\tificc.vcxproj] [C:\dev\b\ext_lcms2\ext_lcms2.vcxproj]


cmake --build . --config RelWithDebInfo --target ext_kwindowsystem - lot of compilation errors:
https://paste.kde.org/pznssj3ho
update: seems to be fixed, I have QT headers in two places, inside python C:\soft\py27\Library\include\ and C:\Qt\5.6\msvc2015_64\include\ , I temporarily removed all Qt* (QtCore, QtGui, Qt, ...) folders from C:\soft\py27\Library\include\


Krita itself - seems now I can't check which Krita problems I have, because I don't have dependencies built. At current time Krita build errors are the following (I didn't expect succesfull build without dependencies, but maybe it failed earlier due other reasons):
https://paste.kde.org/p4bxkuw0l

Quoting myself here for boost:

Stefano Bonicatti wrote:For the issue with boost, i don't know, but it seems that it is detecting the compiler as if it was VS2010 instead of just leaving out the vc part (that is then corrected by our cmake script into vc140).
Anyway if the boost build fails at that step, you just need to manually copy the files and rename them as it's shown in the copy operation that fails.

As for the patches, we just need to change to Unix line endings and devs use autocrlf true, then it shouldn't be an issue anymore.

Try first to have boost correctly detected, otherwise you'll have weird errors later with other libs.

As for the patches, we just need to change to Unix line endings and devs use autocrlf true, then it shouldn't be an issue anymore.

Git is not the only way to transfer files between build environments. One filesystem can be mounted to different OS. It is exactly my case - NTFS filesystem in cygwin can be used both in "linux" or "windows" environment. And git thinks that environment is linux (with linux EOL), but I want to make Windows build. You can also think of example "get repository on Linux machine and copy (rsync) it to Windows machine due security/technical problems". Or "tarball with sources". All this can be solved or declared as "wrong workflow", but it's better not to create problems, than to solve/arguing is workflow wrong or not.

Different source files will give another source of unexpected surprises, to make build dependent on git config. Yes, we can say "different line endings should not cause problems", but it will. And it is not always clear for large codebase, "text" file or binary. Is zipped text section in PNG-file icon binary or text? Why hash-sum and size of png icon should be different on different systems after build? Reversed example: If png file is under version control - can git change EOL inside text sections of this PNG file? Different source on different machines gives subtle problems.

For the issue with boost, i don't know, but it seems that it is detecting the compiler as if it was VS2010 instead of just leaving out the vc part (that is then corrected by our cmake script into vc140).

Try first to have boost correctly detected, otherwise you'll have weird errors later with other libs.

Thanks, this note about 110/140vc++ detection will definitely help if I or someone else will investigate problem of this part of build. Still, this does not give exact steps how to fix makefiles, just gives hint where start to go (which is very valuable too)

Anyway if the boost build fails at that step, you just need to manually copy the files and rename them as it's shown in the copy operation that fails.

Thanks for this too, I'll try this when I build all other Krita dependencies, and done Krita compilation step, and start to link Krita executable.
I can't check for now, can this help or not, because I can't move forward to Krita compilation while other build problems present.
It is impossible to check renaming libraries solution, until I approach Krita final executable linking.

dobrokotov wrote:Thanks for this too, I'll try this when I build all other Krita dependencies, and done Krita compilation step, and start to link Krita executable.
I can't check for now, can this help or not, because I can't move forward to Krita compilation while other build problems present.
It is impossible to check renaming libraries solution, until I approach Krita final executable linking.

Keep in mind that the instructions written in the README are to follow in order, so you got to do the boost step before doing the others.
You get an error while trying to copy "/dev/i/lib/boost_system-vc-mt-1_55.dll" to "/dev/i/lib/boost_system-vc140-mt-1_55.dll", you just need to take your version of boost .dll inside the lib folder and copy it with the name boost_system-vc140-mt-1_55.dll.

I have two Visual Studio installed. Environment variables are quite clean, and do not mix paths/common variable names, but have both VS110COMNTOOLS and VS140COMNTOOLS variables being set.

And despite explicitly called C:\soft\msvc14\VC\bin\amd64\vcvars64.bat , boost compilation script ( C:\dev\b\ext_boost\ext_boost-prefix\src\ext_boost\tools\build\v2\engine\build.bat ) doesn't check version set from vcvars64, instead it uses first found globally defined VS110COMNTOOLS.

Code: Select all

if NOT "_%VS110COMNTOOLS%_" == "__" (
    set "BOOST_JAM_TOOLSET=vc11"

Seems, boost developers are responsible to detect proper toolset, when both are installed or when toolset has been changed, but only one is set as current by vcvars64/vcvars32. Maybe it can be overwritten and fixed on Krita side, with explicit boost toolset selection, to avoid additional lines in build README.

I have removed VS110COMNTOOLS from system environment variables editor (simple unsetting the variable "set VS110COMNTOOLS=" from console didn't help), so ext_boost dependency build was finished as successful.

Thanks for Stefano Bonicatti, due your advice I managed to find source of the problem much faster.
Other problems are still present.

Ok, let's try to do with something with QT compilation errors.

Seems, I have two QT, and both are in compiler include paths.
First one:
C:\soft\py27\Library\include\QtCore - ( my system python installed from https://www.continuum.io/downloads )
Second one:
C:\Qt\5.6\msvc2015_64\include\QtCore

During compilation I have mishmash of headers from both installations, and this gives unpredictable compiler errors.
What is proper way to avoid both QT in one project? Modification of system python, to delete QT from system python, seems weird, but I can try.

Visual C++ Compiler command line during build:

Code: Select all

C:\soft\msvc14\VC\bin\x86_amd64\CL.exe
/c
/I"C:\dev\b\ext_frameworks\ext_karchive-prefix\src\ext_karchive-build\src"
/I"C:\dev\b\ext_frameworks\ext_karchive-prefix\src\ext_karchive\src"
/IC:\dev\i\include
/IC:\soft\py27\Library\include
/IC:\Qt\5.6\msvc2015_64\include
/IC:\Qt\5.6\msvc2015_64\include\QtCore
/I"C:\Qt\5.6\msvc2015_64\.\mkspecs\win32-msvc2015"
/Zi /nologo /W3 /WX- /O2 /Ob1
/D WIN32
/D _WINDOWS
/D NDEBUG
/D WIN32_LEAN_AND_MEAN
/D _WIN32_WINNT=0x0600
/D WINVER=0x0600
/D _WIN32_IE=0x0600
/D UNICODE
/D _UNICODE
/D _USE_MATH_DEFINES
/D _CRT_SECURE_NO_DEPRECATE
/D _CRT_SECURE_NO_WARNINGS
/D _CRT_NONSTDC_NO_DEPRECATE
/D _SCL_SECURE_NO_WARNINGS
/D QT_NO_CAST_TO_ASCII
/D QT_NO_CAST_FROM_ASCII
/D QT_NO_URL_CAST_FROM_STRING
/D QT_NO_CAST_FROM_BYTEARRAY
/D QT_NO_SIGNALS_SLOTS_KEYWORDS
/D QT_USE_FAST_OPERATOR_PLUS
/D QT_USE_QSTRINGBUILDER
/D QT_CORE_LIB
/D QT_NO_DEBUG
/D "CMAKE_INTDIR=\"RelWithDebInfo\""
/D KF5Archive_EXPORTS
/D _WINDLL
/D _UNICODE
/D UNICODE
/Gm- /EHsc /MD /GS
/fp:precise
/Zc:wchar_t /Zc:forScope /Zc:inline
/GR
/Fo"KF5Archive.dir\RelWithDebInfo\\"
/Gd /TP
/wd4250 /wd4251 /wd4396 /wd4661
"C:\dev\b\ext_frameworks\ext_karchive-prefix\src\ext_karchive\src\karchive.cpp"


Cause of link errors with image libraries is existing C:\soft\py27\Library\lib\tiff.lib , and CMake generates project files with path to this library.
I have removed files with path to python tiff.lib, removed C:\soft\py27\Library\lib, and have regenerated project files. After this dependencies have been built.

Seems, ext_openjpeg, ext_lcms2 and ext_libraw build were finished as successfull.
Still, when I start to build Krita, I got message

The following OPTIONAL packages could NOT be located on your system Consider installing them to enable more features from this software.
* openjpeg <http://www.openjpeg.org>

Code: Select all

 C:\soft\msvc14\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\dev\b\ext_lcms2\ext_lcms2-prefix\src\ext_lcms2-build\bin\RelWithDebInfo\tificc.exe" /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib ..\src\RelWithDebInfo\lcms2.lib C:\soft\py27\Library\lib\tiff.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:/dev/b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/bin/RelWithDebInfo/tificc.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/dev/b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/utils/RelWithDebInfo/tificc.lib" /MACHINE:X64 /PROFILE tificc.dir\RelWithDebInfo\tificc.obj
./b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/CMakeCache.txt:TIFF_LIBRARY_RELEASE:FILEPATH=C:/soft/py27/Library/lib/tiff.lib
./b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_TIFF:INTERNAL=[C:/soft/py27/Library/lib/tiff.lib][C:/soft/py27/Library/include][v4.0.6()]
./b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/utils/tificc.vcxproj:      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;..\src\Debug\lcms2.lib;C:\soft\py27\Library\lib\tiff.lib</AdditionalDependencies>
./b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/utils/tificc.vcxproj:      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;..\src\Release\lcms2.lib;C:\soft\py27\Library\lib\tiff.lib</AdditionalDependencies>
./b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/utils/tificc.vcxproj:      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;..\src\MinSizeRel\lcms2.lib;C:\soft\py27\Library\lib\tiff.lib</AdditionalDependencies>
./b/ext_lcms2/ext_lcms2-prefix/src/ext_lcms2-build/utils/tificc.vcxproj:      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;..\src\RelWithDebInfo\lcms2.lib;C:\soft\py27\Library\lib\tiff.lib</AdditionalDependencies>


And this is my 100-th post on this forum.

It works! It works! http://dobrokot.ru/pics/i2016-03-21__04-01-11_268kb.png
Thanks all for help.

Congrats