Eigene Programme - wie muss das Makefile aussehen?

0815eddi · 5 Okt 2009

Hallo,

ich bin dabei, mir eine Überwachung für die Wechselrichter meiner Photovoltaikanlage zu bauen. Da ich dazu natürlich nicht mienen PC den ganzen Tag laufen lassen möchte, bin ich auf Freetz und die damit verbundenen Möglichkeiten, "etwas mehr aus der FritzBox herauszuholen" gestossen.
Mit den entsprechenden HowTos und Foreneinträgen ist es mir dann auch relativ schnell gelungen, meine FritzBox zu "freetzen" und am Beispiel des "Empty-Packages" auch mal ein eigenes Paket in die Firmware zu integrieren. Hier an der Stelle ist ein Lob fällig: Alles war gut beschrieben und nachvollziehbar, so dass das relativ einfach ging.

So weit so gut - jetzt möchte ich natürlich nicht nur mein "Hello World"-Programm laufen lassen, sondern meine Wechselrichterüberwachung. Vom Hersteller des Interfaces (USB auf CAN-Bus - ist hier an der Stelle aber nicht so wichtig ...) gibt es dazu eine OpenSource-API, die auch mit entsprechenden Beispielprogrammen versehen ist. Zu diesen Beispielprogrammen gibt es für die Verwendung unter UNIX auch gleich die passenden Makefiles. Ich habe dann zunächst mal in meiner Ubuntu-Partition das Makefile ausgeführt - das ging ohne Probleme und auch das Programm lief hinterher problemlos.

Jetzt möchte ich das in meine Freetz-Firmware integrieren und habe das passende Paket bereits erstellt. Wenn ich dann mit dem vorhandenen Makefile ein "make mypackage-precompiled" durchführe erhalte ich Fehlermeldungen. Die kann ich gerne noch mal nachreichen, im Moment gehe ich aber davon aus, dass das Problem grundsätzlicher Natur ist und ich das Makefile erstmal an die Freetz-Gegebenheiten anpassen muss. Und das ist genau die Stelle, an der ich mich über die Unterstützung der Profis hier im Forum freuen würde. Über die Suchfunktion bin ich leider nicht so richtig fündig geworden.

Hier erstmal das vorhandene Makefile:

Code:

#

# libusbcan Makefile

#



CC = gcc

LD = gcc 

INCLUDE = -I/usr/local/include -I. -I.. -I../../lib

LIB = -L/usr/local/lib -ldl -lc

CFLAGS =  -Wall -pthread -ggdb3 -O0 

#CFLAGS = -Wall -g0 -O2

LDFLAGS = -Wall



SRCS = tiny_can.c linux_util.c can_drv_linux.c

OBJS = $(SRCS:.c=.o)



all: $(OBJS)

	$(LD) $(LDFLAGS) $(LIB) -o sample1 $(OBJS)



%.o: %.c

	$(CC) $(CFLAGS) $(INCLUDE) -o $@ -c $<



