From: Michael M. <mm...@el...> - 2013-01-02 19:44:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also, ich glaub ich bin zu blöd, cmake ist nicht meins oder da gibts noch ne andere Dependency/Version von libs oder so; Ubuntu 12.04, libzmq ist 3.2.2 ausm tarball: - --- cut --- Aktualisiert zu Revision 1285. markstaller@v3750mm:~/devel/openautomation/GrAF/trunk$ cd GrAFd/ markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/GrAFd$ cmake . - -- The C compiler identification is GNU - -- The CXX compiler identification is GNU - -- Check for working C compiler: /usr/bin/gcc - -- Check for working C compiler: /usr/bin/gcc -- works - -- Detecting C compiler ABI info - -- Detecting C compiler ABI info - done - -- Check for working CXX compiler: /usr/bin/c++ - -- Check for working CXX compiler: /usr/bin/c++ -- works - -- Detecting CXX compiler ABI info - -- Detecting CXX compiler ABI info - done - -- Boost version: 1.48.0 - -- Found the following Boost libraries: - -- filesystem - -- system - -- Found zeromq (lib) in: /usr/local/lib/libzmq.so Building type: - -- Found Doxygen: /usr/bin/doxygen - -- Boost version: 1.48.0 - -- Found the following Boost libraries: - -- unit_test_framework - -- Configuring done - -- Generating done - -- Build files have been written to: /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/GrAFd$ make Scanning dependencies of target GrAFd [ 7%] Building CXX object CMakeFiles/GrAFd.dir/src/graphsignal.cpp.o In file included from /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:34:0, from /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:23: /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/logicengine.hpp:59:58: Fehler: a brace-enclosed initializer is not allowed here before »{« token /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/logicengine.hpp:59:91: Fehler: »const« und »constexpr« können hier nicht zusammen verwendet werden In file included from /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:23:0: /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:88:3: Fehler: ein Klassenschlüssel muss bei Deklaration als »friend« verwendet werden /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:88:3: Fehler: »friend«-Deklaration benennt keine Klasse oder Funktion /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:89:3: Fehler: ein Klassenschlüssel muss bei Deklaration als »friend« verwendet werden /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:89:3: Fehler: »friend«-Deklaration benennt keine Klasse oder Funktion /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp: In Lambda-Funktion: /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:115:21: Fehler: »const GraphBlock& Graph::libLookup(const string&) const« ist privat /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:58:61: Fehler: in diesem Zusammenhang /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:105:17: Fehler: »Graph::blockLookup_t Graph::blockLookup« ist privat /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:63:49: Fehler: in diesem Zusammenhang /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:105:17: Fehler: »Graph::blockLookup_t Graph::blockLookup« ist privat /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:63:79: Fehler: in diesem Zusammenhang /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:100:20: Fehler: »Graph::DirecetedGraph_t Graph::g« ist privat /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:63:107: Fehler: in diesem Zusammenhang /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:100:20: Fehler: »Graph::DirecetedGraph_t Graph::g« ist privat /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:64:9: Fehler: in diesem Zusammenhang /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:100:20: Fehler: »Graph::DirecetedGraph_t Graph::g« ist privat /home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:65:9: Fehler: in diesem Zusammenhang make[2]: *** [CMakeFiles/GrAFd.dir/src/graphsignal.cpp.o] Fehler 1 make[1]: *** [CMakeFiles/GrAFd.dir/all] Fehler 2 make: *** [all] Fehler 2 markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/GrAFd$ cd ../logicd/ markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ make make: *** Keine Targets angegeben und keine »make«-Steuerdatei gefunden. Schluss. markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ cma cmake cmap2enc markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ cmake . - -- The C compiler identification is GNU - -- The CXX compiler identification is GNU - -- Check for working C compiler: /usr/bin/gcc - -- Check for working C compiler: /usr/bin/gcc -- works - -- Detecting C compiler ABI info - -- Detecting C compiler ABI info - done - -- Check for working CXX compiler: /usr/bin/c++ - -- Check for working CXX compiler: /usr/bin/c++ -- works - -- Detecting CXX compiler ABI info - -- Detecting CXX compiler ABI info - done - -- Boost version: 1.48.0 - -- Found the following Boost libraries: - -- program_options - -- system Building type: - -- Found zeromq (lib) in: /usr/local/lib/libzmq.so - -- Configuring done - -- Generating done - -- Build files have been written to: /home/markstaller/devel/openautomation/GrAF/trunk/logicd markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ make Scanning dependencies of target client [ 12%] Building CXX object CMakeFiles/client.dir/src/testclient.cpp.o In file included from /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/testclient.cpp:25:0: /home/markstaller/devel/openautomation/GrAF/trunk/logicd/include/message.hpp:474:3: Warnung: diese Dezimalkonstante ist nur in ISO-C90 vorzeichenlos [standardmäßig aktiviert] /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/testclient.cpp:28:5: Warnung: unbenutzter Parameter »argc« [-Wunused-parameter] /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/testclient.cpp:28:5: Warnung: unbenutzter Parameter »argv« [-Wunused-parameter] Linking CXX executable client [ 12%] Built target client Scanning dependencies of target cometvisu2logic [ 25%] Building CXX object CMakeFiles/cometvisu2logic.dir/src/cometvisu2logic.cpp.o In file included from /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:32:0: /home/markstaller/devel/openautomation/GrAF/trunk/logicd/include/message.hpp:474:3: Warnung: diese Dezimalkonstante ist nur in ISO-C90 vorzeichenlos [standardmäßig aktiviert] /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:207:8: Warnung: unbenutzter Parameter »bytes_transferred« [-Wunused-parameter] /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:432:8: Warnung: unbenutzter Parameter »error« [-Wunused-parameter] /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp: In Elementfunktion »void ZMQ_server::handle_read(const boost::system::error_code&)«: /home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:559:15: Warnung: Variable »FIXME_tmp« wird nicht verwendet [-Wunused-variable] Linking CXX executable cometvisu2logic CMakeFiles/cometvisu2logic.dir/src/cometvisu2logic.cpp.o: In function `SCGI_session::handle_read(boost::system::error_code const&, unsigned int)': cometvisu2logic.cpp:(.text._ZN12SCGI_session11handle_readERKN5boost6system10error_codeEj[SCGI_session::handle_read(boost::system::error_code const&, unsigned int)]+0x643): undefined reference to `LogicMessage::invalidIndex' cometvisu2logic.cpp:(.text._ZN12SCGI_session11handle_readERKN5boost6system10error_codeEj[SCGI_session::handle_read(boost::system::error_code const&, unsigned int)]+0x831): undefined reference to `LogicMessage::invalidIndex' collect2: ld gab 1 als Ende-Status zurück make[2]: *** [cometvisu2logic] Fehler 1 make[1]: *** [CMakeFiles/cometvisu2logic.dir/all] Fehler 2 make: *** [all] Fehler 2 - --- cut ---- Any idea? LMGTFY hat nicht funktioniert ;) Makki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDkjfcACgkQaWRHV2kMuAJwdQCgpn7kq2zy8LGezkjDMzoJndJz IIsAoNXoBgscVjWCo9YA72OfLdRQ157T =2rBN -----END PGP SIGNATURE----- |
From: Christian M. <ma...@Ch...> - 2013-01-02 19:58:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 02.01.2013 20:43, schrieb Michael Markstaller: > Also, ich glaub ich bin zu blöd, cmake ist nicht meins oder da > gibts noch ne andere Dependency/Version von libs oder so; Ubuntu > 12.04, libzmq ist 3.2.2 ausm tarball: > > --- cut --- Aktualisiert zu Revision 1285. >> make: *** [all] Fehler 2 > --- cut ---- > > Any idea? LMGTFY hat nicht funktioniert ;) Wie gut, dass ich's vorhin auf meinem extra eingerichtetem, virtuellem 32 Bit Ubuntu LTE (also 12.04) getestet habe :) Die schlechte Nachricht: der GCC (und evtl. auch BOOST, bin mir da aber nicht sicher) ist dort zu alt. Im Code verwende ich ein paar C++11 Konstrukte, die die Compiler ja erst nach und nach umsetzen. Aktuell brauche ich den gcc 4.7 (und eigentlich würde ich auch gerne etwas nutzen, was wohl erst im 4.8 kommt...) => Daher kommt der Fehler Zum Glück kann man aber den 4.8 leicht nachrüsten: deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main deb-src http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main (Bei BOOST habe ich dabei auf die 1.48 aktuallisiert - aber die scheinst Du ja schon zu haben...) Das und die frische Revision 1286 sollte hoffentlich durchlaufen :) Zum bauen habe ich für die Kommando-Zeile noch dieses kleine Skript, dass direkt unter ..../GrAF liegt: *********************** #!/bin/bash cd logicd mkdir Debug cd Debug cmake -DCMAKE_BUILD_TYPE=Debug .. make cd .. mkdir Release cd Release cmake -DCMAKE_BUILD_TYPE=MinSizeRel .. make cd .. cd .. cd GrAFd mkdir Debug cd Debug cmake -DCMAKE_BUILD_TYPE=Debug .. make cd .. mkdir Release cd Release cmake -DCMAKE_BUILD_TYPE=MinSizeRel .. make cd .. *********************** Wenn's mal durchkompiliert, kann ich mal schreiben, was inzwischen gehen sollte - und wie. Noch sind da ein paar Dinge hart codiert bzw. anderes (wie z.B. der lighttpd) muss auch passend konfiguriert werden. CU, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAlDkkXQACgkQoWM1JLkHou2mCQCfXzqGCwn7X21sZAkW2C7qUI41 Eq8An3Snt6BTVMg7V2m5ao7iunfRJhR7 =xrV2 -----END PGP SIGNATURE----- |
From: Michael M. <mm...@el...> - 2013-01-03 00:40:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02.01.2013 20:58, Christian Mayer wrote: > deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise > main deb-src > http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise > main Ah nö Chris, also ich steh ja auch mal gerne auf fummeln aber der will meine libstdc++6 updaten - das gehört echt zu den Punkten, wo ich kein Stoppschild überfahre; sowas macht man nicht, wenn man mit dem System auch nochmal arbeiten will :p Also in ne VM mach ich das mal zum Spass, plötzlich gehts auch, für eine mittelfristige Release-Planung zwischen 2014-2015 wärs aber ehrlichgesagt realistischer wenn sich das mitm gcc 4.6 oder besser 4.4 (squeeze/stable) begnügen könnte.. Also libzmq3.2 und boost kann man - unter grossen schmerzen - backporten (ich meine jetzt auf Ubuntu/Debian stable, nicht lenny/WG..) aber die libstdcpp fasse ich nicht an, weil dann mach ich nen Fork von einer Distro; das ist nicht lustig sowas zu pflegen.. Und erklärt bekommt man das auch niemandem, ich mein ich press mir gcc 4.7 dann halt mal drauf aber jetzt nehmen wir Otto der sich bei der Aktion sein komplettes System lötet, weil er vorher nicht nachsieht das ne ganze Menge seiner SW gegen die "alte" libstdcpp der Distro kompiliert wurden.. Grüsse Makki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlDk0y4ACgkQaWRHV2kMuALIJwCgxnlvP0EgODdDC6SOiKZy6xwH nrMAmP63NgcG8jNFf9BugtJ/5e7BfHA= =kSbN -----END PGP SIGNATURE----- |
From: Christian M. <ma...@Ch...> - 2013-01-03 09:16:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 03.01.2013 01:39, schrieb Michael Markstaller: > On 02.01.2013 20:58, Christian Mayer wrote: >> deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu >> precise main deb-src >> http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise >> main > > Ah nö Chris, also ich steh ja auch mal gerne auf fummeln aber der > will meine libstdc++6 updaten - das gehört echt zu den Punkten, wo > ich kein Stoppschild überfahre; sowas macht man nicht, wenn man mit > dem System auch nochmal arbeiten will :p > > Also in ne VM mach ich das mal zum Spass, plötzlich gehts auch, > für eine mittelfristige Release-Planung zwischen 2014-2015 wärs > aber ehrlichgesagt realistischer wenn sich das mitm gcc 4.6 oder > besser 4.4 (squeeze/stable) begnügen könnte.. Also libzmq3.2 und > boost kann man - unter grossen schmerzen - backporten (ich meine > jetzt auf Ubuntu/Debian stable, nicht lenny/WG..) aber die > libstdcpp fasse ich nicht an, weil dann mach ich nen Fork von einer > Distro; das ist nicht lustig sowas zu pflegen.. > > Und erklärt bekommt man das auch niemandem, ich mein ich press mir > gcc 4.7 dann halt mal drauf aber jetzt nehmen wir Otto der sich bei > der Aktion sein komplettes System lötet, weil er vorher nicht > nachsieht das ne ganze Menge seiner SW gegen die "alte" libstdcpp > der Distro kompiliert wurden.. Ich sehe beide Seiten - aber schaun wir uns das Problem vorher lieber mal genauer an: - - Es kompiliert Out-of-the-Box auf einem [K]Ubuntu 12.10 (nämlich mein Entwicklungssystem). Wird auch in Zukunft so bleiben - was auf einem aktuellen [K]Ubuntu nicht Out-of-the-Box läuft, wird nicht im Code landen (so sehr ich ein std::map.emplace() haben will...) - - Es kompiliert nicht mehr auf dem aktuellen Ubuntu LTS, da 12.04, hier kann man mit o.g. PPA das ganze wieder zum Kompilieren bringen. (Von mir nicht ausprobiert, aber evtl. wäre gcc-snapshot harmloser?) - - Das nächste LTS wird für 14.04 erwartet - da wird's sicher kompilieren und somit bei einem gewünschten Release 2014-2015 auch auf einem LTS Out-of-the-Box laufen => Bei den dicken Kisten sehe ich kein grobes Problem (und wenn man sich eine VirtualBox dafür aufmacht...) Spannend und schwierig wirds auf den Embedded Kisten. Bei neu aufgesetzen (Dirk?) mag man sich drum kümmern können, aber das WireGate z.B. hätte ja nur einen 4.3 im Angebot. Da ist die C++11 Unterstützung aber nur sehr mager: http://gcc.gnu.org/projects/cxx0x.html Da ich in den paar Tagen, seit dem ich C++11-Features nutze, vergessen habe, wie man vorher C++ Code schreiben konnte, würde ich ungerne darauf verzichten - erst recht nicht, bei einem neuen Projekt (d.h. im Grunde genommen, kann man noch gar nichts kaputt machen...). Noch nicht ausprobiert, aber wäre ein "-static-libstdc++" nicht ein gangbarer Kompromiss? D.h. auf einem aktuellen System bauen und das statisch gelinkte Paket für's WireGate anbieten? Klar ist das Binary dann dicker, aber das WireGate sollte das noch locker abkönnen (v.a. da zig fette Perl-Prozesse nicht mehr rumschwirren müssen). Für ganz kleine Systeme ist's aber natürlich kaum eine Lösung... CU, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAlDlTHMACgkQoWM1JLkHou2xuQCfUi7HmzzS+C/8K5zZ1+LxvOOf H4EAni4EU14H9/T0C6ZgRPkn3SQ7vvQo =oP1h -----END PGP SIGNATURE----- |
From: Dirk O. <di...@op...> - 2013-01-03 10:40:34
|
Hallo Chris, > Spannend und schwierig wirds auf den Embedded Kisten. > Bei neu aufgesetzen (Dirk?) mag man sich drum kümmern können, aber das > WireGate z.B. hätte ja nur einen 4.3 im Angebot. Da ist die C++11 > Unterstützung aber nur sehr mager: > http://gcc.gnu.org/projects/cxx0x.html > Da ich in den paar Tagen, seit dem ich C++11-Features nutze, vergessen > habe, wie man vorher C++ Code schreiben konnte, würde ich ungerne > darauf verzichten - erst recht nicht, bei einem neuen Projekt (d.h. im > Grunde genommen, kann man noch gar nichts kaputt machen...). Deine Argumente verstehe ich voll und ganz. Ich hatte letztes Jahr zwar 4.5.x als CrossCompiler benutzt, sollte aber inzwischen auch mit was aktuellerem (also 4.7) gehen. Hängt noch etwas von der zu verwendeten Distro ab. Das müsste ich sowieso mit Makki noch etwas ausfechten. Vor mir aus würde dem 4.7 also nichts im Wege stehen. Problematisch wird es halt auf dem WireGate. Wenn du dann jeden Daemon statisch linken willst dürfte auch einiges zusammen kommen. Ob das dann so der beste Weg ist? Gruß Dirk PS: Chris sorry, meine Liste mit offenen Baustellen ist noch etwas umfangreicher geworden. Bin leider immer noch stiller Mitleser. |
From: Michael M. <mm...@el...> - 2013-01-03 20:55:43
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.01.2013 10:16, Christian Mayer wrote: > Am 03.01.2013 01:39, schrieb Michael Markstaller: >> On 02.01.2013 20:58, Christian Mayer wrote: >>> deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu >>> precise main deb-src >>> http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise >>> main > >> Ah nö Chris, also ich steh ja auch mal gerne auf fummeln aber >> der will meine libstdc++6 updaten - das gehört echt zu den >> Punkten, wo ich kein Stoppschild überfahre; sowas macht man >> nicht, wenn man mit dem System auch nochmal arbeiten will :p > >> Also in ne VM mach ich das mal zum Spass, plötzlich gehts auch, >> für eine mittelfristige Release-Planung zwischen 2014-2015 wärs >> aber ehrlichgesagt realistischer wenn sich das mitm gcc 4.6 oder >> besser 4.4 (squeeze/stable) begnügen könnte.. Also libzmq3.2 und >> boost kann man - unter grossen schmerzen - backporten (ich meine >> jetzt auf Ubuntu/Debian stable, nicht lenny/WG..) aber die >> libstdcpp fasse ich nicht an, weil dann mach ich nen Fork von >> einer Distro; das ist nicht lustig sowas zu pflegen.. > >> Und erklärt bekommt man das auch niemandem, ich mein ich press >> mir gcc 4.7 dann halt mal drauf aber jetzt nehmen wir Otto der >> sich bei der Aktion sein komplettes System lötet, weil er vorher >> nicht nachsieht das ne ganze Menge seiner SW gegen die "alte" >> libstdcpp der Distro kompiliert wurden.. > > Ich sehe beide Seiten - aber schaun wir uns das Problem vorher > lieber mal genauer an: > > - Es kompiliert Out-of-the-Box auf einem [K]Ubuntu 12.10 (nämlich > mein Entwicklungssystem). Wird auch in Zukunft so bleiben - was auf > einem aktuellen [K]Ubuntu nicht Out-of-the-Box läuft, wird nicht im > Code landen (so sehr ich ein std::map.emplace() haben will...) - Es > kompiliert nicht mehr auf dem aktuellen Ubuntu LTS, da 12.04, hier > kann man mit o.g. PPA das ganze wieder zum Kompilieren bringen. > (Von mir nicht ausprobiert, aber evtl. wäre gcc-snapshot > harmloser?) - Das nächste LTS wird für 14.04 erwartet - da wird's > sicher kompilieren und somit bei einem gewünschten Release > 2014-2015 auch auf einem LTS Out-of-the-Box laufen > > => Bei den dicken Kisten sehe ich kein grobes Problem (und wenn > man sich eine VirtualBox dafür aufmacht...) > > Spannend und schwierig wirds auf den Embedded Kisten. Bei neu > aufgesetzen (Dirk?) mag man sich drum kümmern können, aber das > WireGate z.B. hätte ja nur einen 4.3 im Angebot. Da ist die C++11 > Unterstützung aber nur sehr mager: > http://gcc.gnu.org/projects/cxx0x.html Da ich in den paar Tagen, > seit dem ich C++11-Features nutze, vergessen habe, wie man vorher > C++ Code schreiben konnte, würde ich ungerne darauf verzichten - > erst recht nicht, bei einem neuen Projekt (d.h. im Grunde genommen, > kann man noch gar nichts kaputt machen...). > > Noch nicht ausprobiert, aber wäre ein "-static-libstdc++" nicht > ein gangbarer Kompromiss? D.h. auf einem aktuellen System bauen und > das statisch gelinkte Paket für's WireGate anbieten? Klar ist das > Binary dann dicker, aber das WireGate sollte das noch locker > abkönnen (v.a. da zig fette Perl-Prozesse nicht mehr rumschwirren > müssen). Für ganz kleine Systeme ist's aber natürlich kaum eine > Lösung... > > CU, Chris Ok, sorry ich hatte nicht geblickt, das 4.7 default in 12.10 ist (und die eigene Kiste bleibt auf 12.04 weil das geficke bis ich den ganzen Kram mit Dualgrafik usw. hingefummelt hatte brauch ich grad nicht..) Hab jetzt ne frische VM gemacht, irgendwie war die zwischen 12.04 und 12.10.. Sollte also gangbar sein, ich teste nachher mal cross für ARM und MIPS, mal sehen. Das WireGate können wir erstmal aussen vor lassen, da muss ich mir eh was ausdenken, nachdem bereits diverse Backports aus testing laufen wirds eh auf 7.0 hinauslaufen. Und das mit statisch sollte schon irgendwie auch übergänglich gehen.. Grüsse Makki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDl8DoACgkQaWRHV2kMuAKzoQCfYoH3eZrAHbAsSDN9H5sdYKW4 bxIAoMBdkI6ilHj/WhDk/a17bnJIDbN8 =97HF -----END PGP SIGNATURE----- |