uClibc++ vs. GNU libstdc++

[Suchiman]

Da ja mit dem Trunk 7148 die Möglichkeit gekommen ist libstdc++ als Standard c++ implementation zu nutzen wollte ich hier mal eine Diskussionsrunde starten was denn die Vorteile und Nachteile der beiden C++ implementationen sind. Da so viele Änderungen ja am Build System erfolgt sind habe ich beschlossen nochmal von einem frischen Checkout anzufangen. Daher die Frage, Vorteile und Nachteile und besonders Auswirkungen für Freetz, den AVM part und den normalen Freetz packeten wie z.b. lighttpd, Dropbear etc.

 

[RalfFriedl]

Fangen wir mal mit dem einfachen Teil an:
Die AVM-Programme, und alle anderen Programme, die kein C++ verwenden, sind davon nicht betroffen.

 

[cwarlich]

Sowas geht z.B. nur mit der libstdc++, die libuClibc++ ignoriert die Formatangaben:

std::cout << std::setfill('0')
             << std::setw(2) << calenderTime.tm_hour << ":"
             << std::setw(2) << calenderTime.tm_min << ":"
             << std::setw(2) << calenderTime.tm_sec;

 

[er13]

Auswirkungen für den AVM part

gar keine, was höhere Programmiersprachen anbetrifft, so verwendet AVM ausschließlich C (man beachte, C ist nicht gleich C++)

wie z.b. lighttpd, Dropbear etc.

gar keine, die von Dir aufgelisteten Pakete sind in C geschrieben. Damit es irgendwelche Auswirkungen gibt, muss in der .mk-Datei des Pakets die Zeile $(PKG)_DEPENDS_ON := $(STDCXXLIB) auftauchen.

Daher die Frage, Vorteile und Nachteile

make menuconfig
-> Advanced options/Toolchain options/Standard C++ Library
-> Hilfe für beide Auswahlmöglichkeiten lesen
den entsprechenden Eintrag in CHANGELOG nachlesen

Kurz zusammengefasst, verwende weiterhin uClibc++, sie ist kleiner, braucht weniger Platz im Image und im Speicher zur Laufzeit. Die beiden Pakete, die libstdc++ (eventuell) brauchen (wenn wir die Probleme mit der uClibc++ nicht lösen), sind nmap-5.x und truecrypt und sind noch nicht eingecheckt.

 

[Suchiman]

okay soweit so gut und verstanden aber wofür ist dann diese "Auswahlmöglichkeit" in dem Toolchain part wenn sich die Packete sich doch selbst die implementation aussuchen? (Zumindest wenn ich das mit Depends on richtig verstanden habe)

 

[er13]

Da hast Du was missverstanden. Früher hat jedes C++-Paket direkt gesagt, ich hänge von uClibc++ ab ($(PKG)_DEPENDS_ON := uclibcxx in .mk) und direkt diese selektiert (select FREETZ_LIB_libuClibc__ in Config.in). Jetzt wird in dem DEPENDS_ON-Teil statt uclibcxx die Variable $(STDCXXLIB) verwendet, die je nachdem, was Du unter "Toolchain options" einstellst, entweder den Wert uclibcxx oder libstdcxx annimt. Im select-Teil ist es genauso, FREETZ_LIB_STDCXXLIB selektiert entweder FREETZ_LIB_libuClibc__ oder FREETZ_LIB_libstdc__ entsprechend Deiner Einstellung unter "Toolchain options".

 

[Suchiman]

Achso okay

 

[sf3978]

... diese "Auswahlmöglichkeit" in dem Toolchain part ...

Die Auswahlmöglichkeit reicht nicht:

...
ccache: FATAL: Could not find compiler "mipsel-linux-uclibc-[COLOR="red"]g++-wrapper[/COLOR]" in PATH
...

 

[er13]

Wann genau kommt die Fehlermeldung? Frischer Build oder svn up mit dem Trick aus r7148?

 

[sf3978]

Frischer Build oder svn up mit dem Trick aus r7148?

Frischer Build (svn co) mit trunk 7153. Beim compilieren von nmap mit libstdc__.

 

[er13]

Hast Du nachdem Du schon was gebaut hast uClibc++ auf stdc++ umgestellt oder war stdc++ von Anfang an eingestellt?

 

[sf3978]

stdc++ war nicht von Anfang (d. h. sofort nach dem Auschecken) an, eingestellt. Ich hatte mit uClibc++, nmap gebaut, aber dann "make nmap-dirclean" gemacht und ein neues Paket für nmap (andere Version) erstellt.

 

[er13]

r7162 behebt für mich das Problem