gnu scientific library für embedded systems

Die LibC Header, die beim conifgure / build von GSL verwendet werden, sollten diejenigen sein, die auch später in der Appliktion verwendet werden.

Zu versuchen, unterschiedliche LibC-Implementierungen gleichzeitig zu verwenden, ist offensichtlich keine gute Idee... Selbst wenn die Applikation buildet ist nicht ausgeschlossen, dass sie beim Laufen crasht.

okay das verstehe ich, ich hab es leider nicht hinbekommen gsl zu cross-compilen ohne --specs=nano.specs zu verwenden und somit müsste ich ja jetzt nano auch in meinem projekt verwenden, aber das funktioniert nicht so wirklich aus den genannten Gründen

Die erste Anlaufstelle wäre ja die Mailing-Liste in https://www.gnu.org/software/gsl/#mailinglists

Wenn du nen Klotz wie GSL verwendest, dann tut wahrscheinlich auch eine vanilla Newlib nicht weh? Also warum willst du überhaupt nano verwenden?

Und dann mal schauen ob man aus config.sub schlau wird, was da an $os geboten wird. linux-newlib vermutlich nicht :-) Also wird configured für arm-unknown-none oder so?

Und der verwendete GCC verwendet Newlib oder nur per Hacks wie -specs= ?

also ich benutze aus der GSL ja nur ganz wenige funktionen und ich habe leider keine alternative gefunden mit der ich levenberg marquardt algorithmen in C effizient laufen lassen kann.

Ja gsl mailing liste habe ich auch schon probiert, sie haben mir eh bei der kompilierung für ARM M4 sehr geholfen Ich muss nicht unbedingt nano verwenden, für mich wäre es ok wenn einfach alles zusammenpasst und dann kann es irgendwas sein. ich habe in meiner config mit '--specs=nano.specs' und '--specs=nosys.specs' probiert, nosys hilft aber leider auch nicht.

ja es wird konfiguriert für arm-none-eabi, das ist meine configuration:

./configure CC=/usr/local/gcc/bin/arm-none-eabi-gcc CXX=/usr/local/gcc/bin/arm-none-eabi-gcc LD=/usr/local/gcc/bin/arm-none-eabi-gcc AR=/usr/local/gcc/bin/arm-none-eabi-ar OBJCOPY=/usr/local/gcc/bin/arm-none-eabi-objcopy RANLIB=/usr/local/gcc/bin/arm-none-eabi-ranlib CFLAGS="-mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard" CXXFLAGS="-mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard" LDFLAGS="--specs=nosys.specs -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard" LIBRARY_PATH="/usr/local/Cellar/gsl/2.7.1/lib" C_INCLUDE_PATH="/Users/algorithm/lib/gsl-2.7.1/gsl" --target=arm-none-eabi --host=arm-none-eabi

Julius D. schrieb:

also ich benutze aus der GSL ja nur ganz wenige funktionen

Nur den dafür benötigten Sourcecode aus de Lib zu extrahieren ist keine Lösung?

Oliver

an sich ein guter input, ich habe es auch probiert, die gsl ist aber sehr komplex und ich fahre in so viele fehler rein. Vielleicht probiere ich das nochmal, bisher ist das aber eher eine nachgestellte Lösung.

Julius D. schrieb:

./configure CC=... CXX=... LD=... AR=... OBJCOPY=... RANLIB=...

Das sollte doch alles automatisch gefunden werden per --host=arm-none-eabi ?

D.h. arm-none-eabi-gcc verwendet nicht die Newlib?

Da würd ich mich ersma darum kümmern, dass die Toolchain ne gescheite LibC hat, die ohne Hacks funktioniert. Also Newlib als In-Tree target Lib des arm-gcc, evtl auch die Libgloss.

leider nein, ich habe es ohne die Flags probiert, dann wird z.B. die native ranlib meiner build machine genutzt und wirft fehler.

okay also in SES wird ja emRun benutzt soweit ich weiß, muss ich zwangsweise die gleiche libc benutzen für die toolchain?

Julius D. schrieb:

leider nein, ich habe es ohne die Flags probiert, dann wird z.B. die native ranlib meiner build machine genutzt und wirft fehler.

Das sieht dann aber wie ein Bug im confifure.ac der GSL aus. Aber egal, wenn der Workaround geht.

okay also in SES wird ja emRun benutzt soweit ich weiß, muss ich zwangsweise die gleiche libc benutzen für die toolchain?

Keine Ahnung was SES ist.

Wenn man sich die GCC Toolchain generiert, dann kann man die Newlib in-Tree mitgenerieren lassen, so wie z.B. andere Target-Libs auch automatisch mitgeneriert werden (libgcc, libatomic, ...). Dazu linkt man Newlib/newlib als "newlib" ins Top-Level Source-Verzeichnis des GCC, dito für Newlib/libgloss wenn man auch die Libgloss will. Dann configure trallala und man hat eine Toolchain mit Newlib.

Julius D. schrieb:

ich habe leider keine alternative gefunden mit der ich levenberg marquardt algorithmen in C effizient laufen lassen kann.

Wo hast Du denn schon geschaut? "Numerical Recipes in C" und "A Numerical Library in C for Scientists and Engineers" von Lau haben Implementationen von Levenberg-Marquardt. gnuplot verwendet Marquardt-Levenberg zum Fitten und der code ist opensource. Evtl. kann man den extrahieren.

Auf github gibt es auch einiges: https://github.com/search?q=levenberg-marquardt++language%3AC&type=repositories&l=C z.B. https://users.ics.forth.gr/~lourakis/levmar/

Johann L. schrieb:

Keine Ahnung was SES ist.

Julius D. schrieb:

arbeite dabei mit Segger Embedded Studio

hey, um das noch kurz 'aufzulösen'

ich habe am ende den src code der gsl ein bisschen modifiziert (die stellen an denen _impure_ptr vorkommt, waren nur 4 recht irrelevante funktionen) und nochmal von neuem cross kompiliert. Dadurch lässt sich die funktionalität anwenden.

Ich laufe gerade schon in die nächsten 'probleme':

1. man sollte möglichst alle funktionen aus den verwendeten c files, die man NICHT verwendet löschen, da ja .o files komplett verlinkt werden kann das zumindest ein bisschen memory sparen

2. auf dem nrf muss man schon einiges an tweaks veranstalten um mit hoher frequenz rechnen zu können

ich brauche grad keine Hilfe mehr damit aber wollte das nur anmerken falls in Zukunft jemand auf die Idee kommt sowas zu machen und auf diesen Faden stößt.

Julius D. schrieb:

da ja .o files komplett verlinkt werden kann das zumindest ein bisschen memory sparen

Kommt auf den verwendeten Linker an. Wenn der "function level linking" kennt, ist das nicht der Fall.

da hast du recht, ist beim segger studio integrated linker nicht der fall.