Ich versuche simulavr für FreeBSD zu übersetzen, Compiler ist also hier
clang 8.01 und nicht g++.
Der Compiler spuckt mich an:
cmd/gdbserver.cpp:184:8: error: value of type '__bind<int &, sockaddr *,
unsigned long>' is not contextually
convertible to 'bool'
if(bind(sock, (struct sockaddr *)address, sizeof(address)))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
das ist die Stelle:
[code]
if(bind(sock, (struct sockaddr *)address, sizeof(address)))
avr_error("Can not bind socket: %s", strerror(errno));
[/code
(int) bind() liefert 0 bei success, -1 bei error.
..was für eine bool Conversion schon etwas seltsam anmutet.
Mit meinen ausschließlich C Kenntnissen hab ich jetzt planlos da drin
rumgestochert, aber außer der Bemerkung das der Compiler keine
Conversion ohne Conversionsoperator machen könne, hatte ich keine
brauchbaren Ergebnisse.
Was kann ich hier tun?
Gruß,
Holm
holm schrieb: > Was kann ich hier tun? Ich denke die Funktion bind ist hier nicht vorab definiert, oder zumindest nicht richtig im header.
holm schrieb: > cmd/gdbserver.cpp:184:8: error: value of type '__bind<int &, sockaddr *, > unsigned long>' is not contextually > convertible to 'bool' Daraus wird ersichtlich: Der Compiler versucht an der Stelle ein template zu instanzieren - Name-Clash. Versuch mal ::bind.
holm schrieb: > (int) bind() liefert 0 bei success, -1 bei error. Und, ist das boolean? Und was würde ein C-Programmierer damit anfangen um ein Boolean draus zu machen? Vergleich?
Nick M. schrieb: > Und, ist das boolean? > Und was würde ein C-Programmierer damit anfangen um ein Boolean draus zu > machen? > Vergleich? Gar nichts?
Heiko L. schrieb: > Nick M. schrieb: > Und, ist das boolean? > Und was würde ein C-Programmierer damit anfangen um ein Boolean draus zu > machen? > Vergleich? > > Gar nichts? Doch, ein guter würde einen Vergleich machen.
Heiko L. schrieb: > Gar nichts? Ja, du vieleicht! Wenn bind bei Erfolg 0 liefert ist das aber eher nicht erwünscht für die Bedingung im if. Geht ins Bett!
Nick M. schrieb: > Ja, du vieleicht! > Wenn bind bei Erfolg 0 liefert ist das aber eher nicht erwünscht für die > Bedingung im if. > Geht ins Bett! Man kann natürlich auch schreiben
1 | int error = bind(); |
2 | if(error) ... |
Aber wozu?
Das bind() liefert doch sicher Fehlercodes zurück gegen die man prüfen kann. Die Compiler sind schlau genug das zu optimieren wenn möglich, da muss man sich gar nicht auf Vermutungen einlassen.
Nick M. schrieb: >> (int) bind() liefert 0 bei success, -1 bei error. > > Und, ist das boolean? Sicher. Aber sein bind ist nicht das (int) bin() das er glaubt aufzurufen. Sondern irgendein anderes. ::bind könnte helfen.
mit den Vergleichen habe ich experimentiert, das ist genau das was ich mit "herumstochern" meinte, gibt anders bunte Fehlermeldungen, hilft aber nicht. Das "::" hat dazu geführt das Clang das löffelt, das make läuft also drüber weg. Stellt sich mir die Frage woher der Compiler das '__bind<int &, sockaddr *, unsigned long>' nimmt, zumal das ja ein Bind() zu sein scheint das den selben Zweck erfüllt. # fgrep -r __bind * # @jojo: bind() liefert 0 und -1, was Anderes ist nicht definiert. Gruß, Holm
holm schrieb: > Das "::" hat dazu geführt das Clang das löffelt, das make läuft also > drüber weg. Stellt sich mir die Frage woher der Compiler das '__bind<int > &, sockaddr *, unsigned long>' nimmt, zumal das ja ein Bind() zu sein > scheint das den selben Zweck erfüllt. Nein - std::bind, boost::bind oder sowas wird das sein.
holm schrieb: > mit den Vergleichen habe ich experimentiert, das ist genau das was ich > mit "herumstochern" meinte, gibt anders bunte Fehlermeldungen, hilft > aber nicht. > > Das "::" hat dazu geführt das Clang das löffelt, das make läuft also > drüber weg. Stellt sich mir die Frage woher der Compiler das '__bind<int > &, sockaddr *, unsigned long>' nimmt, zumal das ja ein Bind() zu sein > scheint das den selben Zweck erfüllt. > > # fgrep -r __bind * > # > > @jojo: bind() liefert 0 und -1, was Anderes ist nicht definiert. > > Gruß, > Holm Irgendwo wird der Code ein "using namespace std;" stehen haben. Das spart die Angabe von "std::" vor viele Bezeichnern, dann konkurriert z.B. das "C"-bind aus den Socket-Bereich mit dem C++-Template std::bind(...). Ein "::" vor dem bind stellt sicher, daß das im "globalen" Namespace liegende gewünschte gefunden wird. Eigentlich sollte das Socket-bind() sogar im extern "C" "Namensraum" stehen, zumindest sind aktuelle Header-Files so gebaut. Da schon im Raum stand "Clang statt GCC" scheint letzterer es besser drauf zu haben, das richtige "Overload" zu finden oder schlicht besser/schlauer/rückwärtskompatibler zwischen "C" und "C++" zu trennen.
Carl D. schrieb: > Ein "::" vor dem bind stellt sicher, daß das im "globalen" Namespace > liegende gewünschte gefunden wird. Eigentlich sollte das Socket-bind() > sogar im extern "C" "Namensraum" stehen, zumindest sind aktuelle > Header-Files so gebaut. Der "leere" scope vor den scope-operator wird das Problem lösen. Allerdings bedeutet "extern "C" " nicht ein C-Namensraum sondern der language linkage specifier. Damit wird das Name mangling von C++ unterdrückt und damit zum den C calling conventions passt.
Carl D. schrieb: > Irgendwo wird der Code ein "using namespace std;" stehen haben. Ja, ziemlich ganz oben. >> Das > spart die Angabe von "std::" vor viele Bezeichnern, dann konkurriert > z.B. das "C"-bind aus den Socket-Bereich mit dem C++-Template > std::bind(...). Ein "::" vor dem bind stellt sicher, daß das im > "globalen" Namespace liegende gewünschte gefunden wird. Eigentlich > sollte das Socket-bind() sogar im extern "C" "Namensraum" stehen, > zumindest sind aktuelle Header-Files so gebaut. Includes mit "extern "C" hatte ich schon ausprobiert, hatte exakt gar Nichts geändert. Momentan stürze ich (nach einigen anderen kleinen Änderungen die wohl auf Grund "unscharfer" Definitionen für libtool notwendig werden) über ein Problem mit fehlenden tr1/tuple Headern:
1 | gmake[2]: Entering directory '/usr/home/holm/src/MICROS/simulavr/regress/gtest' |
2 | depbase=`echo session_001/unittest001.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ |
3 | clang++ -pthread -std=c++11 -DHAVE_CONFIG_H -I. -I../../src -Dprivate=public -Dprotected=public -Igtest-1.6.0/include/gtest -Igtest-1.6.0/include -Igtest-1.6.0 -I../../src -g -g -O2 -MT session_001/unittest001.o -MD -MP -MF $depbase.Tpo -c -o session_001/unittest001.o session_001/unittest001.cpp &&\ |
4 | mv -f $depbase.Tpo $depbase.Po |
5 | In file included from session_001/unittest001.cpp:4: |
6 | In file included from gtest-1.6.0/include/gtest/gtest.h:61: |
7 | In file included from gtest-1.6.0/include/gtest/gtest-param-test.h:192: |
8 | In file included from gtest-1.6.0/include/gtest/internal/gtest-param-util.h:47: |
9 | gtest-1.6.0/include/gtest/gtest-printers.h:497:34: error: no member named 'tr1' in namespace 'std' |
10 | inline void PrintTo(const ::std::tr1::tuple<>& t, ::std::ostream* os) { |
11 | ~~~~~~~^
|
12 | gtest-1.6.0/include/gtest/gtest-printers.h:502:27: error: no member named 'tr1' in namespace 'std' |
13 | void PrintTo(const ::std::tr1::tuple<T1>& t, ::std::ostream* os) { |
14 | ~~~~~~~^
|
Mal sehen, entweder ich bekomme diese regression Tests abgeschaltet oder ich muß mir einen gcc installieren mit dem ich das c++ Zeuch durchdrehe. Ich habe gegoogelt, das Problem gabs wohl auch schon bei irgendwelchen Mozilla Geschichten und offfenbar ist das wichtig wie ein drittes Knie.. Gruß, Holm
holm schrieb: > oder > ich muß mir einen gcc installieren mit dem ich das c++ Zeuch durchdrehe gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit AVR arbeiten möchtest. denn der clang hat kein AVR-backend.
Ist der Sprachstandard auf >= c++ 11 eingestellt? https://stackoverflow.com/questions/53490355/cannot-use-using-declaration-for-stdtuple-on-apple-llvm-7-3-0
Johannes S. schrieb: > Das bind() liefert doch sicher Fehlercodes zurück gegen die man prüfen > kann. bind() liefert im Erfolgsfall 0 zurück, im Fehlerfall -1. Der Fehlercode steht danach in errno. Am Rückgabewert erkennt man also erst mal nur, ob ein Fehler aufgetreten ist oder nicht. Carl D. schrieb: > Irgendwo wird der Code ein "using namespace std;" stehen haben. Und hier sieht man ganz gut, warum empfohlen wird, das nicht zu tun. Besonders schlimm ist es in einem Header, weil es dann die saubere Trennung der Namespaces nicht nur für den Header selbst aushebelt, sondern auch noch für alles, was ihn benutzt.
Johannes S. schrieb: > Ist der Sprachstandard auf >= c++ 11 eingestellt? -std=c++11 steht in seinen options ;-)
Wilhelm M. schrieb: > gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit > AVR arbeiten möchtest. denn der clang hat kein AVR-backend. Quatsch, das Programm läuft ja nicht auf dem avr. Gruß, Holm
Wilhelm M. schrieb: > -std=c++11 steht in seinen options ;-) ist ja noch früh am Morgen... tuples sind ja mittlerweile in C++11 drin, ::tr1 war ein Zwischending zwischen 03 und 11, das müsste man weglassen können. Also direkt std::tuple benutzen.
holm schrieb: > Wilhelm M. schrieb: >> gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit >> AVR arbeiten möchtest. denn der clang hat kein AVR-backend. > > Quatsch, das Programm läuft ja nicht auf dem avr. > Mmh, welchen Code möchtest Du dem im Simulator laufen lassen?
Johannes S. schrieb: > Ist der Sprachstandard auf >= c++ 11 eingestellt? > https://stackoverflow.com/questions/53490355/cannot-use-using-declaration-for-stdtuple-on-apple-llvm-7-3-0 Das habe ich auch schon gelesen, ist aber nur ein Hinweis. Diese tr1/tuple Header existieren auf meiner Mühle nur in den Headern anderer Compiler, sprich die gibts nicht. Das gehört wohl zu den Gnu stdc++ headern, ich habe aber kein Gnu C. Ich habe das Target gtest aus einem der Makefiles entfernt, Programm wird gebaut, kann installiert werden und läuft. Gruß, Holm
Wilhelm M. schrieb: > Mmh, welchen Code möchtest Du dem im Simulator laufen lassen? Begreifst Dus nicht? Auch wenn der Simulator AVR Code ausführt, so tut er es nicht auf einem AVR Host, demzufolge muß kein Code für AVR generiert werden, sondern der für den Host. Gruß, Holm
vielleicht war der ::tr1 namespace auch das Problem mit dem bind? https://stackoverflow.com/questions/4682919/what-are-differences-between-std-tr1-and-boost-as-namespaces-and-or-libraries
holm schrieb: > Wilhelm M. schrieb: >> Mmh, welchen Code möchtest Du dem im Simulator laufen lassen? > > Begreifst Dus nicht? Auch wenn der Simulator AVR Code ausführt, so tut > er es nicht auf einem AVR Host, demzufolge muß kein Code für AVR > generiert werden, sondern der für den Host. Davon spreche ich doch gar nicht. Ich spreche davon, auf welchem Rechner Du den Code erzeugen möchtest, den der Simlulator, der mit clang++ kompiliert wurde, abarbeiten soll. So wie es aussieht, willst Du also avr-gcc auf einem anderen Rechner laufen lassen. Ist ja auch ok.
Wilhelm M. schrieb: > Davon spreche ich doch gar nicht. > > Ich spreche davon, auf welchem Rechner Du den Code erzeugen möchtest, > den der Simlulator, der mit clang++ kompiliert wurde, abarbeiten soll. > > So wie es aussieht, willst Du also avr-gcc auf einem anderen Rechner > laufen lassen. Ist ja auch ok. Warum? Was hat avr-gcc damit zu tun, wie er den Simulator übersetzt? avr-gcc hat erst mal nichts mit dem gcc für den Host zu tun, also warum soll er da einen gcc für den Host brauchen, um dann die AVR-Programme mit avr-gcc übersetzen können?
Rolf M. schrieb: > Warum? Ich dachte nur, wer schon die Prerequisites von simulavr nicht lesen kann ... Rolf M. schrieb: > also warum > soll er da einen gcc für den Host brauchen, Weil das in den Prerequisites von simulavr steht.
Wilhelm M. schrieb: > Rolf M. schrieb: >> Warum? > > Ich dachte nur, wer schon die Prerequisites von simulavr nicht lesen > kann ... avr-gcc hat nichts mit den Prerequisites von simulavr zu tun. > Rolf M. schrieb: >> also warum soll er da einen gcc für den Host brauchen, > > Weil das in den Prerequisites von simulavr steht. Ja, das ist natürlich ein guter Grund. Nur das hier: Wilhelm M. schrieb: > gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit > AVR arbeiten möchtest. denn der clang hat kein AVR-backend. klang eher, als meintest du, man bräuchte zum Bauen von AVR-Programmen auch einen gcc für den Host. Und das auch: Wilhelm M. schrieb: > So wie es aussieht, willst Du also avr-gcc auf einem anderen Rechner > laufen lassen. Warum sollte er avr-gcc nicht auf dem selben Rechner laufen lassen können, nur weil er dort keinen Host-gcc installiert hat?
:
Bearbeitet durch User
Rolf M. schrieb: > klang eher, als meintest du, man bräuchte zum Bauen von AVR-Programmen > auch einen gcc für den Host. Und das auch: Habe ich aber nicht so gesagt. Rolf M. schrieb: > Warum sollte er avr-gcc nicht auf dem selben Rechner laufen lassen > können, nur weil er dort keinen Host-gcc installiert hat? Es ist m.E. praktisch, beide Varianten host/cross desselben Compilers zu haben, damit man weder bei den Optionen noch bei sonstigen "Dingen" umdenken musst. Denn auf dem host ist man ggf. mit dem Testen / Probieren schneller und einfacher zugange, als auf dem µC / Simulator. Aber das war auch nur eine Vermutung ... ist daher auch nicht wichtig.
:-) ..kriegt Ihr Euch nun wieder ein? Freilich habe ich auf dem Rechner auch den avr-gcc nebst der gesamten restlichen Entwicklungsumgebung wie binutils und avr-libc, nur brauche ich die für mein Vorhaben simulavr auf dem Host laufen zu lassen überhaupt nicht und das war auch nicht Gegenstand meiner Anfrage hier. Gruß, Holm
Wilhelm M. schrieb: > Es ist m.E. praktisch, beide Varianten host/cross desselben Compilers zu > haben, damit man weder bei den Optionen noch bei sonstigen "Dingen" > umdenken musst. Denn auf dem host ist man ggf. mit dem Testen / > Probieren schneller und einfacher zugange, als auf dem µC / Simulator. ...nö. Ich habe verschiedene Compiler für den Host, aber nur avr-gcc für das Target. Das selbe Compiler-Verhalten wirds sowieso nicht, schon wegen 8 vs. 64 Bit. > > Aber das war auch nur eine Vermutung ... ist daher auch nicht wichtig. Exakt. Gruß, Holm
holm schrieb: > :-) > > ..kriegt Ihr Euch nun wieder ein? Wer wird denn hier gleich ... Mmh? > > Freilich habe ich auf dem Rechner auch den avr-gcc nebst der gesamten > restlichen Entwicklungsumgebung wie binutils und avr-libc, Du toller Hecht > ich die für mein Vorhaben simulavr auf dem Host laufen zu lassen > überhaupt nicht und das war auch nicht Gegenstand meiner Anfrage hier. Das hat doch auch nun wirklich keiner behauptet. Lies doch Mal die Beträge!
:
Bearbeitet durch User
holm schrieb: > nur brauche ich die für mein Vorhaben simulavr auf dem Host laufen zu > lassen überhaupt nicht Und das ist ja genau das, was ich auch geschrieben hab. Wilhelm M. schrieb: > Das hat doch auch nun wirklich keiner behauptet. Lies doch Mal die > Beträge! Du hast allerdings den avr-gcc ins Spiel gebracht, da der clang ja gar kein AVR-Backend hat. Das ist für die Frage aber überhaupt nicht relevant, da es - ich weiß, ich wiederhole mich - nichts damit zu tun hat, wie der simulavr übersetzt wird.
Wilhelm M. schrieb: > Du toller Hecht Jetzt möchte ich aber auch die Definition für Deine Person von Dir wissen. > >> ich die für mein Vorhaben simulavr auf dem Host laufen zu lassen >> überhaupt nicht und das war auch nicht Gegenstand meiner Anfrage hier. > > Das hat doch auch nun wirklich keiner behauptet. Lies doch Mal die > Beträge! Ich denke schon das ich die Beiträge hier gelesen habe und wie ich auch sind noch mehr Leute der Meinung das Dein Vorschlag zwar sicher irgendwie nett gemeint, aber leider völlig irrelevant für mein Problem ist. Ich verstehe nicht was Du eigentlich von mir willst und warum Du von mir willst das ich einen avr-gcc auff dem Host und auf dem AVR zu verwenden hätte. Die Zeiten sind vorbei das FreeBSD den GCC für den Host verwendet, ich habe ohne Kopfstände gar nicht die Chance das zu tun was Du von mir willst. Simularv kann ich frfeilich mit einem GCC kompilieren, ich kann auch die dafür erforderlichen Libraries erzeugen...aber warum zum Teufel sollte ich das tun? Ein Compiler der gut genug für FreeBSD, X11 und Gnome ist, sollte auch in der Lage sein simulavr zu übersetzen und zwar so wohl auf FreeBSD als auch auf MacOsX. Gruß, Holm
Rolf M. schrieb: > Du hast allerdings den avr-gcc ins Spiel gebracht, da der clang ja gar > kein AVR-Backend hat. Oh je Leute, Leute, Leute ... Genau aus diesem Grunde habe ich den ins Spiel gebracht. > Das ist für die Frage aber überhaupt nicht > relevant, da es - ich weiß, ich wiederhole mich - nichts damit zu tun > hat, wie der simulavr übersetzt wird. Das habt ihr doch in meine Aussage reininterpretiert, gesagt / gemeint habe ich es nicht (s.o.) Und den Grund, warum ich den gcc neben dem avr-gcc ins Spiel gebracht habe, habe ich oben auch erläutert. Jetzt müsste es euch doch Mal klar sein, oder?
Ich habe ein Problem mit der Bremse bei einem Ford. Du antwortest ich sollte mir doch einen Opel kaufen, weil man damit in eine Opelwerkstatt fahren kann. Ungeachtet der Tatsache das ich da gar nicht hin will und es das Problem mit meiner Bremse auch nicht löst, erklärst Du das der Opel trotzdem eine gute Idee sei, weil Dein Kumpel Werner auch einen hat und auch er damit in die Opelwerkstatt fahren kann. Nachdem nun auch schon andere Leute angedeutet hatten das sie Deine Logik nicht verstehen, fängst Du an grantig zu werden und dich zu ärgern warum Niemand verstehen will das man unbedingt in eine Opelwerkstatt fahren können muß... ..mach mal mit Deinem Kumpel alleine weiter, Opelwerkstattfahrten interessieren mich gerade nicht besonders. Gruß, Holm
Das clang/llvm kein AVR-Backend haben stimmt so nicht. Das Backend ist zwar experimentel, aber es ist vorhanden.
holm schrieb: > Ich verstehe nicht was Du eigentlich von mir willst und warum Du von mir > willst das ich einen avr-gcc auff dem Host und auf dem AVR zu verwenden > hätte. Ich will gar nichts von Dir. Doch glaube ich nach wie vor, dass Du den avr-gcc auf Deinem host brauchst. Oder arbeitest Du tatsächlich mit dem experimentellen avr-backend des clang? Und dass Du den avr-gcc auf dem AVR verwenden sollst, habe ich nun wirklich nicht gesagt. Also bitte, verdehe hier nicht die Aussagen. Gesagt habe ich folgendes: Wilhelm M. schrieb: > holm schrieb: >> oder >> ich muß mir einen gcc installieren mit dem ich das c++ Zeuch durchdrehe > > gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit > AVR arbeiten möchtest. denn der clang hat kein AVR-backend. Und zwar aus genau zwei Gründen: 1) Du möchtest simulavr compilieren, für das gcc als prerequisite angegeben ist. 2) Du möchstest AVR-Code erzeugen und im simulavr simuliert ablaufen lassen. Verstehst Du nun meine Aussage?
Wilhelm M. schrieb: > 1) Du möchtest simulavr compilieren, für das gcc als prerequisite > angegeben ist. > 2) Du möchstest AVR-Code erzeugen und im simulavr simuliert ablaufen > lassen. Wer sagt, dass der TO AVR-Code auf demselben Host erzeugen will, wo er auch den simulavr compiliert hat?
Frank M. schrieb: > Wilhelm M. schrieb: >> 1) Du möchtest simulavr compilieren, für das gcc als prerequisite >> angegeben ist. >> 2) Du möchstest AVR-Code erzeugen und im simulavr simuliert ablaufen >> lassen. > > Wer sagt, dass der TO AVR-Code auf demselben Host erzeugen will, wo er > auch den simulavr compiliert hat? Zuletzt der TO. Anfänglich hatte ich auch Deine Vermutung: s.o.: Beitrag "Re: keine Ahnung von C++.aber Problem.."
Frank M. schrieb: > Wer sagt, dass der TO AVR-Code auf demselben Host erzeugen will, wo er > auch den simulavr compiliert hat? Selbst wenn: warum muss deshalb der Hostcompiler dann auch unbedingt ein GCC sein? FreeBSD kommt nun einmal standardmäßig mit Clang daher. Beide Compiler (Host vs. AVR als Target) haben miteinander doch rein gar nichts zu tun. @Holm: du kannst sowas ruhig auch auf deren Mailingliste fragen. So völlig inaktiv sind die Jungs nicht, auch wenn es zu großen Teilen zu einer One-Man-Show mutiert zu sein scheint. Gerade das mit dem ::bind wäre einen Bugreport wert. Über diesen tr1-Kram bin ich auch schon gestolpert, aber den Zusammenhang kenne ich nicht mehr. Könnte man aber auch dort auf der Liste fragen, denn das hat nun mit GCC vs. Clang praktisch nichts mehr zu tun.
:
Bearbeitet durch Moderator
42 schrieb: > holm schrieb: >> Was kann ich hier tun? > > Am besten C++ lernen. ...nein. Ich brauche den Unfug eher nicht. Die Tatsache das ich manchmal einen Maler oder Klemptner beötige, bedeutet nicht, das ich selber Maler und Klemptner sein muß. (auch wenn das in Fakt so ist, also blödes Beispiel, ich gebs zu) Gruß, Holm
Wilhelm M. schrieb: > holm schrieb: >> Ich verstehe nicht was Du eigentlich von mir willst und warum Du von mir >> willst das ich einen avr-gcc auff dem Host und auf dem AVR zu verwenden >> hätte. > > Ich will gar nichts von Dir. Sehr schön. > > Doch glaube ich nach wie vor, dass Du den avr-gcc auf Deinem host > brauchst. Oder arbeitest Du tatsächlich mit dem experimentellen > avr-backend des clang? Ist Dein Glaube offiziell als Kirche anerkannt und genießt Religionsfreiheit? > > Und dass Du den avr-gcc auf dem AVR verwenden sollst, habe ich nun > wirklich nicht gesagt. Also bitte, verdehe hier nicht die Aussagen. Höre doch einfach auf Käse zu erzählen der keine Sau interessiert. > > Gesagt habe ich folgendes: > > Wilhelm M. schrieb: >> holm schrieb: >>> oder >>> ich muß mir einen gcc installieren mit dem ich das c++ Zeuch durchdrehe >> >> gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit >> AVR arbeiten möchtest. denn der clang hat kein AVR-backend. Das mag in meinem Fall so sein. Es ist aber auch sinnvoll das ich eine Tastatur, ne Maus und ein Display an meinem Computer habe, weil ich ab und an mal dieses Ding benutzen möchte. Wollen wir drüber reden? > > Und zwar aus genau zwei Gründen: > > 1) Du möchtest simulavr compilieren, für das gcc als prerequisite > angegeben ist. Stell Dir mal vor, ich habs compiliert..ohne gcc. > 2) Du möchstest AVR-Code erzeugen und im simulavr simuliert ablaufen > lassen. Nein, das möchte ich nicht. Ich möchte die Quellen des simulavr übersetzen, schrub ich doch oben. Selbst wenn ich das wollen würde, bedeutet das immer noch nicht das ich einen avr-gcc haben muß, denn ich kann auch Code aus irgend einem Assembler (IAR?) da debuggen und deinen AVR simulieren, ich benötige dann keinen gcc. > > Verstehst Du nun meine Aussage? Nein. Wenn Du über Deine eigenen Probleme reden möchtest, mach doch einfach einen Thread auf und beschreibe Dein Problem. Anmerken möchte ich noch das Du mir langsam auf den Wecker fällst. Gruß, Holm
Wilhelm M. schrieb: > holm schrieb: >> Ich verstehe nicht was Du eigentlich von mir willst und warum Du von mir >> willst das ich einen avr-gcc auff dem Host und auf dem AVR zu verwenden >> hätte. > > Ich will gar nichts von Dir. Sehr schön. > > Doch glaube ich nach wie vor, dass Du den avr-gcc auf Deinem host > brauchst. Oder arbeitest Du tatsächlich mit dem experimentellen > avr-backend des clang? Ist Dein Glaube offiziell als Kirche anerkannt und genießt Religionsfreiheit? > > Und dass Du den avr-gcc auf dem AVR verwenden sollst, habe ich nun > wirklich nicht gesagt. Also bitte, verdehe hier nicht die Aussagen. Höre doch einfach auf Käse zu erzählen der keine Sau interessiert. > > Gesagt habe ich folgendes: > > Wilhelm M. schrieb: >> holm schrieb: >>> oder >>> ich muß mir einen gcc installieren mit dem ich das c++ Zeuch durchdrehe >> >> gcc/g++ und auch avr-gcc/avr-g++ wären ja wohl eh sinnvoll, wenn Du mit >> AVR arbeiten möchtest. denn der clang hat kein AVR-backend. Das mag in meinem Fall so sein. Es ist aber auch sinnvoll das ich eine Tastatur, ne Maus und ein Display an meinem Computer habe, weil ich ab und an mal dieses Ding benutzen möchte. Wollen wir drüber reden? > > Und zwar aus genau zwei Gründen: > > 1) Du möchtest simulavr compilieren, für das gcc als prerequisite > angegeben ist. Stell Dir mal vor, ich habs compiliert..ohne gcc. > 2) Du möchstest AVR-Code erzeugen und im simulavr simuliert ablaufen > lassen. Nein, das möchte ich nicht. Ich möchte die Quellen des simulavr übersetzen, schrub ich doch oben. Selbst wenn ich das wollen würde, bedeutet das immer noch nicht das ich einen avr-gcc haben muß, denn ich kann auch Code aus irgend einem Assembler (IAR?) da debuggen und deinen AVR simulieren, ich benötige dann keinen gcc. > > Verstehst Du nun meine Aussage? Nein. Wenn Du über Deine eigenen Probleme reden möchtest, mach doch einfach einen Thread auf und beschreibe Dein Problem. Anmerken möchte ich noch das Du mir langsam auf den Wecker fällst. Gruß, Holm Jörg W. schrieb: > @Holm: du kannst sowas ruhig auch auf deren Mailingliste fragen. So > völlig inaktiv sind die Jungs nicht, auch wenn es zu großen Teilen zu > einer One-Man-Show mutiert zu sein scheint. Gerade das mit dem ::bind > wäre einen Bugreport wert. > > Über diesen tr1-Kram bin ich auch schon gestolpert, aber den > Zusammenhang kenne ich nicht mehr. Könnte man aber auch dort auf der > Liste fragen, denn das hat nun mit GCC vs. Clang praktisch nichts mehr > zu tun. Ich habe mittlerweile gelesen das dieses tr1 Zeug "Technical Report 1" heißt und irgend ein Status zwischen den verschiedenen C++ Standards bedeuted. Konkret das tr1/tuple ist wohl nicht in c++11 eingeflossen, der gcc schleppts aber mit. Für den konkreten Fall ist das Zeug völlig ohne Bedeutung und nur Bestandteil eines in die Sourcen integrierten Regressionstests. Es geht auch völlig ohne diese Tests. Ich werde das mit dem ::bind mal anmeckern. Gruß, Holm
holm schrieb: > Ist Dein Glaube offiziell als Kirche anerkannt und genießt > Religionsfreiheit? Wenn einem nix mehr einfällt, wird man ausfällig ;-) BTW: ja, sie ist es. holm schrieb: > Selbst wenn ich das wollen würde, bedeutet das immer noch nicht das ich > einen avr-gcc haben muß, denn ich kann auch Code aus irgend einem > Assembler (IAR?) da debuggen und deinen AVR simulieren, ich benötige > dann keinen gcc. Ja, dann sag es doch gleich ohne Umschweife (s.a. meine Frage weiter oben dazu.) holm schrieb: > Konkret das tr1/tuple ist wohl nicht in c++11 eingeflossen, > der gcc schleppts aber mit. Nein. Ist seit C++11 drin.
Wilhelm M. schrieb: > holm schrieb: >> Ist Dein Glaube offiziell als Kirche anerkannt und genießt >> Religionsfreiheit? > > Wenn einem nix mehr einfällt, wird man ausfällig ;-) > > BTW: ja, sie ist es. > > holm schrieb: >> Selbst wenn ich das wollen würde, bedeutet das immer noch nicht das ich >> einen avr-gcc haben muß, denn ich kann auch Code aus irgend einem >> Assembler (IAR?) da debuggen und deinen AVR simulieren, ich benötige >> dann keinen gcc. > > Ja, dann sag es doch gleich ohne Umschweife (s.a. meine Frage weiter > oben dazu.) > > holm schrieb: >> Konkret das tr1/tuple ist wohl nicht in c++11 eingeflossen, >> der gcc schleppts aber mit. > > Nein. Ist seit C++11 drin. Wilhelm M. schrieb: > holm schrieb: >> Ist Dein Glaube offiziell als Kirche anerkannt und genießt >> Religionsfreiheit? > > Wenn einem nix mehr einfällt, wird man ausfällig ;-) Jawoll, das beschwehrt sich der, der mich "Toller Hecht" nannte. > > BTW: ja, sie ist es. Na dann erzähle mal, jetzt bin ich neigierig was es für eine eingetragene Religion hinsichtlich avr-gcc gibt. > > holm schrieb: >> Selbst wenn ich das wollen würde, bedeutet das immer noch nicht das ich >> einen avr-gcc haben muß, denn ich kann auch Code aus irgend einem >> Assembler (IAR?) da debuggen und deinen AVR simulieren, ich benötige >> dann keinen gcc. > > Ja, dann sag es doch gleich ohne Umschweife (s.a. meine Frage weiter > oben dazu.) Das erzähle ich Dir seit gefühlten 10 Postings das Du auf einer völlig falschen Baustelle herumbuddelst. Höre einfach auf mir mit Deinem Gesülze auf den Wecker zu fallen, ich habe Dich niemals drum gebeten. > > holm schrieb: >> Konkret das tr1/tuple ist wohl nicht in c++11 eingeflossen, >> der gcc schleppts aber mit. > > Nein. Ist seit C++11 drin. Wo steht im C++11 Standard was von "tr1/tuple"? ..konkreten Link bitte. Gruß, Holm
holm schrieb: > Das erzähle ich Dir seit gefühlten 10 Postings das Du auf einer völlig > falschen Baustelle herumbuddelst. Du hast bis jetzt noch nicht konkret geantwortet. Du benutzt immer noch den Konjunktiv. ;-)
holm schrieb: > Wo steht im C++11 Standard was von "tr1/tuple"? > ..konkreten Link bitte. Der Titel des Beitrages sagt eigentlich schon alles: Du hast weder Ahnung von C++ noch vom Standardisierungsprozeß von C oder C++. https://en.cppreference.com/w/cpp/utility/tuple Man achte auf den Zusatz: since C++11
Wilhelm M. schrieb: > https://en.cppreference.com/w/cpp/utility/tuple > > Man achte auf den Zusatz: since C++11 Man beachte aber auch, dass die Zeichenkombination "tr1" dort gar nicht vorkommt. Es ging nicht um std::tuple, sondern um std::tr1::tuple, denn um genau das drehte sich der Fehler aus dem obigen Posting. Ein std::tr1::tuple gibt es in C++11 nicht.
:
Bearbeitet durch User
Rolf M. schrieb: > Wilhelm M. schrieb: >> https://en.cppreference.com/w/cpp/utility/tuple >> >> Man achte auf den Zusatz: since C++11 > > Man beachte aber auch, dass die Zeichenkombination "tr1" dort gar nicht > vorkommt. Es ging nicht um std::tuple, sondern um std::tr1::tuple, denn > um genau das drehte sich der Fehler aus dem obigen Posting. Ein > std::tr1::tuple gibt es in C++11 nicht. Also: der TO compiliert die Sourcen von simulavr (aus welchen Gründen auch immer) mit dem Flag -std=c++11. Wenn das so upstream bei simulavr drin ist, passt diese Option einfach nicht zum Source-Code. Es stellt sich also die Frage: warum kompiliert man einen Source-Code, der nicht C++11 ist, weil er tr1 verwendet, als C++11-Code?
Wilhelm M. schrieb: > Es stellt sich also die Frage: warum kompiliert man einen Source-Code, > der nicht C++11 ist, weil er tr1 verwendet, als C++11-Code? Deshalb ja auch meine Empfehlung, dass er sich mit den simulavr-Machern in Verbindung setzt. Vielleicht sollten die ja einfach mal das tr1 da entfernen, schließlich ist das nun schon einige Jahre lang im Standard. Allerdings bin ich mir nicht ganz im Klaren, ob der tr1-Kram nicht eventuell von irgendeinem Codegenerator emittiert wird (ich lese da was von "gtest"), den man ggf. einfach nur mal aktualisieren müsste. Dazu stecke ich in simulavr zu wenig drin. Auch da sollten aber die simulavr-Autoren helfen können.
:
Bearbeitet durch Moderator
Rolf M. schrieb: > Wilhelm M. schrieb: >> https://en.cppreference.com/w/cpp/utility/tuple >> >> Man achte auf den Zusatz: since C++11 > > Man beachte aber auch, dass die Zeichenkombination "tr1" dort gar nicht > vorkommt. Es ging nicht um std::tuple, sondern um std::tr1::tuple, denn > um genau das drehte sich der Fehler aus dem obigen Posting. Ein > std::tr1::tuple gibt es in C++11 nicht. Genau. deswegen fragte ich auch explizit nach der Referenz für tr1/tuple in c++11. Gruß, Holm
Jörg W. schrieb: > Wilhelm M. schrieb: >> Es stellt sich also die Frage: warum kompiliert man einen Source-Code, >> der nicht C++11 ist, weil er tr1 verwendet, als C++11-Code? > > Deshalb ja auch meine Empfehlung, dass er sich mit den simulavr-Machern > in Verbindung setzt. Vielleicht sollten die ja einfach mal das tr1 da > entfernen, schließlich ist das nun schon einige Jahre lang im Standard. Vielleicht sollte jemand mal nachsehen, ob dieses -std=c++11 tatsächlich in den Sourcen von simulavr drin steht. Da melde ich mal Zweifel an ...
Wilhelm M. schrieb: > Rolf M. schrieb: >> Wilhelm M. schrieb: >>> https://en.cppreference.com/w/cpp/utility/tuple >>> >>> Man achte auf den Zusatz: since C++11 >> >> Man beachte aber auch, dass die Zeichenkombination "tr1" dort gar nicht >> vorkommt. Es ging nicht um std::tuple, sondern um std::tr1::tuple, denn >> um genau das drehte sich der Fehler aus dem obigen Posting. Ein >> std::tr1::tuple gibt es in C++11 nicht. > > Also: der TO compiliert die Sourcen von simulavr (aus welchen Gründen > auch immer) mit dem Flag -std=c++11. Aus dem Grund gelesen zu haben das tuple in c++11 enthalten ist, das war nur ein Test. > > Wenn das so upstream bei simulavr drin ist, passt diese Option einfach > nicht zum Source-Code. ..und ist ein absoluter Nebenschauplatz den Du jetzt ausgräbst, nur um weiterhin lamentieren zu können. Erinnerung: Dir gings um den avr-gcc den ich unbedingt haben müsse, nicht um c++1 oder tr1/tuple. Höre doch endlich auf rumzurudern. Da ist nichts weiter als Belästigung. Ich hatte weiter oben schon geschrieben das ich das Programm erfolgreich compiliert habe und es arbeitet wie erwartet. > > Es stellt sich also die Frage: warum kompiliert man einen Source-Code, > der nicht C++11 ist, weil er tr1 verwendet, als C++11-Code? Die Frage stellt sich eigentlich nicht. Die Frage stellst Du Dir, mach einen eigenen Thread dazu auf, denn das hier ist meiner. Gruß, Holm
Jörg wie stehts mit dem "lesenswert"? hab ich wieder -95 und wilhelm +47? Gruß, Holm
holm schrieb: > Aus dem Grund gelesen zu haben das tuple in c++11 enthalten ist, das war > nur ein Test. Wilhelm M. schrieb: > Vielleicht sollte jemand mal nachsehen, ob dieses -std=c++11 tatsächlich > in den Sourcen von simulavr drin steht. Da melde ich mal Zweifel an ... Na Bingo. Warum sagst Du das nicht gleich, dass Du das da eingebaut hast. Oh man ...
holm schrieb: > Ich hatte weiter oben schon geschrieben das ich das Programm erfolgreich > compiliert habe und es arbeitet wie erwartet. Dennoch wäre es sinnvoll, wenn du zumindest das ::bind() mal zu den Autoren zurück beamst, denn das halte ich für einen waschechten Bug. Nach dem tr1 könntest du bei der Gelegenheit halt auch mal nerven. Habe mein simulavr mal aktualisiert, das steht da tatsächlich direkt in den Quellen so drin, aber der Code sieht automatisch generiert aus (Google C++ test framework ist der "Autor" des Codes), müsste also wohl mal neu generiert werden.
Wilhelm M. schrieb: > holm schrieb: >> Aus dem Grund gelesen zu haben das tuple in c++11 enthalten ist, das war >> nur ein Test. > > Wilhelm M. schrieb: >> Vielleicht sollte jemand mal nachsehen, ob dieses -std=c++11 tatsächlich >> in den Sourcen von simulavr drin steht. Da melde ich mal Zweifel an ... > > Na Bingo. > Warum sagst Du das nicht gleich, dass Du das da eingebaut hast. Oh man > ... Warum sollte ich? Um Deine nächste Frage zu beantworten: Im Nettomarkt in FG, auch bekannt als "Machetennetto" gibts Kartoffeln. Gruß, Holm
Jörg ich habs versucht. Um ein Bug zu reporten muß man sich registrieren, auch das habe ich versucht. Allerdings bin ich 5 mal mit meinen paßworten gescheitert, danach habe ich gelesen was die von mir wollen: Note: The password should be long enough or containing multiple character classes: symbols, digits (0-9), upper and lower case letters. For instance: plague3lovely5Ritual. pwqcheck options are 'match=0 max=256 min=24,24,11,8,7': The maximum allowed password length: 256. Checks for common substrings are disabled. The minimum length for passwords consisting of characters from one class: 24. The minimum length for passwords consisting of characters from two classes that don't meet requirements for passphrases: 24. The minimum length for passphrases: 11. The minimum length for passwords consisting of characters from three classes: 8. The minimum length for passwords consisting of characters from four classes: 7. ..jetzt habe ich keine Lust mehr. Gruß, Holm
holm schrieb: > Um ein Bug zu reporten Ich schrieb was von Mailingliste. Das ist'n normaler Mailman, da gibt's keinen großartigen Passwort-Zirkus. ps: holm schrieb: > The minimum length for passwords consisting of characters from one > class: 24. Immerhin, andere gestatten das gar nicht (nur eine "character class"). Das heißt, dass du auch sowas wie "heut ist ein wunderschoener tag" als Passwort nehmen kannst. :)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > holm schrieb: >> Um ein Bug zu reporten > > Ich schrieb was von Mailingliste. Das ist'n normaler Mailman, da gibt's > keinen großartigen Passwort-Zirkus. Egal. Es wäre nicht weniger aufwendig gewesen. https://savannah.nongnu.org/bugs/index.php?57430 Ich habe versucht das neu ein 2. Mal zu kompilieren, kann aber das Repository nicht ziehen, deren git server ist gerade kaputt, deswegen gibts nur ne Umschreibung. > > ps: > > holm schrieb: >> The minimum length for passwords consisting of characters from one >> class: 24. > > Immerhin, andere gestatten das gar nicht (nur eine "character class"). > Das heißt, dass du auch sowas wie "heut ist ein wunderschoener tag" als > Passwort nehmen kannst. :) Ja ganz toll. Die Leute vergessen einfach das das Menschen dahinter stecken die sich den Scheiß auch noch merken können sollen. Ich brauche vier unterschiedlich lange "Zugangscodes" und "Pins" um mein Konto zu bedienen nebst Tatsche, alles gaaaaanz sicher, sind die bescheuert? 2 Faktor Huckauf, bei der EU "arbeiten" nur noch Idioten. Ich habe bc pi generieren lassen, pi kann ich mir merken :-) Wenn jetzt Jemand mit der Info meinen Account da aufmacht in dem er die Anzahl der Stellen ausprobiert..bitteschön. Für den Aufwand gebe ich meinen Account gerne ab. Ich denke ich war das letzte Mal da. Gruß, Holm
holm schrieb: > Egal. Es wäre nicht weniger aufwendig gewesen. Bisschen schon - aber wie du sagst: egal. > Ich habe versucht das neu ein 2. Mal zu kompilieren, kann aber das > Repository nicht ziehen, deren git server ist gerade kaputt, deswegen > gibts nur ne Umschreibung. Keine Ahnung, was du da für'n Problem hast, aber hier ist der aktuelle git-Stand. Vorhin gerade ein "git pull" gemacht. (Ich habe aber vermutlich bei denen noch einen developer-Zugang und darf das Repo mit ssh ziehen.) > Ja ganz toll. Die Leute vergessen einfach das das Menschen dahinter > stecken die sich den Scheiß auch noch merken können sollen. Die meisten Leute lassen sowas wohl entweder den Browser oder einen Passwortmanager merken.
Jörg W. schrieb: > holm schrieb: > >> Egal. Es wäre nicht weniger aufwendig gewesen. > > Bisschen schon - aber wie du sagst: egal. > >> Ich habe versucht das neu ein 2. Mal zu kompilieren, kann aber das >> Repository nicht ziehen, deren git server ist gerade kaputt, deswegen >> gibts nur ne Umschreibung. > > Keine Ahnung, was du da für'n Problem hast, aber hier ist der aktuelle > git-Stand. Vorhin gerade ein "git pull" gemacht. (Ich habe aber > vermutlich bei denen noch einen developer-Zugang und darf das Repo mit > ssh ziehen.) > Das was gestern noch ging sah vorhin so aus: $ git clone https://git.savannah.nongnu.org/git/simulavr.git Cloning into 'simulavr'... fatal: unable to access 'https://git.savannah.nongnu.org/git/simulavr.git/';: The requested URL returned error: 502 ..auf deren Webseite das Browse lief auf den selben Fehler. >> Ja ganz toll. Die Leute vergessen einfach das das Menschen dahinter >> stecken die sich den Scheiß auch noch merken können sollen. > > Die meisten Leute lassen sowas wohl entweder den Browser oder einen > Passwortmanager merken. Jepp..und das ist dann "sicher"? ...aber klar doch. Du kannst mich jetzt noch mit Vielem agitieren was ich selber weiß. Aber: Ein PC der meine Paßwörter verwaltet ist ein Sicherheitsrisiko auf meiner Seite. Ein Handy dessen bescheuerte App ich zwingend benötige um an mein Konto zu kommen, ist ein Sicherheitsrisiko auf meiner Seite. Jedes Paßwort das ich mir selbst nicht merken kann, also irgendwo ablegen muß, ist ein Sicherheitsrisiko. Ergo: die ganzen tollen Lösungen sind glatt für den Arsch. Gruß, Holm
holm schrieb: > Das was gestern noch ging sah vorhin so aus: > $ git clone https://git.savannah.nongnu.org/git/simulavr.git > Cloning into 'simulavr'... > fatal: unable to access > 'https://git.savannah.nongnu.org/git/simulavr.git/';: The requested URL > returned error: 502 Also irgendwas auf dem Webserver. Dann nimm das, was ich da oben angehängt habe. Du wirst nur kein weiteres "git pull" darin machen können, weil die remote-Seite auf meinen Account auf Savannah zeigt. >> Die meisten Leute lassen sowas wohl entweder den Browser oder einen >> Passwortmanager merken. > > Jepp..und das ist dann "sicher"? Nö, hat doch keiner behauptet. Sicherer als überall dasselbe ist es aber vermutlich.
Jörg W. schrieb: > holm schrieb: > >> Das was gestern noch ging sah vorhin so aus: >> $ git clone https://git.savannah.nongnu.org/git/simulavr.git >> Cloning into 'simulavr'... >> fatal: unable to access >> 'https://git.savannah.nongnu.org/git/simulavr.git/';;: The requested URL >> returned error: 502 > > Also irgendwas auf dem Webserver. Dann nimm das, was ich da oben > angehängt habe. Du wirst nur kein weiteres "git pull" darin machen > können, weil die remote-Seite auf meinen Account auf Savannah zeigt. Ehe ich das nochmal veranstalte, warte ich ab was mit dem passiert was ich denen da vor die Füße geworfen habe. Es sollte reichen die Fhler zu beheben..wenn man denn möchte. > >>> Die meisten Leute lassen sowas wohl entweder den Browser oder einen >>> Passwortmanager merken. >> >> Jepp..und das ist dann "sicher"? > > Nö, hat doch keiner behauptet. Aha. >Sicherer als überall dasselbe ist es aber > vermutlich. Warum implizierst du das ich mich wie ein Trottel im Internet bewege? Gruß, Holm
Nen (guter) Passwortmanager ist mindestens genauso sicher, wie Passwörter jedes mal per Hand einztippen, wenn sie benötigt werden. Wenn jemand an den Passwortmanager kommt, kommt er auch an die anderen Programme.
mh schrieb: > Nen (guter) Passwortmanager ist mindestens genauso sicher, wie > Passwörter jedes mal per Hand einztippen, wenn sie benötigt werden. Wenn > jemand an den Passwortmanager kommt, kommt er auch an die anderen > Programme. Ja..hab ich schon mal gehört. Ich fasse für Dich zusammen: "die ganzen tollen Lösungen sind glatt für den Arsch." Send End zu dem Thema, ich weiß es einfach besser. Gruß, Holm
holm schrieb: > Warum implizierst du das ich mich wie ein Trottel im Internet bewege? Bist du dir sicher, dass du nicht etwas in seine Aussage "implizierst", nicht andersrum? Wenn er es implizieren würde, ist dein Auftreten in diesem Thread eine nachvollziehbare Ursache.
...ein :.,$s/tr1:://g über diese angemeckerten gtest files führt dazu das die sich auch übersetzen lassen. Gruß, Holm
holm schrieb: > über diese angemeckerten gtest files führt dazu das die sich auch > übersetzen lassen. Das wundert mich jetzt nicht. :-) Da diese Teile allerdings generiert worden sind, hielte ich es für sinnvoller, wenn man das Problem an der Quelle behebt, sprich, eine neuere Version des Generators benutzt. Der sollte dann hoffentlich wissen, dass die Tupels mittlerweile im Standard angekommen sind und man keine obskuren Namensräume mehr bemühen muss, um sie zu nutzen.
..wußte ich schon, hab ja Deine vorhergehenden Posts gelesen, habs aber trotzdem ausprobiert. Der kaputte Webserver tut auch wieder. Gruß, Holm
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.