Lilo et compilation

["F.Boisson" <fboisson@worldnet.fr>]

Bonjour,

1) Toujours pour le futur réseau, j'ai voulu patcher Lilo pour interdire
les options lors du boot. Il est indispensable que les machines puissent
tourner sous W95 (logiciel chimie), des verrous empêchant l'accès au
lecteur disquette, lilo s'impose (de préférence à loadlin car si W95 plante
ce qui arrive souvent, on ne peut rien faire!). Le patch est assez simple;
à la saisie de la ligne de commande, le caractères espace est remplacé et
traité comme un CR (fichier second.S). Le problème est que même sans patch,
la compilation de lilo donne:

(sous /home/francois/lilo/lilo-20)
$ make
cc -c -Wall -g `( if [ -r $ROOT/etc/lilo.defines ]; then cat
$ROOT/etc/lilo.defines; else echo -DIGNORECASE -DVARSETUP; fi ) | sed
's/-D/-DLCF_/g'` `[ -r /usr/include/asm/boot.h ] && echo -DHAS_BOOT_H`
lilo.c
In file included from common.h:10,
                 from lilo.c:17:
/usr/include/linux/genhd.h:82: parse error before `__u32'
/usr/include/linux/genhd.h:82: warning: no semicolon at end of struct or
union
/usr/include/linux/genhd.h:83: warning: data definition has no type or
storage class
....

le fichier /usr/include/linux/genhd.h lui est à partir de la ligne 75

.............
#define BSD_PARTITION		0xa5	/* Partition ID */

#define BSD_DISKMAGIC	(0x82564557UL)	/* The disk magic number */
#define BSD_MAXPARTITIONS	8
#define BSD_FS_UNUSED		0	/* disklabel unused partition entry ID */
struct bsd_disklabel {
	__u32	d_magic;		/* the magic number */
	__s16	d_type;			/* drive type */
	__s16	d_subtype;		/* controller/d_type specific */
	char	d_typename[16];		/* type name, e.g. "eagle" */
	char	d_packname[16];			/* pack identifier */ 
...........
Tout va bien donc, le type __u32 est un long unsigned int défini dans
<asm/types.h>

Si on le redéfinit par un include subtil, rien ne change.

Cela m'arrive également à la compilation de wine. Je n'ai aucune idée de ce
qui se passe et pense à un problème de configuration de gcc puisque les
sources sont corrects et (j'imagine) non buggés.

2) Lorsque alien transforme un paquet rpm en un paquet Debian, il me semble
que les dépendances sont traitées mais que la localisation des fichiers
peut ne pas être celle prévu dans le paquet estampillé Debian d'origine. Je
me trompe?

Merci à tous

François BOISSON

PS: libXpm.so.4 est  la librairie Xpm (figurant dans la rubrique oldlibs
(dist
Debian 2.0). Ce sont des routines graphiques particulières si ma mémoire
est bonne, Wp8 les utilisent effectivement. La version doit être la 4.7
dans la distribution 2.0.