native GCC Development-Environment

[daniel3000]

Frage:
Kann man dieses onboard-development-Paket in der letzten verfügbaren Version (März 2011, falls ich nichts übersehen habe) auch noch bedenkenlos im (fast) aktuellen HF7b1 benutzen? Und in künftigen neuen OS-Versionen?

Gruß
Daniel

 

[Granitehead]

Frage:
Kann man dieses onboard-development-Paket in der letzten verfügbaren Version (März 2011, falls ich nichts übersehen habe) auch noch bedenkenlos im (fast) aktuellen HF7b1 benutzen? Und in künftigen neuen OS-Versionen?

Gruß
Daniel

Du musst das OS aus jeden Fall auf eine SD-Karte machen, der NAND ist zu klein. Von dem her würdest du dir beim Versuch nicht dein OS kaputt machen, wenn es nicht kompatibel wäre.

Aber eigentlich sollte es, denke ich, mit sämtlichen Hotfixes laufen, aber wahrscheinlich nicht mehr, wenn es eine nächste "grosse" OS-Version gibt.

 

[daniel3000]

Hi ED,

(edit: ach, das war ja gar nicht ED, die Notification-Email kam bloß von ED... sorry!)

hast Du schon eine Vorstellung davon, wann es eine nächste "große" OS-Version geben wird?

Ich denke, ich versuch's einfach mal.
OS auf SD habe ich eh schon (NAND nutze ich nur zum Testen von Ports auf einem (fast) unmodifizeirten System und zum Erstellen von Voll-Backups inkl. System-SD.)

Viele Grüße,
Daniel

 

[Granitehead]

Also es wird daran gearbeitet, aber ich bin da nicht involviert und weiss weder, was noch zu tun ist noch wie lange das dauert.
Ich schätze genau kann es dir eh niemand sagen, wenn's fertig ist halt.
Wohl in absehbarer Zukunft, aber doch auch nicht allzu bald.

 

[ingoreis]

Nimm doch einfach mein Paket,das geht ganz gut und du hast sogar Qemu schon mit dabei.
Das ist erst nen Monat alt :yes:
Ist ja schließlich auch ne native Entwicklerumgebung :-D

http://forum.gp2x.de/viewtopic.php?f=35&t=13031

 

[jilse]

Frage:
Kann man dieses onboard-development-Paket in der letzten verfügbaren Version (März 2011, falls ich nichts übersehen habe) auch noch bedenkenlos im (fast) aktuellen HF7b1 benutzen? Und in künftigen neuen OS-Versionen?
Daniel

Ich wuesste nicht, was dagegen sprechen sollte. Ich bin aber noch nicht dazu gekommen, daran weiter zu basteln (werde das aber wohl demanechst mal wieder tun, und da ich momentan die HF7Beta drauf habe ...). Das OS muss fuer dieses Paket *nicht* auf SD-Karte installiert sein, solange du auf /usr/local ein Filesystem mit hinreichend Platz (es sollten schon mehrere GB sein) gemountet hast (so laeuft das bei mir: Ich habe hinreichend viel
Massenspeicher auf /usr/local gemounted und verwende das mit dem System aus dem internen Flash).

 

[daniel3000]

Hi jilse at. al.

same question as every year:
Spricht was dagegen, das environment under der neuesten Firmware (SuperZaxxon Beta5) zu verwenden?
Bzw. tut as schon jemand erfolgreich?

Ich habe Schwierigkeiten mit dem C/C++ Dev PND, das im Repo erhältlich ist. Programme, die ich damit kompiliere, funktionieren auf meinem Produktivsytem, aber auf dem Testsystem, einem frischen SuperZaxxon Beta5 ohne jegliche Erweiterungen, meckern die Applikationen wegen fehlender libiconv.so.2 und libtinfo.so.5.
Klar kann ich die libs in die PNDs mit einbauen, aber das kann ja nicht der Weisheit letzter Schluss sein.

Und als ich vor Monaten mit diesem native environment hier kompiliert hatte, hatte ich die Probleme nicht.
Daher möchte ich das gern wieder versuchen. Aber natürlich nur, wenn ich mir nicht andere Inkompatibilitäten einhandele...

Vielen Dank!
Daniel

 

[Granitehead]

Hi jilse at. al.

