Hi, ich habe seit einigen wochen das Buch "C Einführung und professionelle Anwendung" gekauft und bis zum 16 kapitel bis jetzt durchgearbeitet. Auf der CD gibts einen GNU-c/c++ compiler den ich bis jetzt nicht gebraucht habe. Doch in dem aktuellen Kapitel brauche ich für ein programm eine library die ich anscheinend von diesem GNU compiler herbekomme. jetzt wollte ich es intstallieren als diese fehler meldung kam (siehe screenshot) hoffe jemand weiss da ne lösung! Nachtrag: das programm lade ich auch mal hoch falls es was hilft
Angehängte Dateien:
-
screenshot.png
170 KB
hi, die seite hab ich auch entdeckt nur peil ich da nicht wirklich durch welche ich da brauch bzw wie ich sie installieren kann
Und, warum glaubst Du unbedingt mit einer 64-Bit-Windows-Version hantieren zu müssen? Weil's so cool ist? Oder weil Du das wirklich brauchst?
Rufus t. Firefly schrieb: > Und, warum glaubst Du unbedingt mit einer 64-Bit-Windows-Version > hantieren zu müssen? Weil's so cool ist? Oder weil Du das /wirklich/ > brauchst? es war natürlich kalr das so ne blöde antwort kommen muss ich hab einfach vor kurzem eine win 7 64 bit version draufgemacht UND JETZT? was has du für ein problem is das verboten
Bob Hulu schrieb: > Hi, > > ich habe seit einigen wochen das Buch "C Einführung und professionelle > Anwendung" gekauft und bis zum 16 kapitel bis jetzt durchgearbeitet. Auf > der CD gibts einen GNU-c/c++ compiler den ich bis jetzt nicht gebraucht > habe. Interessehalber: Was hast du denn bisher benutzt? Etwa den Compiler aus dem Visual Studio? Finger weg, hinsichtlich C (C99) ist der schon länger nicht mehr aktuell und Microsoft hat nicht vor, das zu ändern. Der ist auf C++ ausgerichtet. > Doch in dem aktuellen Kapitel brauche ich für ein programm eine > library die ich anscheinend von diesem GNU compiler herbekomme. Welche? > Nachtrag: das programm lade ich auch mal hoch falls es was hilft Es steht doch ganz klipp und klar im Kommentar, dass das Programm nur mit DOS läuft. Daran ändert auch die GCC nix. conio.h stammt übrigens von Microsoft. Alternativ gäbe es da allerlei 'Port-IO'-Treiber, die die Sicherheitsmechanismen von neueren Windows-Versionen aushebeln. Die Treiber werden neuerlich vermutlich an der Signatur/Zertifizierungs-Politik von Microsoft scheitern. outb() und inb() gibts auf Unixen nach wie vor, mit ioperm() funktionierts dann auch.
>> Nachtrag: das programm lade ich auch mal hoch falls es was hilft > Es steht doch ganz klipp und klar im Kommentar, dass das Programm nur > mit DOS läuft. Daran ändert auch die GCC nix. > conio.h stammt übrigens von Microsoft. > > Alternativ gäbe es da allerlei 'Port-IO'-Treiber, die die > Sicherheitsmechanismen von neueren Windows-Versionen aushebeln. Die > Treiber werden neuerlich vermutlich an der > Signatur/Zertifizierungs-Politik von Microsoft scheitern. > outb() und inb() gibts auf Unixen nach wie vor, mit ioperm() > funktionierts dann auch. ähm bis jetzt hat der visual c/c++ compiler gerreicht als ich aber dann den oben gezeigten code compilliern wollte kam diese fehlermeldung: checkprn.obj : error LNK2001: Nichtaufgeloestes externes Symbol _inp Debug/checkprn.exe : fatal error LNK1120: 1 unaufgeloeste externe Verweise Fehler beim Ausführen von link.exe. ein kumpel hat gemeint das er noch die library für inp brauchen würde
weiß jemand was die fehlermedlung bedeutet bzw was die lösung wäre
Ist schön, wenn er reicht. Er unterstützt trotzdem kein vernünftiges C99. Die Fehlermeldung besagt, dass es eine Definition von _inp() nicht gibt. Vermutlich hat man die Funktion aus dem 'Betriebssystem' (dem Benutzerraum) entfernt.
Sven P. schrieb: > Ist schön, wenn er reicht. Er unterstützt trotzdem kein vernünftiges > C99. > > Die Fehlermeldung besagt, dass es eine Definition von _inp() nicht gibt. > Vermutlich hat man die Funktion aus dem 'Betriebssystem' (dem > Benutzerraum) entfernt. ohne gleich wieder einen auf den deckel zu kriegen kannst du mir in kurzen worten erklären was es mit diesem GNU überhaupt aufsich hat? ich hab mich damit noch nicht so beschäftigt ich vermute es handelt sich um eine sammlung von header dateien aber du kannst mich gerne korrigieren
Dir fehlt das Programmstück in dem die Funktion inp() implementiert ist. Eine gängige Methode um diese Funktion zu bekommen ist, die impout32.dll zu benutzen. http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html Hinweise zur Anwendung gibt es bei Codeproject.com http://www.codeproject.com/info/search.aspx?artkw=printer&vidlst=80%2c78&sa_ao=False&sa_so=17&sa_as=1%2c3%2c4%2c5%2c6&pgnum=2 Die inpout32.dll ist aber für WIN 98/NT/2000/XP, also bei 64-Bit Windows, Vista oder Windows 7 kann (wird) es Probleme geben.
Nein. Die Fehlermeldung ist eine des Linkers, und sie besagt, daß in keiner der verwendeten Libraries und Objektdateien eine Funktion namens (_)inp gefunden werden kann. Mehr besagt sie nicht. Mit dem Betriebssystem hat das nichts zu tun, da ist auch nichts "entfernt" worden. Die Funktion lässt sich mit etwas inline-Assembler nachbilden, aber unter den ernstgemeinten Windows-Versionen (alles außer 95 & Konsorten) funktioniert so etwas trotzdem nicht ohne zusätzliche Vorkehrungen à la giveio.sys. Und die wiederum gibt es nicht für 64-Bit-Windows. Stattdessen sollte hier ein Devicetreiber verwendet werden. Da es allerdings nur um das Erlernen des Programmierens in C geht, rate ich jetzt mal ganz einfach dazu, diese Übung auszulassen. Sie vermittelt hoffnungslos veraltete Techniken, die unter Betriebssystemen der letzten 10 Jahre nur mit üblen Frickeleien funktionieren. Das sieht übrigens auch unter Linux nicht anders aus; auch unter Linux darf ein Usermode-Programm nicht mit direkten I/O-Operationen an der Hardware herumpfuschen. > es war natürlich kalr das so ne blöde antwort kommen muss > ich hab einfach vor kurzem eine win 7 64 bit version > draufgemacht UND JETZT? > was has du für ein problem is das verboten Das ist die Ursache Deines Problemes. Mir ist das vollkommen schnurz, aber die 64-Bit-Windows-Version ist der Grund, warum auf Deinem Computer das von Dir geschilderte Problem auftritt. "Verboten" ist das natürlich nicht, aber eben die Quelle vielen Ärgers. Und dem hast Du Dich ausgesetzt, weil Du diese Windows-Version installiert hast.
Benutze das Buch in dem dort angegebenen Rahmen, also DOS/Windows 98 auf einem entsprechenden Rechner oder beschränke dich auf die nicht-hardwarenahen Programmbeispiele oder beschaffe dir ein aktuelleres Buch.
Rufus t. Firefly schrieb: >> es war natürlich kalr das so ne blöde antwort kommen muss >> ich hab einfach vor kurzem eine win 7 64 bit version >> draufgemacht UND JETZT? >> was has du für ein problem is das verboten > > Das ist die Ursache Deines Problemes. Mir ist das vollkommen schnurz, > aber die 64-Bit-Windows-Version ist der Grund, warum auf *Deinem* > Computer das von Dir geschilderte Problem auftritt. > > "Verboten" ist das natürlich nicht, aber eben die Quelle vielen Ärgers. > > Und dem hast Du Dich ausgesetzt, weil Du diese Windows-Version > installiert hast. So sauer habe ich dich ja noch nie erlebt. Heh, es ist Sonntagmittag. Zeit für eine heisse Tasse Kaffee und ein Stück Kuchen!
nachtrag: also liebe leute ich hab gerade mit einem kollegen gesprochen der da schon etwas fitter ist und er meinte ebenfalls das das programmbeispiel doch schon sehr veraltet ist. es war ein programmbeispiel zur erklärung von bit feldern, hätte ich mir die comments am anfang etwas genauer durchgelesen hätte ich mir den post hier ersparen können sorry. da stehts ja drin das es ab win nt und aufwärts nicht mehr funzt. das buch is trotzdem sehr gut muss ich sagen structs und unions wurden zuvor sehr gut erklärt und ich weiß jetzt endlich wie man damit umgehen muss. auf jeden fall besser erklärt als mein alter informatik prof ^^. ich glaube ich schau mir das programm nochma an wenn ich mich mehr mit dlls beschäftigt habe was in dem buch in späteren kapiteln noch behandelt wird. trotzdem vielen dank für alle antworten
Rufus t. Firefly schrieb: > Nein. Die Fehlermeldung ist eine des Linkers, und sie besagt, daß in > keiner der verwendeten Libraries und Objektdateien eine Funktion namens > (_)inp gefunden werden kann. Mehr besagt sie nicht. > > Mit dem Betriebssystem hat das nichts zu tun, da ist auch nichts > "entfernt" worden. Ist doch meine Rede. Es war mit 9x noch dabei und ist es jetzt halt aus verschiedenen Gründen nicht mehr. inp() gehört in irgendwelche Header des Betriebssystemes, nicht zur C-Bibliothek.
> inp() gehört in irgendwelche Header > des Betriebssystemes, nicht zur C-Bibliothek. In irgendeiner Headerdatei ist es aber vorhanden, denn der erwähnte Fehler ist ein Linkerfehler. Und inp() ist kein Betriebssystemaufruf, sondern ein Wrapper um den Assemblerbefehl in. Aber das sind Spitzfindigkeiten, die nichts mit dem eigentlichen Problem zu tun haben.
Deshalb muß es nicht in einer Headerdatei stehen; vielleicht kam ja irgendwo eine kleine Warnung von wg. implicit declaration, die wir nur nicht gesehen haben? Aber stimmt, hat nichts mit dem Problem zu tun.
Habe gerade mal nachgesehen: Bei Visual Studio 2008 sind in conio.h die Definitionen für _inp, _inpw und _inpd sowie die äquivalenten _out, _outw und _outd nach wie vor enthalten. Die Implementierung ist ebenfalls in den unterschliedlichen Varianten der C-Runtime-Library enthalten. Allerdings achte man auf den Namen der Funktionen - sie werden mit vorangestelltem Unterstrich geschrieben. Die dem Linker übergebenen Symbolnamen enthalten bei MS einen zusätzlichen Unterstrich. Daher ist aus der oben zitierten Fehlermeldung darauf zu schließen, daß der Threadstarter eine Funktion namens inp aufgerufen hat (und weiß Gott woher eine Deklaration dafür gefunden oder die Fehlermeldung ignoriert hat). Hätte er anstelle dessen conio.h eingebunden und _inp aufgerufen, würde sein Programm erst beim Laufenlassen auf die Schnauze fallen, und zwar mit einer Fehlermeldung wie Unhandled exception at 0x0irgendwo in irgendwas.exe: 0xC0000096: Privileged instruction. Also, die Unterstützung für direkten I/O-Zugriff ist nach wie vor in MS-Compilern vorhanden.
Hallo Bob, die Leute die Dir geraten haben das nicht auf System > win95 zu machen haben natürlich recht, nichtsdestotrotz hast Du dich letztendlich mit dem Thema auseinandergesetzt und das ist gut so. Ich habe den Thread nur überflogen aber auf anhieb fällt mir da ein dass es ev. helfen könnte die io.h statt conio.h einzubinden. Wenn ich das richtig im Kopf habe ist das beim GNU-Compler so. Alternativ mal unter Linux versuchen, da kann man solche Spielchen (als root) machen. Viel Erfolg
Rufus: Nun haste schön zehn Sachverhalte zusammengewürfelt... Nur weils ein Linkerfehler ist, muss inp() nicht zwangsläufig korrekt deklariert sein. Im Zweifelsfall nimmt ein C-Compier einfach ein 'int()' an und übersetzt es. Da inb()/inp() und Konsorten absolut garnix mit dem C-Standard zu tun haben, findet man die meistens als Makros/Inlines in irgendwelchen Bs-Headern. Darum liegen die auch in <sys/io.h> und nicht darüber. Unter Unixoiden sollte man dann noch aufpassen, dass die Dinger nicht inp, sondern inb (b!) heißen und dass Microsoft die Reihenfolge der Argumente vertauscht hat.
> Nur weils ein Linkerfehler ist, muss inp() nicht zwangsläufig korrekt > deklariert sein. Im Zweifelsfall nimmt ein C-Compier einfach ein 'int()' > an und übersetzt es. Dann würde der Compiler aber eine Warnung ausgeben. Und von einem MS-Compiler war die Rede, der (bzw. dessen Linker) hat die Fehlermeldung ausgegeben, die hier zitiert wurde. Das ist keine gcc-Fehlermeldung. Und was war noch mal Dein Problem?
Ich habe keines mit inb() und Konsorten, bei mir funktionieren sie ja. Ich weiß aber nicht, wie der Übersetzer des Fragenstellers eingestellt ist.
Er arbeitet mit Windows, und da funktioniert so etwas nicht. Was nicht am Compiler, Verzeihung, Übersetzer liegt.
Ja, unglaublich, aber zu dieser Einsicht sind wir schon längst gekommen.
Schön, dann ist ja alles geklärt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.