-ljepg war korrekt. Schönen Dank an dcdead
Ich hatte aber noch einen anderen Fehler:
Wenn schon
#include <jpeglib.h>dann so:
extern "C" {
#include <jpeglib.h>
}dann klapps und es kommt kein
undefined symbol: _Z14jpeg_std_errorP14jpeg_error_mgrmehr ... 
Hi dcdead,
prima, das war genau der Tip, der mir weitergeholfen hat. Mit meinen eigenen, in extra Files ausgelagerten Klassen, funktioniert das jetzt wie gewünscht.
Kannst du mich evtl. auch noch sagen, wie ich Bibliotheken, die ich via
#include <jpeglib.h>einbinde linken (statisch?) kann.
Kompilieren tut's wie immer nichtig, auf der Box bekomme ich aber wieder ein undefined symbol aus dieser Headerdatei.
Muß ich das dann auch entsprechend im makefile angeben? (Ich hab schon ein paar Sachen ausprobiert, bisher aber leider ohne Erfolg)
Damit man versteht was ich genau meine hier mal Testcode.
Ich bekomme immer ein "Undefined symbol ..." auf der Box angezeigt, wenn ich das Plugin starte.
Ich hab mal ein kleines Test-Plugin geschieben, indem leicht nachzuvollziehen ist, was ich meine.
Es besteht aus:
- test.cpp (Mainpart)
- TestClass.cpp & TestClass.h
- Makefile und mk Script zum kompileren
Wenn ich nun versuche alles zu kompilieren klappt das auch ohne Fehler; starte ich das Plugin auf der Box kommt's zum o.g. Fehler "Undefined ..."
Packe ich den Code der TestClass mit in das test.cpp & kompiliere den Kram neu läuft es auch auf der Box.
=> die includeten Datein sind nicht kompiliert/linked worden !??!?
Weiß jemand was ich machen muß, damit das funktioniert? makefile ändern?
Hat niemand eine Idee? Ich habs auch schon mal mit
./autogen.sh
./config.status versucht... ohne Erfolg.
Wie erzeugt man normalerweise makefiles?
Wenn ich ein Plugin baue, welches aus Test.cpp & Test.h besteht klappt alles mit dem bauen.
Ich habe ein makefile
CDK_SRC = /home/asterix/dreambox-cdk/
CDKROOT = /home/asterix/dreambox-cdk/root/cdkroot/
BOXBIN = /home/asterix/dreambox-cdk/root/cdk/bin/
CROSS = /home/asterix/dreambox-cdk/root/cdk/powerpc-tuxbox-linux-gnu/bin/
CC = $(CROSS)g++
CXX = $(CC)
STRIP = $(CROSS)strip
DBG = -DDEBUG
CFLAGS = $(INCLUDES) -fno-rtti -fno-exceptions -Wall -O2 -mcpu=405 -msoft-float -mmultiple -mstring -g -ggdb3 -pipe
OBJECTS = Test.o
INCLUDES = -I$(CDK_SRC)/apps/tuxbox/enigma/include \
-I$(CDKROOT)/include \
-I$(CDKROOT)/include/sigc++-1.2 \
-I$(CDKROOT)/include/freetype2 \
-I$(CDKROOT)/lib/sigc++-1.2/include \
-I$(CDK_SRC)/driver/include \
-I$(CDK_SRC)/apps/tuxbox/enigma \
-I$(CDK_SRC)/apps/misc/libs/libxmltree \
-I$(CDK_SRC)/apps/tuxbox/plugins/include \
-I$(CDK_SRC)/apps/tuxbox/enigma/src \
-I.
all: Test.so
Test.so: $(OBJECTS)
$(CXX) -shared -Wall -O2 -mcpu=823 -msoft-float -mmultiple -mstring -g -ggdb3 -pipe -o Test.so $(OBJECTS)
$(STRIP) --remove-section=.note --remove-section=.comment Test.so
.cpp.o:
$(CXX) $(CFLAGS) -c -o Test.o $<
clean:
rm -rf *.so *.ound ein keines Script mk
#! /bin/bash
echo
echo Building Plugin
echo
rm ./bin/Test.so
make clean
make all
/home/asterix/dreambox-cdk/root/cdk/powerpc-tuxbox-linux-gnu/bin/strip --remove-section=.note --remove-section=.comment Test.so
chmod 755 Test.so
cp ./Test.so ./bin
was mir dann das Teil baut. Das Prog läuft auf der Box wie gewünscht.
Wenn ich aber Klassen in andere Files auslagen möchte und diese via #include im Code einbaue kompilert (und linkt?) zwar alles wie gewünscht, wenn ich das Teil aber auf der Box starte kommt: "Undefined symbol ...".
Also fehlt ihm die entsprechende lib (aus den ausgelagerten Klassen), bzw. sie wurde zuvor nicht gebaut?!
Wie konfiguriere ich solche Projekte richtig? Dafür gibts doch Tools/Befehle, oder nicht? Kann ich mein makefile modifizieren, so dass es auch mit mehreren Files klar kommt?
Ich komme aus der Windows-Entwickler-Welt und bin mit den LinuxDev-Gepflogenheiten leider nicht so vertraut ...
Wenn ich getFPVersion mache krieg ich bei der FP1.06 Version eine 6 (int) zurück. Das 1.0 davor muß man sich wohl denken, oder? ( =1.06)
Ahhhh... das war ein guter Tip! Jetzt macht er's.
Noch eine Frage: Ich hatte mir seinerzeit mal das CDK und Dreamimagesourcen Stand 1.09 FP 1.05 geholt.
Wenn ich in dieser Version das FP Update duchführe, wenn FP > 1.05 ist (durch Codeänderung), dann müßte er doch ein Downgrade auf 1.05 (was ja in dieser Version mitgeliefter wurde) machen, oder?
Hm, das scheint er aber nicht zu machen. Wenn ich nämlich extra fehlerhaften "Code" einbaue müßte ja ein Compilerfehler auftauchen.
Das passiert aber nicht, ergo nimmt er gar nicht den geänderten Code ... was mache ich denn da wohl falsch ...?
Wenn ich in der "dmfp.cpp" Code ändere reicht dann ein
make dreamimage_root
make rebuild-flash
make flash-compressum das Image mit den Änderungen neu zu bauen. (Irgenwie scheint er mir das nicht neu zu kompilieren) Muß man da noch was bestimmtes touchen oder so?
na ja, ich werde mal mein Glück versuchen ... mal schauen, ob's klappt.
Vielleicht hast du ja trotzdem noch eine Idee (oder jemand anderes) wie man starten könnte ...
Ja, das ist schon klar. Das coden ansicht ist kein Problem, das werde ich schon machen, wenn ich nur wüßte, wie ich da prinzipiell bei jpg's vorgehen soll/muß ... 
Habe mal in diegPixmap usw. reingeschaut. Wenn ich das mit png's machen würde ist alles klar. (da gibt's loadPNG usw...)
Leider habe ich jedoch jpg's.Hast du da vielleicht noch einen Tipp? Ist das ev. über ePictureDecoderJPEG zu lösen? Aber wie ist das anzuwenden..?
Oder könnte man
int fh_jpeg_load(const char *filename, unsigned char *buffer, int x, int y)aus der jpeg.cpp nutzen und den Buffer dann in eine gPixmap schieben?!? Etwa so:
...
gPixmap MyPixmap;
MyPixmap.data = buffer;
MyPixmap.x = x;
MyPixmap.y = y;
...
Würde das funzen? 
OK, prima. Danke für die Info.
Das Image ist gebaut. Dann werde ich gleich mal versuchen zu flashen. (Damit ich endlich wieder die neuen Images mit LZMA auch auf den Stick bekomme)
Update: So, hab's geflashed und hat auch geklappt. Aktuelles Image, FP immer noch 1.05 ... :]
ZitatAlles anzeigenOriginal von digi_casi
also wer den fp downgrade versuchen will.... hier das vorgehen.
1. man besorge sich ein head.ko mit dementsprechenden fp level. muss allerdings zum kernel passen. aber 1.05 und 1.06 hatten ja denselben kernel.
2. man aendert in enigma/lib/system/dmfp.cpp das upgradeisavailalable so ab, dass nur noch return 1; drin steht.
3. man baut ein image mit der head.ko und der geaenderten dmfp.cpp
und schon wird der alte fp reingeschrieben.
ich selbst habe das noch nicht probiert, bei mir ist in upgradeisavailabe ein return 0 drin... damit wird nie nicht ein upgrade gemacht.
also ohne gewaehr
Hi digi_casi,
wenn ich mein Image also so baue:
int eDreamboxFP::isUpgradeAvailable()
{
// never update the fp!
return 0;
int fd = ::open("/dev/dbox/fp0", O_RDWR);
if (fd < 0)
return 0;
int val = 0xdeadbabe;
if ((::ioctl(fd, 0x200, &val) < 0) || (val != 1))
{
::close(fd);
return 0;
}
::close(fd);
return 1;
}
wird kein FP update gemacht, richtig? (Ich hab nämlich bislang auch noch das erste 1.09 mit FP 1.05 auf der Box und möchte das eigentlich bis auf weiteres nicht auf FP 1.06 hochziehen).
Hab ich ja aschon mal gemacht. Das ist doch der Weg über ein Skin, oder sehe ich das falsch?
Da wird doch im esml-Skinfile das File (mit Namen) statisch gesetzt:
<images basepath="" target="fb">
...
<img name="dreamlogo" src="dreamlogo-fs8.png" />
...
</images>und dann für den entsprechenden Dialog (hier eAboutScreen) die entsprechende "Referenz" zum eLabel gesetzt:
<object name="eAboutScreen">
<eAboutScreen text="About..." cposition="125:105" csize="450:410">
...
<eLabel name="dreamlogo" pixmap="dreamlogo" position="e-160:e-105" csize="143:75" alphatest="on" />
...
</eAboutScreen>
</object>Später im enigma_info.cpp wird das die Instance des Label(-Bilds) erzeugt:
...
dreamlogo=new eLabel(this);
dreamlogo->setName("dreamlogo");
...
OK soweit. Aber wie könnte ich nun zur Laufzeit des Plugins das obige "dreamlogo-fs8.png" durch ein Bild "bla.jpg" (oder was auch immer) anderer Größe ersetzten?
Hallo digi_casi,
im Tuxbox CVS habe ich gesehen, dass du viel oder alles beim picviewer gecodet hast. Deswegen hätte eine Frage an dich (die du bei deinem Wissen über Bilder auf der Dreambox anzeigen vielleicht leicht beantworten kannst):
Ich möchte ein Plugin basteln (bzw. habe das Plugin bis auf die Bildanzeige schon erstellt), welches zu einem Produkt ein Bild anzeigt.
Dieses Bild liegt dann als jpg z.B. in /tmp/Bild1.jpg, /tmp/Bild2.jpg ...
Man kann dann aus einer Liste von Produkten wählen und es soll immer das zugehörige Bild dargestellt werden.
Lange Rede kurzer Sinn: Könntest du mir ein Codeschnipsel schicken, wie ich auf einem Dialog (eWindow) ein Bild plazieren kann? (nicht Vollbild, sondern sagen wir 200x150pix; da soll immer noch Text usw. nebenstehen).
Das Bild muß/soll ev. vorher auf obige Größe resized werden.
Ich hatte es schon mal geschafft Bilder über ein Skin einzubauen, aber das ist mir etwas zu statisch, oder gibts da keinen anderen Weg?
Für einen Tipp wäre ich dir echt dankbar.
Viele Grüße
Ralf
Danke für den Tip. Werde ich gleich heute abend mal versuchen zu builden...
tomdulix : Ja, ich glaube so wars ...
metalhead: Danke für die Info. Das kann ich mal probieren.
Aber generell ist es doch schon möglich einen bestimmten Softwarestand auszuchecken, oder?
Etwa so:
cvs -danoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -rDM7000_109 -P .
Wobei "DM7000_109" einen Checkpoint darstellen soll den es aber, soweit ich im cvs gesehen habe so nicht gibt. Also bleibt einem nur die Möglichkeit über ein bestimmtes Datum auszuchecken?
Also so:
cvs -danoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -r2005-03-11 -P .
um die Version vom 11.3.2005 auszuchecken?
Also ich habe die letzte "offizielle" Release, die auch mal auf der Homepage angeboten wurde (jetzt ists ja wieder 1.08 ) im Flash und da läuft auf dem FP die Version 1.5 ...
Bitte korrigiert mich, falls das nicht die letzte offizielle SW war.
Hallo,
kann mir jemand sagen, wie ich die letzten Sourcen ohne LZMA Patch für die DM7000 aus dem CVS holen kann?
Welcher Checkpoint ist das?
Vielleicht kann mir jemand die entsprechende "CVS ..." Zeile schicken?
Hintergrund: Ich möchte was für die Box proggen, aber nicht ein aktuelles Image aus dem CVS nehmen, weil das ja ein FP Update auf 1.6 macht. Die Box ansicht läuft im aktuellen Zustand (letztes original 1.09 Image im Flash) super stabil und ich möchte nicht riskieren, dass ich mit einem aktuellen CVS Image Bottprobleme o.ä. bekomme.
Grüße
Ralf