same question as every year:
Spricht was dagegen, das environment under der neuesten Firmware (SuperZaxxon Beta5) zu verwenden?
Bzw. tut as schon jemand erfolgreich?

Ich habe Schwierigkeiten mit dem C/C++ Dev PND, das im Repo erhältlich ist. Programme, die ich damit kompiliere, funktionieren auf meinem Produktivsytem, aber auf dem Testsystem, einem frischen SuperZaxxon Beta5 ohne jegliche Erweiterungen, meckern die Applikationen wegen fehlender libiconv.so.2 und libtinfo.so.5.
Klar kann ich die libs in die PNDs mit einbauen, aber das kann ja nicht der Weisheit letzter Schluss sein.

Und als ich vor Monaten mit diesem native environment hier kompiliert hatte, hatte ich die Probleme nicht.
Daher möchte ich das gern wieder versuchen. Aber natürlich nur, wenn ich mir nicht andere Inkompatibilitäten einhandele...

Vielen Dank!
Daniel

Probier's doch aus. ;-)
Ich würde vorschlagen, dass du die Libs in die PNDs einbaust, das ist am sichersten. Es ist auch sehr wahrscheinlich, dass in einer neueren OS-Version (.next) plötzlich viele Libs nicht mehr vorhanden sind oder nur in einer viiiieeel neueren Version, die nicht mehr kompatibel ist. Dann laufen die PNDs nicht mehr, wenn du die Libs nicht dazupackst.

 

[daniel3000]

Hi t4b,

ich dachte erst, ausprobieren will ich lieber nicht weil es zu kompliziert ist, das Paket dann wieder vom root-fs runterzukratzen, falls es nicht gut ist.
Aber weit gefehlt: Ein rm -r /usr/local reicht ja völlig aus

Also habe ich es nun ausprobiert.

Anders als beim C/C++-Dev-PND, gab es jetzt beim Kompilieren Fehler wegen fehlender libiconv.
Das ist mir ja schon lieber, als wenn das Kompilieren sauber durchläuft und der Nutzer nachher den Fehler zur Laufzeit bekommt.
Schön.

Ich werde also ab jetzt das devel-pandora-native-20110411.tar.bz2 benutzen und alle libraries, die nicht da sind, selbst kompilieren oder per opkg installieren (soweit sie in den feeds vorhanden sind) und im PND mit dazulegen.

Danke! Wieder was gelernt!

Daniel

 

[jilse]

ich dachte erst, ausprobieren will ich lieber nicht weil es zu kompliziert ist, das Paket dann wieder vom root-fs runterzukratzen, falls es nicht gut ist.
Aber weit gefehlt: Ein rm -r /usr/local reicht ja völlig aus

Ja, ich hatte den Kram auch benutzt, indem ich das Zeug auf einem eigenen Filesystem
hatte, dass ich auf /usr/local gemountet habe. Ein "umount" reicht dann im Zweifelsfall
aus (ein umount ist aber so ohne weiteres nicht moeglich, solange Prozesse laufen, die
/usr/local/lib im LD_LIBRARY_PATH haben ...). Um /usr/local dann trotzdem sauber
umounten zu koennen ohne die Maschine zu rebooten, musste ich etwas herumprobieren,
aber es geht auch: mit "mount --move" Das Filesystem auf einen anderen Pfad "um-
haengen" der nicht im LD_LIBRARY_PATH liegt, dann kann man es anschliessend wieder
sauber "umounten" ...

Also habe ich es nun ausprobiert.

Anders als beim C/C++-Dev-PND, gab es jetzt beim Kompilieren Fehler wegen fehlender libiconv.

Hatte ich die libiconv da nicht schon drin? Evt. waere dann nur eine passende configure-Option
(irgend etwas mit "--with-iconv=/usr/local" oder so) notwendig gewesen ...

Das ist mir ja schon lieber, als wenn das Kompilieren sauber durchläuft und der Nutzer nachher den Fehler zur Laufzeit bekommt.
Schön.

Das pnd-Paket scheint im Endeffekt eine Cross-Compile-Umgebung zu sein, die in einem Emulator
laeuft. Unter "native Development-Environment" verstehe *ich* eigentlich etwas anderes (ich
wollte eine "native Umegbung", weil es bei manchen Programmpaketen die Uebersetzung ver-
einfacht, wenn dabei vorher kein crosscompilieren vorgesehen war: Ein auf dem Host laufender
Test kann evt. in einer Cross-Compile-Umegbung zu falschen Ergebnissen fuehren, und manche
Pakete nutzen so etwas beim "configure" ohne die Moeglichkeit einer Crosscompile-Umgebung
in Betracht zu ziehen).

