So, the build process for PythonQt is sort of a black box to me. I've tried to understand it, but there is so much going on here that I've sort of resigned myself to just being happy that my debug build works. However, today that has changed, as I need a release build, and I'm getting an error:
LNK2038mismatchdetectedfor'RuntimeLibrary': value'MD_DynamicRelease'doesn't match value 'MDd_DynamicDebug' in com_trolltech_qt_core_builtin0.obj PythonQt-Qt5-Python38 C:\...\PythonQt\src\PythonQtQFileImporter.obj
The error speaks for itself, but for I can't for the life of me figure out why it's happening. From what I can tell, com_trolltech_qt_core_builtin0.obj is generated by the release build, so I have no idea how or why this would get generated with a different runtime library than the main project. I know that 'MD_DynamicRelease' is the correct one since this is the release build, but I'm not sure where to start investigating how to rectify this mismatch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that maybe, even in release mode, the MDd_DynamicDebug runtime library is being used in stead of MD_DynamicRelease for PythonQt. This doesn't make any sense to me. I've dug through the project settings PythonQt.pro and src.pro, and everything looks fine. All of the settings in my MSVC solution also look fine. The static library itself builds fine for the project PythonQt-Qt5-PythonXY, and is is using the /MD flag. This is just very strange.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Florian, glad to hear from you! Unfortunate that you haven't run into this issue.
I actually hadn't made any modifications to the MSVC solution before things stopped working. I just have been building in debug for the past few months, and finally made the leap to compile a release version of the DLLs.
I'm about 80% convinced that this is a very strange problem with MOC. I'm using QT 5.12, and I'm not sure if there are any oddities that have been introduced.
Which leads me to the question, is it possible to build PythonQt without using MOC on the generated header files? The custom build step is what seems to be contentious.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the moc required and it only generates addition cpp files that are
compiled like the rest of the files. Hm, I would try to setup my
installation anew, remove all tmp files, recreated vcxproj and so on, like
you start on a clean machine.
Hi Florian, glad to hear from you! Unfortunate that you haven't run into
this issue.
I actually hadn't made any modifications to the MSVC solution before
things stopped working. I just have been building in debug for the past few
months, and finally made the leap to compile a release version of the DLLs.
I'm about 80% convinced that this is a very strange problem with MOC. I'm
using QT 5.12, and I'm not sure if there are any oddities that have been
introduced.
Which leads me to the question, is it possible to build PythonQt without
using MOC on the generated header files? The custom build step is what
seems to be contentious.
Maybe qmake does not generate correct release vcxproj files for you. You
could try to change the pro file to build release only. Google the qmake
docs how to configure release only in a pro file. (It was like this years
ago, but nowadays I thought release and debug vcxproj settings would be ok).
Yes, the moc required and it only generates addition cpp files that are
compiled like the rest of the files. Hm, I would try to setup my
installation anew, remove all tmp files, recreated vcxproj and so on, like
you start on a clean machine.
Hi Florian, glad to hear from you! Unfortunate that you haven't run into
this issue.
I actually hadn't made any modifications to the MSVC solution before
things stopped working. I just have been building in debug for the past
few
months, and finally made the leap to compile a release version of the
DLLs.
I'm about 80% convinced that this is a very strange problem with MOC. I'm
using QT 5.12, and I'm not sure if there are any oddities that have been
introduced.
Which leads me to the question, is it possible to build PythonQt without
using MOC on the generated header files? The custom build step is what
seems to be contentious.
Unfortunately, I tried all of that, and still no luck. I've even gone as far as to pull PythonQt's source directly into my own project, and I'm STILL getting the error in release build:
ErrorLNK2038mismatchdetectedfor'_ITERATOR_DEBUG_LEVEL': value'0'doesn't match value '2' in com_trolltech_qt_core_builtin0.obj grand_blue C:\Users\dante\Documents\Projects\grand-blue-engine\grand_blue\PhysXCommon_static_32.lib(GuFeatureCode.obj) 1 ErrorLNK2038mismatchdetectedfor'RuntimeLibrary': value'MD_DynamicRelease'doesn't match value 'MDd_DynamicDebug' in com_trolltech_qt_core_builtin0.obj grand_blue C:\Users\dante\Documents\Projects\grand-blue-engine\grand_blue\PhysXCommon_static_32.lib(GuDistanceSegmentTriangle.obj) 1
I'm only using PythonQt to wrap up my own custom classes for use in Python, so I'm wondering if it's feasible to just skip the loading of QtCore and QtGui altogether, and just use the features of PythonQt that wrap my own custom classes. Is this something that you think would be feasible? My last resort is to try to remove the calls
Got it, thanks again Florian. Turns out, I had introduced a stray _DEBUG definition in PythonQtPythonInclude, which was ruining everything. So as I'd suspected all along, it was my fault. I'd added that line a year ago to test something and had forgotten about it.
As to why I hadn't caught it when I reinstalled PythonQt, it turns out git also wasn't tracking my changes properly, so things didn't actually get overwritten when I pulled from the repo. An unfortunate comedy of errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey folks,
So, the build process for PythonQt is sort of a black box to me. I've tried to understand it, but there is so much going on here that I've sort of resigned myself to just being happy that my debug build works. However, today that has changed, as I need a release build, and I'm getting an error:
The error speaks for itself, but for I can't for the life of me figure out why it's happening. From what I can tell, com_trolltech_qt_core_builtin0.obj is generated by the release build, so I have no idea how or why this would get generated with a different runtime library than the main project. I know that 'MD_DynamicRelease' is the correct one since this is the release build, but I'm not sure where to start investigating how to rectify this mismatch.
Man, tough audience, huh?
Update: Still no luck. I did make another post with more info here: https://github.com/MeVisLab/pythonqt/issues/11
It seems that maybe, even in release mode, the MDd_DynamicDebug runtime library is being used in stead of MD_DynamicRelease for PythonQt. This doesn't make any sense to me. I've dug through the project settings PythonQt.pro and src.pro, and everything looks fine. All of the settings in my MSVC solution also look fine. The static library itself builds fine for the project PythonQt-Qt5-PythonXY, and is is using the /MD flag. This is just very strange.
@florianlink, are you okay? You are my shining light.
I mean I never had that problem before and have no idea why it happens for
you. What was your last change before it stopped working?
On Thu 11. Jun 2020 at 21:04, Flower lady fancyflowerlady@users.sourceforge.net wrote:
Sorry but I really don’t know.
On Thu 11. Jun 2020 at 21:04, Flower lady fancyflowerlady@users.sourceforge.net wrote:
Hi Florian, glad to hear from you! Unfortunate that you haven't run into this issue.
I actually hadn't made any modifications to the MSVC solution before things stopped working. I just have been building in debug for the past few months, and finally made the leap to compile a release version of the DLLs.
I'm about 80% convinced that this is a very strange problem with MOC. I'm using QT 5.12, and I'm not sure if there are any oddities that have been introduced.
Which leads me to the question, is it possible to build PythonQt without using MOC on the generated header files? The custom build step is what seems to be contentious.
Yes, the moc required and it only generates addition cpp files that are
compiled like the rest of the files. Hm, I would try to setup my
installation anew, remove all tmp files, recreated vcxproj and so on, like
you start on a clean machine.
On Thu 11. Jun 2020 at 22:55, Flower lady fancyflowerlady@users.sourceforge.net wrote:
Maybe qmake does not generate correct release vcxproj files for you. You
could try to change the pro file to build release only. Google the qmake
docs how to configure release only in a pro file. (It was like this years
ago, but nowadays I thought release and debug vcxproj settings would be ok).
On Fri 12. Jun 2020 at 08:56, Florian Link florianlink@users.sourceforge.net wrote:
Hi Florian,
Unfortunately, I tried all of that, and still no luck. I've even gone as far as to pull PythonQt's source directly into my own project, and I'm STILL getting the error in release build:
I'm only using PythonQt to wrap up my own custom classes for use in Python, so I'm wondering if it's feasible to just skip the loading of QtCore and QtGui altogether, and just use the features of PythonQt that wrap my own custom classes. Is this something that you think would be feasible? My last resort is to try to remove the calls
And all related hooks, since that seems to be the contentious part of the code.
Got it, thanks again Florian. Turns out, I had introduced a stray
_DEBUGdefinition in PythonQtPythonInclude, which was ruining everything. So as I'd suspected all along, it was my fault. I'd added that line a year ago to test something and had forgotten about it.As to why I hadn't caught it when I reinstalled PythonQt, it turns out git also wasn't tracking my changes properly, so things didn't actually get overwritten when I pulled from the repo. An unfortunate comedy of errors.