clean:	

	rm -f *.o *~ ./../../lib/*.o ./../../lib/*~ \

	./../*.o ./../*~

Wie muss das aussehen, damit das kompilieren unter Freetz funktinioniert? Ich habe selbst schon einiges probiert, da ich mich mit Makefiles aber nicht im Detail auskenne, komme ich an der Stelle nicht wirklich weiter.
Daher bin ich dankbar für jeden Hinweis, der mir hier weiterhilft.

Danke schon mal für die Unterstützung!
Gruß
0815eddi

Silent-Tears · 5 Okt 2009

Schau dir im trunk die Sachen unter "./make/$pkg/$pkg.mk" an. $pkg wird natürlich ersetzt durch den Paketnamen deiner Wahl.

0815eddi · 5 Okt 2009

Hallo Silent-Tears,

das ging ja schnell mit der Antowrt!

Silent-Tears schrieb:
Schau dir im trunk die Sachen unter "./make/$pkg/$pkg.mk" an. $pkg wird natürlich ersetzt durch den Paketnamen deiner Wahl.

Das sieht so aus:

Code:

$(call PKG_INIT_BIN, 0.0.2)
$(PKG)_SOURCE:=tiny_can-$($(PKG)_VERSION).tgz
$(PKG)_SITE:=@SF/tiny_can
$(PKG)_BINARY:=$($(PKG)_DIR)/tiny_can
$(PKG)_TARGET_BINARY:=$($(PKG)_DEST_DIR)/usr/bin/tiny_can


$(PKG_SOURCE_DOWNLOAD)
$(PKG_UNPACKED)
$(PKG_CONFIGURED_NOP)

$($(PKG)_BINARY): $($(PKG)_DIR)/.configured
	PATH="$(TARGET_PATH)" \
		$(MAKE) -C $(TINY_CAN_DIR) \
		CC="$(TARGET_CC)" \
		CFLAGS="$(TARGET_CFLAGS)"

$($(PKG)_TARGET_BINARY): $($(PKG)_BINARY)
	$(INSTALL_BINARY_STRIP)

$(pkg):

$(pkg)-precompiled: $($(PKG)_TARGET_BINARY)

$(pkg)-clean:
	-$(MAKE) -C $(TINY_CAN_DIR) clean
	$(RM) $(TINY_CAN_DIR)/.configured

$(pkg)-uninstall:
	$(RM) $(TINY_CAN_TARGET_BINARY)

$(PKG_FINISH)

Aber wie hilft mir das jetzt weiter? Im Moment weiss ich noch nicht, was ich damit anfangen soll - vielleicht steh ich mir da aber auch selbst im Weg und seh den Wald vor lauter Bäumen nicht ...

hermann72pb · 5 Okt 2009

Ich hatte mal die Tage dosfstools auf eine ähnliche Weise angepasst. Hatte es vorher auch nie gemacht. Ich würde dir anraten nicht nur ein, sondern 2-3 Beispiele anzuschauen. Nimm dir z.B. dosfstools oder e2fsprogs oder noch was Vergleichbares. Du musst da schon die Parameter für LDFLAGS und CFLAGS setzen und nicht nur die von der toolchain nehmen.

MfG

RalfFriedl · 6 Okt 2009

Vielleicht sind die konkreten Fehlermeldungen doch hilfreich.

Meine Vermutung ist, daß ein Fehler beim Linken auftritt und dieser gelöst werden kann, wenn man auch LD setzt:

Code:

		CC="$(TARGET_CC)" \
[B]		LD="$(TARGET_LD)" \[/B]

Es kann aber auch sein, daß schon vorher ein Fehler auftritt.

sf3978 · 6 Okt 2009

0815eddi schrieb:

Hier erstmal das vorhandene Makefile:

Code:

#

# libusbcan Makefile

#



CC = gcc

LD = gcc 

INCLUDE = -I/usr/local/include -I. -I.. -I../../lib

LIB = -L/usr/local/lib -ldl -lc

CFLAGS =  -Wall -pthread -ggdb3 -O0 

#CFLAGS = -Wall -g0 -O2

LDFLAGS = -Wall



SRCS = tiny_can.c linux_util.c can_drv_linux.c

OBJS = $(SRCS:.c=.o)



all: $(OBJS)

	$(LD) $(LDFLAGS) $(LIB) -o sample1 $(OBJS)



%.o: %.c

	$(CC) $(CFLAGS) $(INCLUDE) -o $@ -c $<



clean:	

	rm -f *.o *~ ./../../lib/*.o ./../../lib/*~ \

	./../*.o ./../*~

Wie muss das aussehen, damit das kompilieren unter Freetz funktinioniert?

Schau dir mal das Makefile an, das mit dem Patch aus diesem Beitrag, im Ordner ".../source/portsentry_beta" erzeugt/angepasst/geändert wird. Es geht nicht um die Datei "portsentry.mk" aus dem Ordner ".../make/portsentry".

olistudent · 6 Okt 2009

Ich würde neben LD auch noch die Variablen INCLUDE und LIBS im Makefile überschreiben.

MfG Oliver

RalfFriedl · 6 Okt 2009

Evtl. auch einfach im Makefile ändern, statt auf der Kommandozeile zu übergeben:

Code:

LD = $(CC)
INCLUDE = -I. -I.. -I../../lib
LIB = -ldl -lc

Die /usr/local Einträge entfernen, LD aus CC übernehmen, und bei der Gelegenheit die überflüssigen Leerzeilen entfernen. Meine Vermutung ist, daß dieses Leerzeilen aus DOS-Zeilenenden kommen.

0815eddi · 6 Okt 2009

Erstmal danke an alle für die verschiedenen Anregungen. Ich werde das jetzt mal in Ruhe testen und euch über meine Fortschritte (oder eben auch nicht...) auf dem Laufenden halten.

0815eddi · 13 Okt 2009

So,

ich bin ein Stückchen weiter gekommen.
Offensichtlich lags an den LD und CC-Einträgen. Danke für die hilfreichen Tipps!

Die Fehlermeldung, die ich jetzt noch bekomme, bezieht sieht auf einen Include (stropts.h) - Die datei wird nicht gefunden - wie gesagt, beim Kompilieren mit dem Original-Makefile unter UBUNTU ist das kein Problem. Ich hab den Include dann zunächst in der "Ubuntu"-Version auskommentiert - Das Programm läuft trotzdem noch tadellos - Das Problem ist also erstmal sekundär. Trotzdem wäre ich dankbar, wenn mir da noch jemand einen Tipp geben könnte, wie es auch unter Freetz klappt

Um weiterzukommen, habe ich den Include in der "Freetz"-Version mal auskommentiert, danach konnte alles sauber kompiliert und auf die Fritzbox gebracht werden

So weit so gut - aber da kommt schon das nächste Problem. Das Programm verwendet eine Treiber-Bibliothek namens "libmhstcan.so". Beim Starten kommt folgende Fehlermeldung:
"./tiny_can: './../lib/libmhstcan.so' is not an ELF executable for MIPS". Wie muss ich denn die vorher noch behandeln, damit die FritzBox damit zurechtkommt. Ich hab zwar gelesen, dass man grundsätzlich auch zusätzliche Bibliotheken integrieren kann - ich hab aber noch nicht gefunden , wie das genau geht. Vielleicht kann mir hier noch mal jemand auf die Sprünge helfen...

MaxMuster · 13 Okt 2009

Wo kommt denn diese Bibliothek her? Die muss auch für das "Zielsystem" gebaut sein, also auch für "mipsel".

Jörg

0815eddi · 14 Okt 2009

Hallo Jörg,

MaxMuster schrieb:
Wo kommt denn diese Bibliothek her? Die muss auch für das "Zielsystem" gebaut sein, also auch für "mipsel".

Die Bibliothek wird vom Hersteller des USB-CAN Interfaces bzw. der zugehörigen API mitgeliefert. Es gibt einen Windows-Treiber und einen LINUX-Treiber. Die libmhstcan.so ist halt der LINUX-Treiber- Aber LINUX ist nun mal ein sehr weit gefasster Begriff ...

Silent-Tears · 14 Okt 2009

Ja ist es tatsächlich, denn deine "*.so" ist sicherlich nicht für die Fritz und deren zugrunde liegende Architektur gedacht. Das hat erst einmal nichts mit Linux an sich zu tun, sondern eben damit, dass es eine komplett andere Architektur ist.

RalfFriedl · 14 Okt 2009

Wenn diese .so Datei über Sourceforge verteilt wird, dann widerspricht das nach meinen Informationen der Lizenz zur Benutzung von Sourceforge, wenn keine Quellen dafür verfügbar sind.
Ansonsten wird dann nicht "LINUX" unterstützt, sondern "LINUX auf Prozessor X in der Version Y, möglicherweise mit Einschränkungen bezüglich der Konfiguration". Je nachdem, was da konkret geliefert wird, kann es gut sein, daß es auf einem X86 Prozessor, auf einem Multiprozessor-System oder mit dem nächsten Kernel nicht mehr funktioniert. Ich habe auch schon binäre Kernel-Module gesehen, die nur funktioniert haben, wenn der Kernel auf eine bestimmte Adresse gelinkt wurde.

0815eddi · 15 Okt 2009

RalfFriedl schrieb:
Wenn diese .so Datei über Sourceforge verteilt wird, dann widerspricht das nach meinen Informationen der Lizenz zur Benutzung von Sourceforge, wenn keine Quellen dafür verfügbar sind.

Ich hab die Sourcen gefunden - der Download war ein bisschen versteckt - aber anscheinend alles da. Dann kann ich ja wieder weitermachen - neues Makefile bauen etc. - aber da hab ich ja schon ein wenig Übung

0815eddi · 18 Okt 2009

Tja, von einem Problem zum nächsten....

Ich bekomme zwar die Treiberdatei libmhstcan.so jetzt kompiliert, bei Verwendung auf der FB kommt aber ein freundliches "Segmentation fault". Ich habs mit mehren Einstellungen im Makefile probiert, der Fehler bleibt aber der gleiche.

Anbei die aktuelle Version des Makefiles. Vielleicht findet dort jemand insb. bei den CFLAGS oder LDFLAGS irgendeine Option, die besser nicht oder anders verwendet werden sollte?

MaxMuster · 18 Okt 2009

Kannst du mal das testen? Ist mit tiny_can_api_302.tar.gz und dem enthaltenden Makefile gebaut.

Code:

joerg@linux-l63w:~/freetz-trunk/source/tiny_can/treiber/mhstcan/linux> mipsel-linux-ldd libmhstcan.so 
        libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
        librt.so.0 => not found (0x00000000)
        libc.so.0 => not found (0x00000000)
        libc.so.6 => /lib/libc.so.6 (0x00000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
joerg@linux-l63w:

Jörg

0815eddi · 18 Okt 2009

Hallo Jörg

MaxMuster schrieb:
Kannst du mal das testen? I
[/code]

Hab ich gemacht - allerdings ohne Erfolg - Es bleibt beim alten Fehler:

Code:

/var/mod/root # tiny_can
Wechselrichterueberwachung
=========================

Can't open output file ./log/output.log!
Segmentation fault
/var/mod/root #

Die Fehlermeldung mit"output.log" kann an der Stelle ignoriert werden. Problematisch ist die Meldung "Segmentation fault" die bei Aufruf der Treiber-Datei erscheint.
Letztendlich habe ich es auch so wie du gemacht: Das vorhandene Makefile genommen und ein wenig (und später immer mehr) angepasst. Dabei enstanden dann in der Größe unterschiedliche *.so-Dateien. Die Fehlermeldung blieb aber immer gleich. Jetzt steh ich ziemlich auf dem Schlauch und weiss nicht weiter ...

Eddi

MaxMuster · 19 Okt 2009

Sind denn die ganzen anderen Libraries, die du benötigst vorhanden? Kannst du (mit dem neu gebauten libmhstcan.so) eventuell das Programm selbst statisch bauen?
Ein Segfault kann die verschiedensten Ursachen haben, ohne strace wird man da wohl nicht wirklich genaueres herausbekommen...

Jörg

RalfFriedl · 19 Okt 2009

0815eddi schrieb:
Die Fehlermeldung mit"output.log" kann an der Stelle ignoriert werden.

Der Fehler könnte die Ursache für den "Segmentation fault" sein.

Eigene Programme - wie muss das Makefile aussehen?

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

IPPF-Urgestein

Neuer User

Neuer User

Anhänge

IPPF-Promi

Anhänge

Neuer User

IPPF-Promi

IPPF-Urgestein

Statistik des Forums