(Bug): CMake debug build fails at linking.

[Al3145]

Make sure to follow our issue report guidelines

• [X] I'm using the latest version of Natron (not required but recommended)
• [X] I've restarted Natron and the issue persists
• [ ] I've run Natron via the command line and the issue persists
• [X] I've followed the contributing guidelines to the best of my understanding
• [X] My issue is not on the issue tracker or in a pull request already (go search for it and dig around a little bit!)
• [X] This bug is reproducible

Natron version

Natron 2.5

Operating system

Windows 10

System specs

Ram: 64 Gigs CPU: Ryzen 5600x GPU: EVGA RTX2060

Did you install Natron using the official installer?

• [ ] Yes, I used the official installer
• [ ] No, I installed from a binary archive
• [X] No, I compiled Natron from sources
• [ ] No, I installed Natron via another method

Custom installation path

/home/Username/src/Natron/

What were you trying to do?

I was trying to compile Natron using CMake Ninja workflow (cmake -DCMAKE_BUILD_TYPE=Debug ..) from a created build folder in Natron's repo folder, and the shiboken blender libraries evaluates to "Not Found".

Build fails after Ninja command in the folder due to linking errors because of apparent missing Qt dependencies (if I'm understanding correctly).

What did you expect to happen? What happened instead?

I expected the debug build to succeed.

Step-by-step reproduction instructions

1. Git pull Natron recursive (git clone --recursive https://github.com/NatronGitHub/Natron.git). After installing dependencies through msys2 man -S mingw-w64-x86_64-natron-build-deps-qt5, as laid out in comment here
2. install cmake and ninja through pacman, cd to repo and mkdir Build && cd Build
3. use command cmake -DCMAKE_BUILD_TYPE=debug .. after which you should get this output

-- SHIBOKEN_PYTHON_LIBRARIES computed to value: 'PYTHON_DEBUG_LIBRARY-NOTFOUND'
-- libshiboken built for Release
-- Configuring done (0.4s)
-- Generating done (0.2s)

4. ninja command fails with linking errors.

Error output:

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
cannot find -lPYTHON_DEBUG_LIBRARY-NOTFOUND: No such file or directory
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Additional details

Release build type works just fine according to the build process.

I tried to debug the cmake issue but it's a bit too complicated as I don't fully understand how Shiboken is being used.

[Al3145]

This may have to do with CMake new versions. Will install old version and test.

[acolwell]

This has been a long standing issue that I have not been able to figure out yet. I believe it has to do with debug versions of the python libraries not being available in MSYS2. It has been a while since I have looked into this so my memory might be rusty, but I believe there is some sort of issue with the python headers in debug builds that make it unsafe to just use the release python libraries. I don't believe this is a problem with Shiboken specifically. I think it has more to do with linking release python into a binary compiled with debug flags.

Based on your change in #972, qmake seems to be able to get a debug Natron to link but it isn't clear to me if qmake and my minimal testing of the resulting build are actually correct. We might just not be hitting the issue that cmake is trying to protect us from.

[Al3145]

Thank you. I think you are right about that in addition it may be because of some faulty cmake instruction leading to the libraries not being generated properly because it was in fact triggering some cmake policy error/warning (not sure which). Has to do with deprecating some commands that were in the file mentioned below.

After some digging I found the error being somewhere in the cmake helpers file for shiboken and python using an older expression to add the python executable to the path, iirc. I am not entirely sure about it as that was a week ago and my memory is hazy but I know how to go about finding it again. I'll log it here for posterity once I have another build going as I had to format my machine.

I think there's a good chance we can stabilize the building process once we pinpoint the exact issue here. That'll go a long way towards cleaning up everything.

[acolwell]

I've figured out a fix for the Windows debug cmake build. I'll send out a pull request for it soon. There were basically 3 issues that needed to be resolved.

• Force Shiboken to use the release python library
• Force -O option to be specified for debug builds to prevent long link times and missing Eigen symbols errors. This is present in the qmake builds and I'm assuming that is what is allowing them to work as well.
• Remove the NDEBUG define that the Shiboken cmake helper was unconditionally defining for ALL build types. This was preventing asserts() from behaving properly in debug builds.

[Al3145]

This is great work! I'll make sure to go the changes to fully understand what was going wrong. Thank you for the update!!

[acolwell]

Fixed.