Ich werde also ab jetzt das devel-pandora-native-20110411.tar.bz2 benutzen und alle libraries, die nicht da sind, selbst kompilieren oder per opkg installieren (soweit sie in den feeds vorhanden sind) und im PND mit dazulegen.

Ich hoffe bis spaetestens Herbst eine neue Version bereitstellen zu koennen (ggfs. mit neueren
Libraries, evt. besser angepasst, mit neueren Compiler-Versionen und neueren binutils).

Danke! Wieder was gelernt!
Daniel

Schoen, wenn es fuer jemanden hilfreich war.
Ich benutze eine entsprechende Umgebung bei mir uebrigens auf einer externen USB-Platte
(an einem "powered USB-HUB") mit der Firmware im Flash. Dabei habe ich bisher noch nicht
gemerkt, dass etwas mit aktuellerer Firmware nicht laufen wuerde ...

-- Fr Jun 22, 2012 15:29 --

ich dachte erst, ausprobieren will ich lieber nicht weil es zu kompliziert ist, das Paket dann wieder vom root-fs runterzukratzen, falls es nicht gut ist.
Aber weit gefehlt: Ein rm -r /usr/local reicht ja völlig aus

Ja, ich hatte den Kram auch benutzt, indem ich das Zeug auf einem eigenen Filesystem
hatte, dass ich auf /usr/local gemountet habe. Ein "umount" reicht dann im Zweifelsfall
aus (ein umount ist aber so ohne weiteres nicht moeglich, solange Prozesse laufen, die
/usr/local/lib im LD_LIBRARY_PATH haben ...). Um /usr/local dann trotzdem sauber
umounten zu koennen ohne die Maschine zu rebooten, musste ich etwas herumprobieren,
aber es geht auch: mit "mount --move" Das Filesystem auf einen anderen Pfad "um-
haengen" der nicht im LD_LIBRARY_PATH liegt, dann kann man es anschliessend wieder
sauber "umounten" ...

Also habe ich es nun ausprobiert.

Anders als beim C/C++-Dev-PND, gab es jetzt beim Kompilieren Fehler wegen fehlender libiconv.

Hatte ich die libiconv da nicht schon drin? Evt. waere dann nur eine passende configure-Option
(irgend etwas mit "--with-iconv=/usr/local" oder so) notwendig gewesen ...

Das ist mir ja schon lieber, als wenn das Kompilieren sauber durchläuft und der Nutzer nachher den Fehler zur Laufzeit bekommt.
Schön.

Das pnd-Paket scheint im Endeffekt eine Cross-Compile-Umgebung zu sein, die in einem Emulator
laeuft. Unter "native Development-Environment" verstehe *ich* eigentlich etwas anderes (ich
wollte eine "native Umegbung", weil es bei manchen Programmpaketen die Uebersetzung ver-
einfacht, wenn dabei vorher kein crosscompilieren vorgesehen war: Ein auf dem Host laufender
Test kann evt. in einer Cross-Compile-Umegbung zu falschen Ergebnissen fuehren, und manche
Pakete nutzen so etwas beim "configure" ohne die Moeglichkeit einer Crosscompile-Umgebung
in Betracht zu ziehen).

Ich werde also ab jetzt das devel-pandora-native-20110411.tar.bz2 benutzen und alle libraries, die nicht da sind, selbst kompilieren oder per opkg installieren (soweit sie in den feeds vorhanden sind) und im PND mit dazulegen.

Ich hoffe bis spaetestens Herbst eine neue Version bereitstellen zu koennen (ggfs. mit neueren
Libraries, evt. besser angepasst, mit neueren Compiler-Versionen und neueren binutils).

Danke! Wieder was gelernt!
Daniel

Schoen, wenn es fuer jemanden hilfreich war.
Ich benutze eine entsprechende Umgebung bei mir uebrigens auf einer externen USB-Platte
(an einem "powered USB-HUB") mit der Firmware im Flash. Dabei habe ich bisher noch nicht
gemerkt, dass etwas mit aktuellerer Firmware nicht laufen wuerde ...