habe hier gerade das gefunden:
Make a new console project. Do not use the irrlicht template, I assume it's for windows so it gives us a bunch of errors.
Das erklärt alles.
</Closed>
Ich revidiere meinen vorigen Beitrag. Natürlich hat Archi recht, bezüglich der Kompilerspezifität. Unter gcc heißt das gleiche Konzept .a, nicht .lib.
Ich hatte immer gedacht, der gcc kann auch mit .lib umgehen. Das ist scheinbar nicht der Fall...
Trotzdem würde ich so eine Bibliothek wie gesagt in einem eigenen Verzeichnis halten, und wie beschrieben einbinden.
Okay, das Problem schien gewesen zu sein, dass die entsprechende .lib durch statisches Linken genau die gleiche Version/den gleichen Build braucht, was schlichtweg nicht zu funktionieren schien. Hab die neuste Version geladen und so ging's. Alternativ hätte ich dynamisch linken können statt statisch.
Vielen dank für eure Antworten.
Wie kann ich denn herausfinden gegen welche Runtime eine vorhandene Bibliothek gebaut ist? Ich weiss nur, dass sie statisch und Multithreaded ist.
Was genau meinst du mit Debug oder Release. Stell ich nicht bei den Projekteigenschaften bei Debug auf MTd und bei Release auf MT? Mir wurde gesagt das 'd' steht für Debug.
Hallo,
ich hab einen ASM-Datei, die ich zu einer C-Datei gelinkt hab. Da ich beim Debuggen mit GDB mit dem Kommando disassembly aber immer nur durch die kompletten ASM-Dateien durchsteppen kann hab ich mir die ASM-Datei von der C-Datei erstellt. Hab also nun zwei ASM-Dateien, die ich zusammen linke. Ich kann mit GDB aber nach wie vor nur durch meinen eigenen ASM-Code steppen - beim generierten wird mir immer der C-Code angezeigt und nicht der Code, der in der ASM-Datei steht.
Gibt es eine Möglichkeit das zu ändern? Also, dass ich auch durch die generierte ASM-Datei steppen kann?
Die oft im Netz beschriebene "Lösung" des scanf-Problems mit flush ist in der Regel nicht zuverlässig. Soweit ich das weiss, soll das nur bei einem Compiler richtig so funktionieren. Das Blöde beim Testen mit scanf - flush: hin und wieder funktioniert das scheinbar und dann bei wiederholten Testen auf einmal wieder nicht, wenn nicht der eine Compiler das Ganze gebaut hat.
Sonst ist das hier eine der meisstgestellten Fragen, da sollte schon die eine oder andere Lösung hier im Forum beschrieben sein. Stichworte: gets, fgets, sscanf
Achtung: auch bei den Alternativen sind compilerspezifische Lösungen unterwegs.
So nun getestet mit gcc 4.4.1
die Aufrufe:
mingw32-gcc -fno-stack-protector -o test test.c -std=c99
und auch:
gcc -fno-stack-protector -o test test.c -std=c99
funktionieren bei mir ohne Fehlermeldung!
Hab keine Ahnung wo der Wurm bei dir drin ist.
Dieser Thread wurde von Moderator/in phlox81 aus dem Forum Andere GUIs - Qt, GTK+, wxWidgets in das Forum Compiler- und IDE-Forum verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
derda_ schrieb:
Nicht umsonst gibt es keine dumme Fragen.
Aber dumme Frager. Und zu diesen gehören jene Leute, die sich nicht zurest selbst erkundigen.
Hallo,
da Sandcastle lediglich Managed C++ unterstüzt, suche ich nach einer anderen Möglichkeit eine Dokumentation meines (nativen) C/C++ Codes mit MSDN Style zu machen.
Kennt da jemand was?
Athar schrieb:
Marc-O schrieb:
Des Einzige was mich irgendwie immer wieder stört ist, dass ich bei übersetzten Programmen die mingw-DLL mitgeben muss.
Musst du nicht, jedenfalls nicht beim TDM MinGW.
Der Grund für die Binarygröße ist, dass bei MinGW die CRT statisch gelinkt wird. Wer keine der Streamklassen verwendet, muss diesen Preis allerdings nicht zahlen.
UPX ist auch eine eher schlechte Idee, da einige Antiviren-Programme mehr oder weniger automatisch Alarm schlagen (Norton, Avast, AVG...), wenn ein Programm mit UPX gepackt ist. Die endlosen Anfragen von Nutzern, warum XXX das Programm denn als Trojaner einstufe, willst du dir nicht antun.
Die CRT wird zwar statisch gelinkt, dennoch produziert der VC++ auch mit statisch gelinkter CRT deutlich kleinere Binaries (z.B. bei einem meiner Projekte mit über 5000 Zeilen ca. 300 statt 720 KB).
Zudem kannst du nicht einfach behaupten, dass er UPX nicht benutzen _will_. Wenn er sein Programm nur im kleineren Kreis verteilen will, kann er auch einfach darauf hinweisen.
Schade, dass der Beitrag verschoben wurde. Im anderen Forum wurde mir doch gleich geantwortet?!
Kann mir vielleicht jemand sagen, wie ich in VS2005 /NODEFAULTLIB:libcmt.lib "einfüge". Hab gelesen , dass man das irgenwie mit dem Linker machen muss nur hab ich leider keine Ahnung wie das geht, VS macht das linken usw ja immer von selbst.
useria83 schrieb:
also ich denke jetzt, dass "gcc" kein cpp-compiler ist.
hab jetzt den g++ 4.4.3 installiert und bekomme jeztz wenigstens Fehlermeldungen beim compilieren. freu und gleichzeitig net freu.
Fehler sofort gefunden : hier der Code der funtzt :
[cpp]#include <iostream>
#include <iomanip>
using namespace std;
void fkt( int &obj);
int main () {
int x =0;
fkt( x ) ;
cout << " HIer ist x nach der fkt " << x << endl;
return 0;
}
void fkt( int &obj) {
obj = obj + 8 ;
}[/cpp]
in Zeile 12 aktueller code steht jetzt kein void vor fkt(); soll ja auch nicht, da das bedeuten würde dass die funktion hier an der Stelle neu erzeugt wird und die soll ja nicht neuerzeugt sondern "BENUTZT" werden.
Das Ergebnis ist :
HIer ist x nach der fkt 8
danke an alle für Hinweise und hilfe.
besten Dank an f.-th.
Und vergiß nicht "The C Programming Language" von K&R zu kaufen.
http://www.amazon.de/Programming-Language-Prentice-Hall-Software/dp/0131103628/ref=sr_1_1/276-5084541-0262726?ie=UTF8
Genau
An dem Rechner, an dem ich diese blöde Library benötige, habe ich keinen Internetzugang. Ich müsste also bei Fragen an die Library immer zwischen zwei Rechnern wechseln. Das würde ich nicht wirklich effektiv nennen
gut hat sich herausgestellt dass mein linker nicht richtig funktionniert hat, jedenfalls hat ein anderer liker es korrekt kopiliert, wahrscheinlich ein fehler während des compilierens des crosscompilers...
