mipsel-linux-gcc anstelle von mipsel-linux-uclibc-gcc im userspace

[gnieder]

Hallo Spezialisten,

ich versuche gerade ein Programm für freetz mit statischen libs zu kompilieren.
Das funktioniert auch soweit, nur leider funktioniert das Binary nicht 100%tig.

Inzwischen habe ich herausgefunden, dass es am verwendeten Kompiler liegt.
Wenn ich den mipsel-linux-uclibc-gcc verwende, macht es Probleme, beim mipsel-linux-gcc
geht's einwandfrei.

Ich muss beim ./configure bereits einige Optionen mit angeben, damit ich ein
100%tiges Binary bekomme.
Leider führt das aber zu einem Konflikt mit Einträgen in make/config.cache wie z.B.:

configure: error: `CC' has changed since the previous run:
configure:   former value:  mipsel-linux-uclibc-gcc
configure:   current value: mipsel-linux-gcc

Kann mir jemand einen Tip geben, wie ich in der dazugehörigen .mk Datei dies angeben muss,
damit die Prüfung in der config.cache übergangen wird?
Bei Angabe dieser Werte über die CC bzw. CFLAGS beim make bekomme ich zwar keinen
Fehler, allerdings läuft das Binary dann aber wiederum nicht mehr sauber.

Irgendwie habe ich einen Knopf in den Gehirnwindungen.
Ich bekomme das einfach nicht gebacken.
Am liebsten wäre mir - nur den ./configure und make Part in der .mk - so zu steuern,
dass ich nicht auf die vorgefertigten Variablen zugreifen muss.

Danke für's lesen...

Gruß

Wanninger

 

[linuxkasten]

Es könnte sein, dass der Kernel-Compiler verwendet wird. Denn eigentlich ist mipsel-linux-gcc auch nur ein Symlink auf mipsel-linux-uclibc-gcc...
Als Workaround könntest du die Verwendung von config.cache ausschalten bzw. config.cache löschen.

 

[gnieder]

...das mit dem config.cache löschen habe ich schon probiert, dann funktioniert es auch.

Leider kann ich das halt nur machen, wenn ich das Paket später zusätzlich kompiliere und
ich muss anschliessend die config.cache wieder löschen, denn sonst bekomme ich beim
kompilieren eines weiteren/anderen Paketes wieder Probleme.

Kann ich es in der .mk irgendwie steuern, dass die config.cache für diesen einen Fall ignoriert wird?

 

[olistudent]

Poste doch mal den Fehler mit mipsel-linux-uclibc-gcc. Da sollten wir angreifen anstatt eine Ausnahme zu erstellen.

MfG Oliver

 

[gnieder]

Ein lesbarer Fehler ist nicht erkennbar, sondern nur in der Auswirkung des fertigen Kompilats.

Es handelt sich hierbei um den sog. siproxd den ich für einige Szenarien benötige.
Dieser setzt u.A. die neuesten libosi2 und libosipparser2 voraus.

1. Problem:
In der org. AVM Firmware sind beide Libs bereits enthalten, aber mit einer Versionsnummer die
es nie gab und auch mit dem aktuellen siproxd nicht verwendbar sind.
Um nun evtl. Konflikten mit Binaries die auf die AVM Variante beider vorhandenen Libs aufsetzen,
zu vermeiden kann ich die benötigten Libs nur statisch einkompilieren.
Bei diesem Vorgang werden auch siproxd eigene Plugins statisch eingebunden.

Soweit sogut.

Das kompilieren funktioniert mit dem mipsel-linux-uclibc-gcc auch einwandfrei.
Nur beim Aufruf des daemons behauptet dieser, erfinde die Plugin-lade-Dateien nicht, obwohl
sie, auch für ihn, definitiv erreichbar sind.

Dieser Effekt tritt bei Verwendung des mipsel-linux-gcc nicht auf.

2. Problem:
In der Toolchain ist eine Lib namen libpthread enthalten.
Beim kompilieren mit mipsel-linux-uclibc-gcc behauptet make dass es pthread nicht findet.
Hier muss ich zusätzlich -lpthread mit angeben. Dann läuft make sauber durch.

Bei Verwendung von mipsel-linux-gcc habe ich diesen zweiten Effekt auch nicht.

3. Problem:
Das Übergeben von zusätzlichen CC und CFLAGS während des standard make Vorganges
in der .mk ändert leider an meinem Problem auch nichts.
Einzig die Angabe dieser geänderten Werte während des ./configure hilft.

Gruß

Wanninger

 

[olistudent]

Wenn du den aktuellen Trunk verwendest, dann brauchst du dir über die AVM Libraries keine Sorgen machen. Die Freetz Libraries landen in /usr/lib/freetz und das ist kein Standard-Such-Pfad für die AVM Programme. Poste doch mal deine Makefiles. Das bekommen wir schon hin.

MfG Oliver

 

[gnieder]

...ich weiss, aber der "dynamische" siproxd versucht es mit den AVM Libs, vermutlich weil er
diese zuerst sieht, und damit läuft der siproxd nicht mehr. (unresolved symbols...)

 

[Silent-Tears]

Oliver schrieb schon, dass du mal deine Makefiles posten sollst, um diese an den richtigen Stellen anzupassen.

 

[olistudent]

Die 2 Libs sind übrigens im AVM Open-Source Package. So dass du sehr wohl gegen diese linken könntest...

MfG Oliver

 

[gnieder]

Anbei mal die .mk files.

Gruß

Wanninger

 

[olistudent]

Ich würde folgenden Abschnitt in der siproxd.mk empfehlen:

$(PKG)_DEPENDS_ON := libosip2

$(PKG)_CONFIGURE_PRE_CMDS += $(call PKG_PREVENT_RPATH_HARDCODING,./configure)

$(PKG)_CONFIGURE_OPTIONS += --sysconfdir=/tmp/flash/siproxd

$(PKG_SOURCE_DOWNLOAD)

Die libosip2 sollte im Image unter /usr/lib/freetz zu finden sein. Mit diesem PREVENT_RPATH_HARDCODING wird sie dann auch gefunden.

MfG Oliver

 

[gnieder]

...merci erstmal.

Der Eintrag funktioniert. Damit kann ich den siproxd nun auch dynamisch linken.

Allerdings stellt sich jetzt die Frage, ob dynamisch in diesem Fall sinnvoller ist, oder ob statisch
günstiger ist, denn statisch komme ich auf eine gestripte Gesamtgröße von etwa 380kB
und bei dynamisch komme ich auf etwa 510kB.

Gibt es eine Liste/Beschreibung aller Vaiablen die in einer .mk verwendet werden können?

Vielleicht hast Du ja noch 'nen Tip zum Thema statisch ?

Gruß

Wanninger

 

[olistudent]

Wie kommst du auf die 510kb? Poste mal bitte die einzelnen Größen?

MfG Oliver

 

[gnieder]

Moin moin,

*siproxd                                  ¦ 151104¦28. Mär 01.58¦
@libosip2.so                              ¦     17¦28. Mär 01.59¦
@libosip2.so.4                            ¦     17¦28. Mär 01.59¦
*libosip2.so.4.2.0                        ¦  98480¦28. Mär 01.48¦
@libosipparser2.so                        ¦     23¦28. Mär 01.59¦
@libosipparser2.so.4                      ¦     23¦28. Mär 01.59¦
*libosipparser2.so.4.2.0                  ¦ 240624¦28. Mär 01.48¦
 plugin_defaulttarget.la                  ¦   1310¦28. Mär 01.58¦
 plugin_demo.la                           ¦   1247¦28. Mär 01.58¦
 plugin_fix_bogus_via.la                  ¦   1310¦28. Mär 01.58¦
 plugin_logcall.la                        ¦   1268¦28. Mär 01.58¦
 plugin_shortdial.la                      ¦   1282¦28. Mär 01.58¦
 plugin_stun.la                           ¦   1247¦28. Mär 01.58¦

Hier fehlen noch die plugin_*.so Dateien. Ich habe die make Datei noch nicht ganz fertig.
Bis hier hin sind es etwa 496kB gestriped. Die .so dürften sich noch auf etwa 15-20kB belaufen.

Gruß

Wanninger

 

[olistudent]

Die .la sind unnötig. Die .so Dateien von den Plugins sollten reichen. Wenn du noch folgende Flags für libosip2 angibst werden die Libs etwas kleiner: (openwrt)

$(PKG)_CONFIGURE_OPTIONS += --disable-debug
$(PKG)_CONFIGURE_OPTIONS += --disable-trace
$(PKG)_CONFIGURE_OPTIONS += --enable-pthread
$(PKG)_CONFIGURE_OPTIONS += --enable-semaphore
$(PKG)_CONFIGURE_OPTIONS += --enable-ntimer

Ich hab grad keine Box in der Nähe und kann deshalb nichts testen.

MfG Oliver

 

[gnieder]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Die .la sind die Dateien über die das entsprechende Plugin geladen wird. Ist eine Eigenheit
von siproxd. Steht auch explizit in der Doku drin.

Die Flags probiere dann mal aus.

-Wanninger

[Beitrag 2:]
...hier das Ergebnis:

*siproxd                                  ¦ 151104¦28. Mär 12.29
@libosip2.so                              ¦     17¦28. Mär 12.30
@libosip2.so.4                            ¦     17¦28. Mär 12.30
*libosip2.so.4.2.0                        ¦  59416¦28. Mär 12.29
@libosipparser2.so                        ¦     23¦28. Mär 12.30
@libosipparser2.so.4                      ¦     23¦28. Mär 12.30
*libosipparser2.so.4.2.0                  ¦ 138176¦28. Mär 12.29
 plugin_defaulttarget.la                  ¦   1310¦28. Mär 12.29
 plugin_demo.la                           ¦   1247¦28. Mär 12.29
 plugin_fix_bogus_via.la                  ¦   1310¦28. Mär 12.29
 plugin_logcall.la                        ¦   1268¦28. Mär 12.29
 plugin_shortdial.la                      ¦   1282¦28. Mär 12.29
 plugin_stun.la                           ¦   1247¦28. Mär 12.29

Jetzt dürfte das Endergebnis bei etwa 40kB weniger als bei statisch sein.
Ich muss jetzt nur noch testen ob der Daemon noch sauber läuft.

-Wanninger

 

[olistudent]

Ich denke, dass die statische Variante jetzt auch kleiner ist. Jedoch weiß ich nicht, ob es überhaupt funktionieren kann die Plugins statisch zu linken, weil die über die libltdl aus dem libtool Package geladen werden...

MfG Oliver

 

[gnieder]

TRies hat zu diesem Zweck im Paket eine eigene libltdl mit drin, die bei Nichtvorhandensein
der lib auf dem Host automatisch mit erzeugt wird.

Das habe ich schon getestet und es läuft auch.

Bei dem Thema "statisch" habe ich letzte Nacht viel probiert und doch einige (für mich)
Ungereimtheiten festgestellt.

Dazu möchte ich mich aber erst später, wenn ich noch Einiges probiert habe, äußern.

???Aber trotzdem, wie kann ich, zum Testen, die Prüfung gegen das config.cache abschalten,
ohne dass ich den ganzen Buildprozess beinflusse??? Ich habe irgendwie das Gefühl, dass ich
bei meinen Tests irgendwelche globalen Variablen während des Builds von siproxd umschreibe.

Wie kann ich das verhindern?

Denn wenn ich einmal das Build so gemacht habe dass der siproxd einwandfrei läuft, dann
kann ich danach an den flags biegen soviel ich will, ich schaffe es dann nicht mehr den
fehlerhaften Build zu reproduzieren. Da hilft auch kein make dirclean o.Ä. nur ein neuer
svn checkout hilft.

-Wanninger

 

[olistudent]

Das einfachste dürfte sein die make/config.cache händisch zu löschen. Ansonsten schau dir doch mal das Makefile von zlib an.

MfG Oliver

 

[gnieder]

Der Tip mit der libz war Gold wert.

Das fertige Kompilat hat noch eine Größe von 288kB. Das sind nochmals knapp 100kB weniger
als bei optimierten dynamischen Variante. Funktionieren tut das Binary bis jetzt auch ohne Fehler.

Danke erstmal für die Unterstützung.

Gruß

Wanninger