Forum Linux.embarqué [80386][linux 1.0] Problème de compil

Posté par . Licence CC by-sa
Tags : aucun
1
16
avr.
2015

Bonjour,
j'ai posté dans la partie embarqué alors que je pose une question pour du pc, mais bon, j'ai trouvé un vieux PC (mais alors vieux, mais vieux…, des années 90, mais du début, voir fin 80, bref…). La config en question
- Ram: 4 Mo
- Proco: 80386
Comme le bazar est assez ancien et plus très courrant, je me suis permis de mettre le post en embarqués.
Je pensait prendre une distro hyper light (genre BasicLinux), mais ces trucs, ce sont des gouffres à RAM (pas moint de 8Mo qu'ils demandent, et pour la version light).
Du coups je pensais me faire un truc quasi ex-nihilo. Je me suis fait mon petit environnement de compilation croisée (c'est plus propre que de rajouter des -m32 partout non ?).
Alors déjà la version de linux (1.0) est déja assez ancienne (1994), quelques truc chelou (genre '#ifndef 0', gcc aime pas trop), ça passe c'est pas très long.
Bon le problème que j'ai actuellement est le suivant
error: 'asm' operand has impossible constraints__asm__("cld\n\t"
le code en question c'est la fonction 'strchr' de string.h

    extern inline char * strchr(const char * s,char c)
    {
    register char * __res __asm__("ax");
    __asm__("cld\n\t"
        "movb %%al,%%ah\n"
        "1:\tlodsb\n\t"
        "cmpb %%ah,%%al\n\t"
        "je 2f\n\t"
        "testb %%al,%%al\n\t"
        "jne 1b\n\t"
        "movl $1,%1\n"
        "2:\tmovl %1,%0\n\t"
        "decl %0"
        :"=a" (__res):"S" (s),"0" (c):"si");
    return __res;
    }

J'ai regardé sur des forums, j'ai pas trouvé grand chose de concluant…
J'ai refait la fonction en C, et là je vois que pour toutes les fonctions (avec l'asm) c'est la meme chose, ou beaucoup en tout cas.

Donc savez vous d'ou ça vient ? (Peut etre compilable par le gcc de l'époque: 2.4.5, et plus maintenant, comme pour le #ifndef 0 ?)
Et surtout, savez vous comment corriger/contourner ces erreurs ?

Merci,
Fanch

  • # minix/elks ?

    Posté par . Évalué à 1.

    Salut,

    Vu la quantité de RAM, je serais reparti sur autre chose que du linux (même si le proc est OK à priori), comme minix ou elks.

    La mailing-liste ELKS - et donc je suppose le projet - renait un peu de ses cendres en ce moment, après quelques années de mutisme :)

    Du coup, vu le nom (E pour Embeddable et L pour Lunix), ça pourrait peut-être coller avec tes recherches, même si ce n'est pas du linux « standard » ? Mais bon, comme ils disent en page de garde :

    We still have a long way to go

    • [^] # Re: minix/elks ?

      Posté par . Évalué à 1.

      Ok, merci, j'ai oublié de préciser que pour le PC en question, je ne compte pas faire de bureautique (avec 4Mo de ram la bureautique ça se limite à vi, voire vim !), mais c'est pour bidouiller dans les coins l'interfacer avec d'autres systèmes (genre un Core2 Duo, arduino Raspberryi, Pentium I, enfin tout ce qui traîne). Et aussi/surtout à des fins pédagogiques (au niveau noyau) !
      Linux 1.0 doit (je pense) être vachement plus accessible à un "débutant" que la toute fraîche 4.0.

      Donc ELKS est encore maintenu, je pense que ça pourrait faire une bonne solution "de replis", et linux 1.0, mais j'aimerais bien pouvoir le compiler… (au moins pour le coté "historique").

      Pour Minix, je pense que je ne peux utiliser que les version 1.x et 2.x, seulement je ne trouve pas leurs sources, je n'ai trouvé que pour les 3.x. C'est vrai que pour le coté historique, la 1.0 de minix c'est plutôt classe.

      Pas d'idées sur l'erreur de gcc  ?

  • # chelou ?

    Posté par (page perso) . Évalué à 2.

    quelques truc chelou (genre '#ifndef 0', gcc aime pas trop)

    Tu pourrais préciser ?

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: chelou ?

      Posté par . Évalué à 1. Dernière modification le 16/04/15 à 08:54.

      Ouai, gcc attend un id et pas un nombre du genre:

      #ifndef UN_TRUC_QUI_N_EXISTE_PAS

      ou

      #if 0

      mais pas le mélange des 2.
      je pense que c'est peut etre la syntaxe de gcc qui a changé en 21 ans non.
      Enfin si c'est le cas, il y a certainement d'autres trucs du genre dans le code…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.