@Quiche-Lorraine
Du kannst in C# auch #if SYMBOLNAME verwenden. Welche Symbole definiert sind, kann man in den Projekteinstellungen pro Konfiguration festlegen. Per Default definieren Debug Konfigurationen das Symbol DEBUG.
@Schelli
aber es ist verwunderlich, daß der Editor den Namen der neuen Datei anzeigt, aber die alte ausführt.
Ist es nicht, sofern du kein neues Projekt erstellt hast. Du startest in Visual Studio ja nicht das .cpp File das du gerade offen hast. Du startest immer das Projekt das du offen hast. Welches .cpp File du offen hast, bzw. ob überhaupt eines, spielt dabei keine Rolle.
Hallo und willkommen.
Dieser Thread ist uralt und auch super unspezifisch, dein eigener Beitrag leider auch. Anstatt uralte Beiträge hervor zu holen, die nichts zu deiner Frage beitragen, mach bitte einen neuen Thread auf. Wenn du eine hilfreiche Antwort möchtest, sei auch möglichst genau und spezifisch bei deiner Problembeschreibung. Lies zum Beispiel dies hier: Du brauchst Hilfe?
@Quiche-Lorraine Hab gerade eine neue Solution mit einem neuen Projekt erstellt, mit dem selben Ergebnis.
@Tyrdal: Mit dem Flag geht's doch. War am Freitag wohl etwas zu müde und mir ist das "-" bei dem Flag durchgegangen. Ich bin trotzdem verwundert, dass nur bei double Membern da optimiert wird.
@Th69 sagte in GNU mit Visual Studio Code:
MinGW erzeugt Windows-Programme auf Basis der GNU Compiler.
Du möchtest aber wohl einen Cross- bzw. Remote-Compiler benutzen, also Linux-Programme erzeugen?
Schau dir mal Erstellen eines auf MSBuild basierenden C++-Projekts für Linux in Visual Studio sowie Tutorial: Erstellen plattformübergreifender C++-Projekte in Visual Studio / Anleitung: Kompilieren und Debuggen von C++ mit WSL 2 in Visual Studio 2022 an.
Als Beispielprojekt habe ich Cross compile on Linux with VS or VS Code gefunden.
Guten Morgen,
ganz konkret habe ich folgendes installiert
https://developer.arm.com/downloads/-/gnu-rm
also der reine GNU ARM compiler
Danke für das GIT repo, das is interessant;)
Habe auch für VSC eine explizite extension für diese GNU ARM variante gefunden...
@hustbaer sagte in Gemeinsame Codebase und verschieden VS Versionen und toolsets):
Als gemeinsames Projekt-Format könntest du CMake verwenden. Das kann auch noch VS 2008 Projekte generieren.
Was die IDEs angeht: die solltest du auch alle auf einem PC (VM, ...) installieren können, parallel. Was die SDKs angeht kann ich dazu nix sagen, hab nie mit WinCE SDKs gearbeitet.
Falls du auch Build-Server brauchst: wäre vermutlich nen Versuch wert das ganze auf nem aktuellen Windows in nem Docker Container zum Laufen zu bekommen. Dann hast du das Dockerfile aus der du dir jederzeit relativ schnell wieder ein Image bauen kannst, mit 1:1 dem Setup drauf das du zum Bauen brauchst. Das Dockerfile kann man dann versionieren und so gefahrlos und vergleichsweise schnell rumexperimentieren.
Eine Gemeinsame IDE mit verschneiden SDK und Toolsets..
Falls du eine gemeinsame Visual Studio Version findest mit der alle benötigten SDKs funktionieren, wäre das mMn. die beste Variante. Ansonsten: siehe oben.
Hallo Hustbaer, sorry für die spät rückmeldung (echt undankbar von mir). Aber die Idee mit CMake is gut.. und vll. sollte ich auch alles VS Versionen auf eine gemeinsam VM pressen.. das wäre auch ne Idee.
Build-Server brauche ich zum glück keine:)
Schöne Wochende dir
@Kaan02 sagte in cannot find 'ld':
@SeppJ Ein Hello-World funktioniert hier auch nicht, was denkst du kann ich dagegen tun?
Keine Ahnung, aber so wissen wir wenigstens erst einmal Bescheid, dass da etwas falsch installiert ist. Ich verschiebe in ein passendes Fachforum.
@Mathuas sagte in codeblooks findet X11 Sourcen nicht:
Diese Include befindet sich hier. "/usr/include/X11/Xlib.h"
Dies habe ich etwas falsch ausgedrückt. Diese Datei ist auf beiden PCs vorhanden.
Hallo und Danke für Eure Tipps,
wer lesen kann ist klar im Vorteil.
Die Kompilation wird beendet mit dem Hinweis:
Libraries have been installed in:
/home/user/apps/gcc/lib/../lib64
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
Das müsste ja das sein, was firefly gepostet hat.
Mir geht es ja um's Klügerwerden :).
Also ein Programm, das ich kompiliere, 'läuft' nicht in jeder Umgebung?
Sondern es sucht sich zu Laufzeit seine libs*.so.*, die dazu passen müssen?
Oder eben mit Pfadangabe dahin?
Aber warum laufen dann so viele "alte" Programme unter den OS?
Werden die Pakete der Distris immer dementsprechend angepasst bzw. gelinkt?
Gruß
Piet
@Th69 sagte in LNK1107 Ungültige oder beschädigte Datei SDL2.dll -> Zweck: Joystick verwenden:
@stefanpc81: Hast du noch nie mit externen DLLs in deinen Projekten gearbeitet?
Edit: Bin im Ausdrücken etwas schlecht... Ich meinte noch NIE. Bei Qt habe ich das irgendwie noch nicht gebraucht.
Hallo hustbaer,
nein, weder lustige Makros noch Preprozessor Gedöhns.
Aber, seit dem großen gestrigen 17.4 Update ist dieses autom. Einrückproblem weg.
Die IDE formatiert wieder, wie es sein soll.
Vielen Dank für eure Beiträge
Gruß
-Uwe
@clueless123 sagte in Code aus zwei unterschiedlichen Visual Studio Projekten mit unterschiedlichen Plattformen verwenden:
Frei zur Verfügung stehen leider keine übereinstimmenden Versionen
Frage doch mal bei den Hiwis nach. Eventuell hat auch die AG ein Login.
@Kloeterkong sagte in Konfiguration Visual Studio 2022 [gelöst]:
Aber selbst über den Assistenten erstellte Anwendungen verursachen diese Fehlermeldungen.
Das sollte nicht so sein. Mit welchem Projekt-Typ/Einstellungen hast du konkret Probleme?
Bzw. falls da etwas nicht funktioniert, kannst du es auch direkt an MS melden. In VS2022 ist ja eine "Send Feedback" Funktion integriert. Und nach meiner Erfahrung wird das dann auch nicht ignoriert. (Es kommt immer wieder vor dass gemeldete Fehler als "nicht wichtig genug" geschlossen werden. Aber eine Antwort hab ich bisher in jedem Fall bekommen. Was ich bei einem gratis Tool von so einer grossen Firma schon erwähnenswert finde. Und viele Dinge die ich gemeldet habe wurden dann auch repariert.)
Dinge die du dabei beachten solltest:
Schreib auf Englisch.
Beschreib was du gemacht hast so genau dass man es ohne zu raten 1:1 nachstellen kann.
Du solltest dir halbwegs sicher sein dass es auch wirklich ein Fehler ist. Also bei über den Assistenten erstellten Projekten sollte man davon ausgehen können dass sie ohne jegliche Änderung kompilierbar sind. Wenn nicht, würde ich das nen Fehler nennen. Sobald du aber etwas änderst, kann es natürlich sein dass du den Fehler selbst verursacht hast.
