Bitte um Hilfe: Ich finde die Ursache der komischen Fehler nicht.

Das ist die benötigte Infrastruktur für einen printf() function call. Mach den mal raus.

Ansonsten probiere mal "-lnosys" als Linker Option...

Alex schrieb:

Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Dann suche systematisch. Immer nur eine Änderung und übersetzen.

Udo S. schrieb:

Alex schrieb:

Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Dann suche systematisch. Immer nur eine Änderung und übersetzen.

"git bisect" kann helfen, daß man nicht jede einzelne Änderung testen muß.

Ansonsten probiere mal "-lnosys" als Linker Option...

Wie stellt man das im AT Studio ein? Unter Project-Properties-Linker-???

"git bisect" kann helfen, daß man nicht jede einzelne Änderung testen

muß. Danke schonmal. Werde ich ausprobieren.

Alex schrieb:

Bitte um Hilfe: Ich finde die Ursache der komischen Fehler nicht.

Finde ich auch nicht.

Und ich habe wirklich gesucht. Mehrfach.

Alex schrieb:

Sowas vermute ich auch, habe aber schon die ganzen Differenzen zur fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Was soll mir das Wort "unverdächtig" in diesem Zusammenhang sagen?

Alex schrieb:

habe aber schon die ganzen Differenzen zur fehlerfreien Version gecheckt. Die sind alle unverdächtig.

Dann nimm die fehlerfreie Version, ob sie weiterhin fehlerfrei compiliert. Und dann füge die Änderungen nacheinander ein.

ok, mit "-lnosys" als Linker Option kommen jetzt zusätzliche Meldungen -Anhang.

Oh mann, mein EntwicklungsleiDer hat Configuration "Debug" und "Release" eingerichtet. Wenn ich auf Debug stelle, kommen die komischen Fehler, wenn ich auf Release gehe, sind sie weg. Wie finde ich das raus???

Alex schrieb:

Wie finde ich das raus???

Vergleiche die Toolchain-Einstellungen und Parameter für diese beiden Makepfade.

Wohl dem, der eine Revisionsverwaltung hat und diese auch nutzt.

Die gibt es für lau im Netz und wenn man will, kann man jederzeit den "Rückwärtsgang" einlegen. Natürlich muss man sich angewöhnen diese auch zu nutzen und dann - "Oh wie schrecklich!" - einen Kommentar abgeben um die Änderung zu bezeichnen.

Wohl dem, der eine Revisionsverwaltung hat und diese auch nutzt

Ich benutze Tortoise Git! Das git bisect hat mir nix gebracht, da ich genau weiß welche Version ging und bei der Nächsten ging es nicht mehr...

Und wenn alles andere nix nützt, könnte miteinander reden vielleicht was bringen. Einfach mal fragen, welche Unterschiede er zwischen Debug und Release macht.

Sebastian S. schrieb:

Wohl dem, der eine Revisionsverwaltung hat und diese auch nutzt.

Wer die vor allem nutzt, um Änderungen von Kollegen asap rückgängig zu machen, hat ruckzuck andere Probleme, die git nicht lösen wird.

Ansonsten : ja, eine Versionsverwaltung und deren regelmäßiger Gebrauch helfen oft sehr.

Und wenn alles andere nix nützt, könnte miteinander reden vielleicht was

bringen. Das ist kaum möglich - leider

Also kommen jetzt keine weiteren sachdienlichen Hinweise mehr?

Alex schrieb:

Also kommen jetzt keine weiteren sachdienlichen Hinweise mehr?

Hast schon mal versucht alle *.obj Files im Projekt von Hand zu löschen damit auch keine "Leichen" von der Vorgeschichte vorhanden sind?

Kann es sein dass es sowas wie ein Debug_Printf gibt ev in einem Macro versteckt?

Alex schrieb:

Das ist kaum möglich - leider

geil

Kündigen

Alex schrieb:

Also kommen jetzt keine weiteren sachdienlichen Hinweise mehr?

Ich unterscheide ganz gerne zwischen technischen Problemen und sozialen Problemen.

Soziale Probleme kann man meist dadurch bearbeiten, dass man darüber redet. Und während man darüber redet, ändert sich das Problem, oder die Einstellung dazu ändert sich. Was beides im Endeffekt auf das gleiche herausläuft. Auf technische Probleme lassen sich die sozialen Lösungsstrategien selten anwenden.

Bei technischen Problemen:

1. Problem analysieren
2. Lösung erarbeiten
3. Lösung durchsetzen.

Punkt 1 erfordert umfangreiche Kenntnisse über das Problem selber, über den Kontext. Die Anwendung technischer Strategien, auf soziale Probleme, führen gerne zu gruseligen Lösungen, z.B. Guillotine, Elektrischer Stuhl usw.

War das sachdienlich?

Hässlicher Trick: Die fehlenden Funktionen (_write etc.) als Dummy leer implementieren. Disassembly erzeugen und schauen wo malloc(), printf(), puts() etc. aufgerufen werden.

Thomas Z. schrieb:

Kann es sein dass es sowas wie ein Debug_Printf gibt ev in einem Macro versteckt?

Wäre auch meine Vermutung. Oder: es wird assert() genutzt, welches standardmäßig printf() und abort() aufruft. Im Release-Build wird per -DNDEBUG das assert() deaktiviert.

Oder: es wird assert() genutzt, welches standardmäßig printf() und abort() aufruft.

Ja genau, ich habe assert() drin. Aber das hatte ich auch schon, als es noch keine Fehler gab. Irgend wie / wo muss man dem assert das printf abschalten können?

Alex schrieb:

Irgend wie / wo muss man dem assert das printf aqbschalten können?

Indem du eine eigene __assert_func implementierst und dort halt kein printf verwendest.

Also, ich habe meine eigene assert() geschrieben. Damit konnte ich mein Problem lösen. Vielen Dank für eure Hilfe, die den wichtigen Hinweis auf printf <= assert gegeben hat. Damit ist für mich das Thema erledigt.

Alex schrieb:

Also, ich habe meine eigene assert() geschrieben.

Achtung, da gibt es ein paar Fallen wenn man es "from Scratch" macht (statt z.B. die Standard-Implementierung anzupassen).