Linux und SDCC 4.4.0

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