Hi,
I have spent XMas trying to get CC running on My Windows 10 PC, but have run into a snag. The process is like this:
1. Open CloudCompare in VC++ 2017.
2. Add Mingw64-Debug target and set it. Mingw64 installed with Msys64. Qt5.14 installed in C: All files found in CMake.
2. From CMake menu I choose generate and all CMake build files are generated from the top CMakeList.txt file. All fine. No errors.
3. Check all the build files and all look good.
4. Buld CCCoreLib and it runs fine. .dll & dll.a files + .obj files are good.
5. Build QCC_DB_LIB target fails. Source code compilation gives a coupe of warnings for QFontMetrics.h but should not be fatal.
The issue is when it tries to create the libs. [71/71] cmd.exe /C "cd . && C:\msys64\mingw64\bin\g++.exe -fopenmp -g -shared -o libs\qCC_db\libQCC_DB_LIBd.dll -Wl,--out-implib,libs\qCC_db\libQCC_DB_LIBd.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libs/qCC_db/CMakeFiles/QCC_DB_LIB.dir/src/cc2DLabel.cpp.obj libs/qCC_db/CMakeFiles/QCC_DB_LIB.dir/src/cc2DViewportLabel.cpp.obj libs/qCC_db/CMakeFiles/QCC_DB_LIB.dir/src/cc2DViewportObject.cpp.obj ...(long list of obj files)............... libs/qCC_db/CMakeFiles/QCC_DB_LIB.dir/QCC_DB_LIB_autogen/mocs_compilation.cpp.obj libs/qCC_db/extern/CCCoreLib/libCCCoreLibd.dll.a libs/CCFbo/libCC_FBO_LIBd.dll.a C:/Qt/5.14.1/mingw73_64/lib/libQt5Concurrent.a C:/Qt/5.14.1/mingw73_64/lib/libQt5OpenGL.a C:/Qt/5.14.1/mingw73_64/lib/libQt5Widgets.a C:/Qt/5.14.1/mingw73_64/lib/libQt5OpenGLExtensions.a C:/Qt/5.14.1/mingw73_64/lib/libQt5Gui.a C:/Qt/5.14.1/mingw73_64/lib/libQt5Core.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
FAILED: libs/qCC_db/libQCC_DB_LIBd.dll libs/qCC_db/libQCC_DB_LIBd.dll.a
I have checked that all the libs are found & exsist. All good. The VC++ IDE list the stack which hold these messages;
cmd.exe /C "cd . (repeat of above) (below is the interesting subject)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libs/qCC_db/CMakeFiles/QCC_DB_LIB.dir/src/cc2DLabel.cpp.obj: in function `CCCoreLib::ScalarField::~ScalarField()':
C:/Users/oddva/Documents/Git/CloudCompare/libs/qCC_db/extern/CCCoreLib/include/ScalarField.h:87: undefined reference to `__imp__ZN9CCCoreLib11ScalarFieldD1Ev'
(repeat of same missing reference message X number of times)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\collect2.exe : error : ld returned 1 exit status.
There is a function missing in CCCoreLib and I think it is a missing flag in the CMake system. I can spens a long time on this but if I can get some help from someone that knows the codebase I will be happy.
Thank you in advance.
Build error Mingw64 on Windows.
Re: Build error Mingw64 on Windows.
Looks like I am answering myself yet again. This is an compiler optimalisation isseue I think. Why is this optimalisation issue turning up in a debug build? I am not a build expert and really would like some help. Link to a post that lead me to believe that this is a optimalisation issue. https://stackoverflow.com/questions/156 ... destructor
Re: Build error Mingw64 on Windows.
Ok. Got it fixed. Issue resolved by switching to Msvc2017 build environment. Mingw64 has issues and if someone can get back to me and check my stuff I can file a BUG report if needed.
Re: Build error Mingw64 on Windows.
mingw64 is definitely not the default compiler on Windows for this project. It is very seldom used. But I guess you can sill create a github 'issue' if anyone wants to try to make CC compile with it.
Daniel, CloudCompare admin
Re: Build error Mingw64 on Windows.
https://stackoverflow.com/questions/156 ... destructor
This is also useless when building shared libraries, since there's no way of knowing in advance which symbols will be used. The compiler is invoked with -fPIC, which should be ok, since the objects are simply being archived. The -fvisibility options might be complicating the issue, however.
cmake option
CCORELIB_SHARED uncheck, the msys2 mingw32 or mingw64 build will be ok.
This is also useless when building shared libraries, since there's no way of knowing in advance which symbols will be used. The compiler is invoked with -fPIC, which should be ok, since the objects are simply being archived. The -fvisibility options might be complicating the issue, however.
cmake option
CCORELIB_SHARED uncheck, the msys2 mingw32 or mingw64 build will be ok.