Nach 3 Tagen bin ich jetzt (fast) schon am Aufgeben. Folgendes Problem stellt sich mir: Wenn ich an meinem Desktop-PC oder Notebook den SDCC in der Version 4.4.0 verwenden möchte gibt es überhaupt keine Probleme (beides sind XUbuntu Ver.22 Rechner). Auf meinem Bastelrechner mit dem ich Mikrocontroller programmiere habe ich einen sehr spartanischen Rechner (4 GB Ram) mit einem sehr schlanken und sehr stark modifiziertem Porteus Live-Linux, bassierend auf Slackware 14.2 (Linux Kernel 4.16.3). Die höchste Version die ich mit SDCC hier an das Laufen bekomme ist 4.1.0. Jede höhere Version scheitert am Nichtvorhandensein von GLIBC_2.34. Bei Slackware finde ich keine Version 2.34 (das höchste der Gefühle ist hier 2.33)! Also denke ich mir (fälschlicherweise): Ich bin ja nicht blöd, übersetze ich mir halt eine libc.so.6.0 selbst und compiliere die Sourcen, GCC Version 4.3 (irgendwann in der Nacht hab ich das einfach laufen lassen, weil das ewig gedauert hat). Insgesamt war das allerdings keine so gute Idee, denn nach dem Installieren hat jeder eingetippte Befehl einen Segmentation Fault hervorgebracht (und er konnte danach auch nicht mehr booten, weshalb da dann "reparieren" erst einmal angesagt war). Hat irgendwer eine Idee, wie man den SDCC 4.4.0 auf einem Kernel 4.16.3 zum Laufen bringen kann? Sagt nicht, von einem anderen Rechner die libc kopieren: wider besserem Wissen habe ich das natürlich auch schon ausprobiert und hat nur zu Segmentation fault geführt.
Moin, An der libc eines Rechners rumdoktoren ist fast immer eine ganz schlechte Idee. In meinem jugendlichen Leichtsinn wuerd' ich mal empfehlen, den SDCC auf dem Zielsystem selber zu compilieren. Gruss WK
Dergute W. schrieb: > An der libc eines Rechners rumdoktoren ist fast immer eine ganz > schlechte Idee. :-) weiß ich und habe das auch nur ungern ausprobiert und auch erst nachdem ich das gesichert hatte um den Ursprungszustand wiederherzustellen. Dergute W. schrieb: > In meinem jugendlichen Leichtsinn wuerd' ich mal empfehlen, den SDCC auf > dem Zielsystem selber zu compilieren. Noch mehr Smile: Da hatte ich natürlich zuvor auch schon versucht gehabt und erst einmal geflucht, weil zum selber compilieren es eine Bibliothek "boost" benötigt, die seinerseits wieder Ewigkeiten braucht bis die übersetzt ist. Dann ließ sich SDCC wegen fehlender GLIBC_2.33 dennoch nicht übersetzen...
Moin, Weiss nicht, wie hilfreich das jetzt fuer dich ist, aber ich hab hier einen Rechner mit ungefaehr einem LinuxFromScratch-7.6 drauf. Kernel: 3.15.1 glibc: 2.19 gcc: 4.9.0 boost:1.55.0 Und auf dem Ding hat sich grad' der sdcc-4.4.0-rc2 bauen lassen (configure & make ohne fehler durchgelaufen). Nur pic14- und pic16-ports musste ich disablen, irgendwelche gpu-tools haben da gefehlt, iirc. Wenn ich da mal stumpf ein sdcc hello.c laufen lasse, kommt ein Fehler: _putchar referenced by module vprintf Also prinzipiell scheint mir der sdcc auch mit aelteren libcs zu laufen. Gruss WK
Dergute W. schrieb: > Nur pic14- und pic16-ports musste ich disablen, irgendwelche gpu-tools > haben da gefehlt, iirc. Klingt das nicht etwas ... ähm, merkwürdig? Wozu braucht ein C-Compiler irgendwelche "gpu-tool", um Code für ältere PICs erzeugen zu können? Wer ist da an welcher Stelle komplett falsch abgebogen?
Moin, Harald K. schrieb: > Wer ist da an welcher Stelle komplett falsch abgebogen? Ich. Es sind die gputils, bzw. deren fehlen, was bemaengelt wird. Nix mit gpu. Gruss WK
Ah, danke. Du hast mir an diesem Freitag doch noch etwas Hoffnung für diese Welt wiedergegeben ...
Ralph S. schrieb: > Hat irgendwer eine Idee, wie man den SDCC 4.4.0 auf einem Kernel 4.16.3 > zum Laufen bringen kann? Der Kernel wird nicht das Problem sein. > Sagt nicht, von einem anderen Rechner die libc > kopieren: wider besserem Wissen habe ich das natürlich auch schon > ausprobiert und hat nur zu Segmentation fault geführt. Es gibt durchaus eine Möglichkeit dazu: Sämtliche Libraries, die das Programm benötigt, auf den Zielrechner in irgendein Unterverzeichnis kopieren. Insbesondere ist dabei die ld-linux.so.* wichtig. Das ist der dynamische Linker. Anders, als man vielleicht vermutet, kann man denn auch direkt als Programm ausführen. Dann setzt du den LD_LIBRARY_PATH auf das Verzeichnis und startest das Programm über die kopierte ld-linux.so. Ich weiß allerdings nicht, ob das geht, wenn das Programm selbst wieder andere Programme startet, was sdcc vermutlich macht. Eine andere Möglichkeit wäre, den Compiler in einem Docker-Container auszuführen.
Dergute W. schrieb: > Kernel: 3.15.1 > glibc: 2.19 > gcc: 4.9.0 > boost:1.55.0 Okay, dann werde ich das noch einmal versuchen. Mein glibc ist neuer, okay, der GCC ist 4.3 (aber den kann ich auch mal erneuern), boost weiß ich nicht (und ich komme am Wochenende auch leider nicht an den Rechner ran). Aaaaber: jetzt weiß ich, dass das geht !
Dergute W. schrieb: > Wenn ich da mal stumpf ein sdcc hello.c laufen lasse, kommt ein Fehler: > _putchar referenced by module vprintf > Also Ich habe jetzt von meinem USB Stick ein Setup laufen lassen, das dem des Bastelrechners entspricht, mit GCC 7.3 und Boost übersetzen lassen. Sdcc läuft tatsächlich, aber der Linker macht noch Probleme mit undefined globals __startup... Dem werde ich bestimmt auch noch auf die Spur kommen...
Ralph S. schrieb: > Noch mehr Smile: Da hatte ich natürlich zuvor auch schon versucht gehabt > und erst einmal geflucht, weil zum selber compilieren es eine Bibliothek > "boost" benötigt, die seinerseits wieder Ewigkeiten braucht bis die > übersetzt ist. Eine Bibliothek namens "boost"... äh, ja. Sind eher so... drölfenölfzig, grob geschätzt. ;-D https://www.boost.org/doc/libs/
Man kann alternative shared Librarys auch einfach ins selbe Verzeichnis wie das Executable legen; dann werden die statt der systemweiten Librarys genutzt.
Moin, Ralph S. schrieb: > aber der Linker macht noch Probleme mit undefined > globals __startup... Ja, aber sowas hat mit dem Startupzeugs fuer C auf dem sdcc-target zu tun. Und nix mit der Version der glibc auf dem Host vs. erwarteter Version von woanders kompilierter Software, was du vorher hattest. Harry L. schrieb: > Man kann alternative shared Librarys auch einfach ins selbe Verzeichnis > wie das Executable legen; dann werden die statt der systemweiten > Librarys genutzt. Huuuh - da will ich ja mal stark hoffen, dass das bei vernuenftigen Betriebssystemen nicht so ootb funktioniert... Gruss WK
Dergute W. schrieb: > Ja, aber sowas hat mit dem Startupzeugs fuer C auf dem sdcc-target zu > tun. Und nix mit der Version der glibc auf dem Host vs. erwarteter > Version von woanders kompilierter Software, was du vorher hattest. Smile, weiss ich doch.. deswegen hab ich ja geschrieben ddass ich dem auf die Spur kommen werde
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.