Forum TI-Planet.org

Bonjour à la communauté TI,

Je souhaite me remettre à programmer en C sur nspire, cela fait 8 ans que je n'y avais pas remis les pieds. A l'époque, j'avais bien réussi à compiler ndless sdk mais plus depuis maintenant. Je bloque toujours au même point, que j'utilise bash ou cygwin (depuis windows 10 et sur 2 PC différents).
J'ai bien mis en mode développeur windows10. J'ai bien installé les dependencies de cygwin comme indiqué sur la page ndlessly/github/hackspire, et j'ai bien downloadé avec succès ndless-sdk depuis git.
Mais je bloque toujours au moment du buid :




A noter que je suis bien dans le bon répertoire. Comme on le voit sur l'image, rien ne se passe.
Quelqu'un à t-il une idée du problème ?
Vous remerciant par avance.

C'est curieux que rien ne s'affiche, ça doit vouloir dire que quelque chose échoue très tôt dans l'exécution du script. Pour pouvoir exécuter le script, il faut quand même un minimum de choses installées dans l'environnement Cygwin, dont un interpréteur Python 3 (il me semble, en tout cas "python3" est lancé avant la première ligne qui affiche quelque chose) et gcc. https://hackspire.org/index.php/C_and_a ... troduction en liste plusieurs autres.

Transforme le

Code: Tout sélectionner

set -eu

qui est au début du script en

Code: Tout sélectionner

set -eux

, et relance le script. Ca devrait donner une indication de l'origine de l'échec.

Note que d'une manière générale, pour des raisons de performance (taux de création des processus, accès disque), tu devrais utiliser un vrai Linux (non, pas WSL2, même si j'avais vu qu'il peut gommer certaines inefficacités de Windows notamment dans les accès disque, ce dont WSL1 qui avait l'avantage de ne pas utiliser de virtualisation est incapable) ou BSD pour développer...
Pour l'exercice, je suis en train de compiler le SDK Ndless sous Cygwin sous Win10 x64 virtualisé: c'est toujours vraiment beaucoup plus lent que sous Linux (EDIT: 2h plus tard, on n'en est toujours qu'au build de GCC), et ce n'est clairement pas seulement dû à la virtualisation. J'ai attribué 4 VCPUs à la VM, le host a 4 coeurs. C'est pour ça que j'ai abandonné Windows très tôt dans le développement de libti*/gfm/tilp, et que j'ai travaillé sur l'automatisation de la cross-compilation de GCC4TI: au fil des années, je pense que j'ai ainsi gagné du temps.
C'est aussi parce que Windows est lent pour la création de processus et les accès disque que non seulement le fuzzing de logiciels portables se fait souvent sur Linux, mais que certains morceaux de logiciels closed source ne fonctionnant que sur Windows (pro-virus MS, par exemple, par James Forshaw et. al) sont fuzzés sous Linux grâce à des couches de compatibilité / émulation.

Merci pour la réponse,
J'ai remplacé : set -eu par set -eux
et voila ce que cela renvoie :



Je ne sais pas ce que ca veut dire....

newprog_creator a écrit:Merci pour la réponse,
J'ai remplacé : set -eu par set -eux
et voila ce que cela renvoie :



Je ne sais pas ce que ca veut dire....

On dirait que python 3 n'est pas disponible sur ton systeme.
Essaie de l'installer et relance la meme procedure pour voir si il y a du mieux...

Sly

Hackspire precise que seule la version 32bits de Cygwin fonctionne.

As tu bien installé les dépendances suivantes : php (5.6+), libboost-devel, libboost_program_options*, binutils, gcc-core, gcc-g++, git, mpfr, mpfr-devel, gmp, libgmp-devel, libmpc3, libmpc-devel, make, zlib-devel, wget
(et python 3 + python 3 dev) ?

Il y en aura besoin a un moment ou un autre dans le processus d'installation

Sly

Ouais, c'est donc bien qu'il manque Python 3, qui n'est pas listé sur Hackspire.
Les noms de packages sont différents sous Cygwin, les packages de dev ont souvent "lib" au début et "-devel" à la fin.

Pour l'instant, mon build sur Cygwin 64 bits est toujours en cours. On arrive bientôt à 3h30 wall clock... La virtualisation et le pro-virus n'expliquent pas tout. Fondamentalement, les scripts configure utilisent beaucoup de processus, donc c'est lent sous Windows et on ne peut rien y faire.

EDIT 16h00: c'est le build de GDB qui a fini par échouer sous Cygwin 64 bits:

Code: Tout sélectionner

cp-support.o: in function `gdb_demangle(char const*, int)':
.../Ndless/ndless-sdk/toolchain/build/gdb/../../download/gdb-9.1/gdb/cp-support.c:1552:(.text+0x1d42): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for thread_local_segv_handler'
.../Ndless/ndless-sdk/toolchain/build/gdb/../../download/gdb-9.1/gdb/cp-support.c:1552:(.text+0x1d5b): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for thread_local_segv_handler'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1908: gdb.exe] Error 1
make[2]: Leaving directory '.../Ndless/ndless-sdk/toolchain/build/gdb'
make[1]: *** [Makefile:9567: all-gdb] Error 2
make[1]: Leaving directory '.../Ndless/ndless-sdk/toolchain/build'
make: *** [Makefile:855: all] Error 2

Ca a pris moins de 6h au total pour en arriver là... une paille.

Merci pour votre aide
J'ai installé les dependencies python3 et libpython-devel et le processus s'est lancé...

Pour info, pour installer de nouvelles dependencies sous cygwin32bits, il faut lancer :

wget https://raw.githubusercontent.com/trans ... er/apt-cyg
chmod +x apt-cyg
mv apt-cyg /usr/local/bin

On installe les dependencies demandées ici en lancant :

apt-cyg install python3
puis
apt-cyg install libpython-devel

Je vous tiens au courant du déroulement du processus
Merci encore

Rahh, à peine mon dernier post envoyé, j'ai l'erreur suivante :



Désolé d'être pénible mais si vous pouvez m'aider encore une fois...ce serait vraiment chouette

Pas d'inquiétude, on est là pour aider.

Par contre ton screenshot ne montre pas l'erreur, juste la fin. Il va falloir montrer d'avantage de lignes

En réponse, je joints un fichier texte contenant tout ce qui est apparu sur l'écran. Y a beaucoup de lignes...