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:> 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?
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
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:
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.
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.
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
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?
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!
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
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.
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.
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.
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
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. :)
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.
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.
