64Bit portierung bringt seltsame Lnk Meldung

Hallo zusammen,

Seit einem Jahr portiere ich rund eine Millionen handmaked Code nach 64 Bit
Da muss man schon Sagen das MS hier gute Arbeit geleistet hat um das überhaupt zu ermöglichen. Jedenfalls kommt bei einem Projekt im Release jedoch nicht im Debug Build folgende Meldung mit Lnk Abbruch:

Severity Code Description Project File Line Suppression State
Error LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in 3DMarker.obj Cam3DView (3D\Cam3DView\Cam3DView) Y:\InspectSystem\Cam3DView\OpenGL.lib(GLmatrix.obj) 1

Was soll das bedeuten, ich habe inzwischen alle möglichen Schalter umgelegt, es bleibt bei dieser Meldung nur im Release.
Vielen Dank für Hinweise
Grüße aus Berlin
K.s.

hustbaer

Naja der Wert von _ITERATOR_DEBUG_LEVEL bei den Object Files die du kompilierst passt nicht mit dem Wert von _ITERATOR_DEBUG_LEVEL zusammen mit dem OpenGL.lib kompiliert wurde. Du verwendest _ITERATOR_DEBUG_LEVEL=2 und OpenGL.lib verwendet _ITERATOR_DEBUG_LEVEL=0.

Und das geht halt nicht, weil verschiedene _ITERATOR_DEBUG_LEVEL Werte verschiedene Iterator-Implementierungen auswählen die unterschiedlich aussehen und daher nicht binary-kompatibel sind.

Findest du aber auch alles mit ca. 1 Sekunde Googeln selbst.

@hustbaer Bevor ich hier was reinschreibe, bin ich bereits in Not gekommen, nach dem ich gesucht habe. Wo wird dieser Schalter eingestellt ? Ich habe das niemals zuvor gesehen.
Das heißt nicht die Oberliegende Applikation hat das problem , sondern meine libs. Die werden separat anderswo kompiliert. Wo könnte ich denn bei den Libs diesen Schalter setzen ?

Danke für deine Antwort und Grüße aus Berlin
K.

mgaeckler

Was hat MS mit Deiner Konvertierung zu tun? Haben die 'Deinen 'Code entwickelt? Umstieg von 16 auf 32 Bit bei Windows war viel heftiger.

Ich meine mich erinnern zu können, daß Du Probleme bekommst, wenn Debug und Nicht-Debug-versionen gemischt werden.

Grüße aus dem schöneren Linz

Hallo HusteBär,

also nach deinem Hinweis habe ich einfach mal bei den defines geschaut, und tatsächlich war in der release Version im Projekt OpenGL das NDEBUG nicht gesetz sondern _DEBUG
lol , das steht natürlich nicht mal bei Google. Aber manchmal ist es entscheidend einfach mal einen anderen Hinweis nachzugehen als den eigenen, allerdings habe ich 184 Projekte in 6 Solutions. Danke also für deinen Hinweis!

Grüße aus Berlin.

@mgaeckler Die meisten Fehler sind offensichtlich, das man sie auch wahrnimmt hat mit dem Bewusstsein zu tun, das ist gelegentlich vernebelt vom grass.

Fehler
Als neuer Benutzer kannst du nur einen Beitrag innerhalb von 120 Sekunden erstellen bis dein Ansehen 3 erreicht hat - Bitte warte bevor du erneut einen Beitrag erstellst.
Mein Ansehen ist also schlecht, das sagen mir die Jungen Weiber auch immer das ich zu alt sei ^^

Ms hat damit viel zu tun, sie ermöglichen es erst mit VS. Es gibt keine andere Entwicklerumgebung mit diesem Potential der Hierarchie von Kits DLL's und Lib's das ganze Windows system sorgt sich durch seine Anordnung darum, das eine Portierung erst möglich ist. zb OpenGL32.dll und alle anderen namentlichen 32.dll's VFW32.dll und so weiter, man stelle sich vor die hießen plötzlich alle 64 Dann kannst Du einpacken.

hustbaer

@KahnSoft

Bevor ich hier was reinschreibe, bin ich bereits in Not gekommen, nach dem ich gesucht habe.

Ja, ich war mich nicht ganz sicher. So selten wie du hier fragst war meine erste Vermutung auch dass du erstmal ausführlich googelst. So direkt wie die guten Treffer aus Google rauspurzeln wenn man einfach nur nach _ITERATOR_DEBUG_LEVEL sucht konnte ich mir den Hinweis dann aber nicht verkneifen

Das heißt nicht die Oberliegende Applikation hat das problem , sondern meine libs. Die werden separat anderswo kompiliert. Wo könnte ich denn bei den Libs diesen Schalter setzen ?

Naja wer das Problem hat ist Definitionssache. _ITERATOR_DEBUG_LEVEL aktiviert halt ein Feature von der Visual Studio Standard Library, nämlich Iterator Debugging (2) bzw. Checked Iterators (1). Was die genau machen kannst du hier nachlesen wenns dich interessiert:
https://docs.microsoft.com/en-us/cpp/standard-library/checked-iterators?view=vs-2019
https://docs.microsoft.com/en-us/cpp/standard-library/debug-iterator-support?view=vs-2019

Default für Release ist 0, also nix. Default für Debug ist 2, also Iterator Debugging. Das geht aber natürlich ordentlich auf die Geschwindigkeit, weswegen es halt normal auch nur in Debug Builds aktiv ist. Und wenn man es anders möchte, dann muss man _ITERATOR_DEBUG_LEVEL selbst definieren.

also nach deinem Hinweis habe ich einfach mal bei den defines geschaut, und tatsächlich war in der release Version im Projekt OpenGL das NDEBUG nicht gesetz sondern _DEBUG

Das würde erklären wieso du _ITERATOR_DEBUG_LEVEL 2 bekommst
Ich schätze da muss bei der Projekt-Konvertierung irgendwas schief gelaufen sein. Oder du hattest das schon immer falsch, und es ist bloss vorher nicht aufgefallen.

Und es heisst dass ich die Fehlermeldung genau verkehrt herum verstanden habe, also wo 0 und wo 2 verwendet wird.

allerdings habe ich 184 Projekte in 6 Solutions

Ja die alle zu kontrollieren macht sicher keinen Spass. Du könntest versuchen mit einem XQuery Tool draufzuhauen. Damit sollte sich das mit einem Batch-File machen lassen.

Das gute ist aber: durch eben das Feature des MS Linkers das dir diese Fehlermeldung beschert, ist ja sichergestellt, dass du nix zusammenlinkst was nicht zusammenpasst. D.h. wenns baut, dann wird es auch passen. Zumindest dieser Aspekt.

Ja es wird nicht einfacher, kleine Fehler können kurzzeitig das ganze Projekt offline schalten ^^
Schlussendlich war NDEBUG nicht gesetzt sondern _DEBUG das haben wir schon unter w3.11 umlegen müssen. Aber es kommt vor, das längst bekannte Zustände sich erneut zu einem Wunder entwickeln.

Die Portierung nach 64 Bit war schon recht heftig, besonders als raus kam, das alles inline asm nicht mehr so mitgenommen werden kann(bekannt seit 2003). Oder die früher gern verwendeten DWORD Addressen ->shity men.

Leider hat mein masm für 64bit auch abgekackt, und will meine eax Geschichten auch nicht mehr assemblieren, ich werde das ganze ASM rauswerfen, hat 10 Lebensjahre gekostet. Wird durch paar for schleifen ersetzt. Alles nur wegen der Unmengen von Speicher die man heute braucht.

Kein Mensch braucht mehr als 640KB