Ist das nicht eh schon so wie in a beschrieben?
Habe mir gerade gestern nach der Aktualisierung des Updater ne neue Chain für die Two geladen und eine ssl lib installiert, fertig.
ist es eben noch nicht , da die vorhandenen Toolchains meist schon *.libs installiert haben und diese dann überschrieben werden und das soll eben bei einer clean Toolchain Auswahl vermieden werden,
so könnte jeder eine funktionierende Toolchain zur Verfügung stellen und man kann sie sich je nach Anforderungen mit den nötigen *.libs versorgen (war nur ein Vorschlag, welchen ich hier schon länger Praktiziere)
Ansonsten müsste man mal gucken welche libs die gängigen Images benötigen und dafür dann fertige Toolchains machen. Dann wäre die "breite Masse" abgedeckt. Für spezielle Fälle könnte man dann ja noch "cleane" Toolchains zur Verfügung stellen wo sich dann jeder für deinen Bedarf libs reinpacken kann.
Ist aber dann mehr Arbei für dich.
das wären sie mit einem clean toolchain auch und da sich die *.lib Versionen ( zum Beispiel openssl) auch ändern wären wir wieder an dem Punkt , wo die breite Masse die vorhanden *.libs überschreiben müsste
aber mir ist es eh wurscht , ich mach es hier wie immer
@WXbet
1. pcsc v1.9.9 baut nicht durch ... irgendwas mit _ATOMIC-Error (v1.9.5 hat noch funktioniert)
(edit: ich habs mal mit der Openwrt-Pogo/Kirkwood-TC und mipsel_s3_ssl102 probiert, da hat es funktioniert! =>
das ist bestimmt die selbe Baustelle wie bei libUSB .23/.26 ... gcc-abhängig vielleicht wieder?)
=> also neuere TC's scheinen zu funktionieren - aber die pre-installed TC's sind zickig: solo4k, dreambox_fpu, rasp_hard zb. !!!
2. libCURL v7.87 baut vmtl. auch durch - aber wird nicht in die TC eingebunden (?), bzw. gibt auch keinen Eintrag im LIBS-Menü!
(siehe @geisivi aus'm SB-Forum)
Anhänge
Du musst angemeldet sein, um die Anhangsliste zu sehen.
1. pcsc v1.9.9 baut nicht durch ... irgendwas mit _ATOMIC-Error (v1.9.5 hat noch funktioniert)
(edit: ich habs mal mit der Openwrt-Pogo/Kirkwood-TC und mipsel_s3_ssl102 probiert, da hat es funktioniert! =>
das ist bestimmt die selbe Baustelle wie bei libUSB .23/.26 ... gcc-abhängig vielleicht wieder?)
@WXbet
zu 2. : jetzt bekomme ich zwar die richtige v0.23.7 im s3_release gelistet, aber angezeigt wird mir im LIBS-Menü trotzdem noch nix.
zu 1. : dann wäre es vielleicht sinnvoll, auch hier wieder die Unterscheidung v1.9.5<C11 / v1.9.9>=C11 in einer v0.23.8 zu bringen.
Beides ist in der Testversion gefixt. Hier ist erklärt, wie diese genutzt werden kann: Simplebuild 3: Toolchain Update Plugin (s3.TUP) (Spoiler aufklappen)
Wenn die Testversion bereits installiert ist, dann git pull && ./s3 tcupdate --reset im s3_test Verzeichnis ausführen.
... hmm, dann lösche ich meinen s3_test nochmal - und fange nochmal an.
(dann sollte es ja ohne "git pull" gleich klappen)
wenn das alles funktioniert, kann man das auch ins s3_release bringen!
... hast du schon einen Status für das Dcube-R2 Template (ARM_Cortex_A9)?
edit:
mit s3_test schaut es bedeutend besser aus!
dcube template/tc funktioniert einwandfrei!
Neue Testversion TEST.04 ist verfügbar mit folgenden Korrekturen:
- alle crosstool-NG Toolchains werden mit statisch gelinkten Host-Bibliotheken erstellt bzw. sind so downloadbar
- unnötiges Popup beim Schließen eines Toolchain Template Editors entfernt
- das Toolchain dcube wurde durch oe20_armv7 ersetzt und ist nun brandaktuell
- das "Hängenbleiben" der Library, die nach pcsclite integriert wird, wurde behoben
Update wie folgt im s3_test Verzeichnis: git pull
./s3 tcupdate --reset