Reprise du message précédent :

Bon je suis en train de me mailer le fichier .rar pour pouvoir l'uploader depuis chez moi. Je te le met dans 5 minutes (ma boite mail me bloque la).

Voila :
http://florianwoofy.free.fr/gzip.rar

Dedans il y a le projet Visual, les fichiers cpp, h et c, et la dll zlib ainsi que le zdll.lib

Tu es cruel, je suis sous Dev-C++ à la maison

Bah dsl, j'ai pas :chepas:
Vais voir si je peut pas exporter.

Bon ben on dirait pas, dsl !


T'avait qu'a acheter Visual Studio

Non serieusement, ca me fait chier que ca soit la lib qui ne passe pas ! Parcque ca m'etonnerait que son truc soit developpe comme un porc (bien que j'ai pas trouve grand chose dessus sur google). Mais bon, mon code est tellement simple... et je me fait chier juste pour ca... pfff !

Bon bah grand merci a Pimoose qui m'a aide a "porter" la libzip sous windows !

Bon, je pense que tu peux enlever le "facilement" du titre

Mieux?

Aah, tu t'es mis a libzip finalement !

Et la solution etait ???

Porter libzip sous windows

Ah au fait, vu que de l'autre cote mes binomes ont pourri le serveur, on a tous taffe pour rien, on aura pas le temps d'implementer le module que j'ai fait, et le serveur marche moins bien qu'avant !

Non, je veux dire qu'est-ce qui a cloche dans ce portage justement .. ?

Je me rappel pas tout ! Utilisation d'unistd.h, types ssize_t, droits linux (mode_t), des trucs dans le genre...

PimoOose nous renseignera mieux j'espere

En même temps lui il a pu dormir, et il s'est pas endormi pendant la soutenance

En fait, la libzip est écrite pour *nix, donc y a des appels particuliers (quelques fonctions de fichiers bas niveau), et y avait des fonctions/types bizarres (là je sais pas d'où ça vient) : par exemple, fseeko, ssize_t, et allez savoir pourquoi, VC++ accepte _snprintf mais pas snprintf...

Bon, enfin, ça n'a pas servi à rien, tu as gagné en culture C maintenant

Le 16 septembre 2005 - 14 h 36, Petit_PimoOosE a écrit : En fait, la libzip est écrite pour *nix, donc y a des appels particuliers (quelques fonctions de fichiers bas niveau), et y avait des fonctions/types bizarres (là je sais pas d'où ça vient) : par exemple, fseeko, ssize_t, et allez savoir pourquoi, VC++ accepte _snprintf mais pas snprintf... Bon, enfin, ça n'a pas servi à rien, tu as gagné en culture C maintenant

par exeple pour ssize_t, types.h dit : typedef int ssize_t
encore queje sais pas trop pourquoi c'est pas plutôt typedef int size_t
en tout cas, c'est bien de l'unixerie. Du pas portable, donc, ce qui explique la difficulté rencontrée pour recompiler... Quant à faire fonctionner sans bug, ça aussi c'est une autre paire de manches...

_snprintf est une pure mircrosofterie, et en effet snprintf (qui fait partie de stdio.h et qui est STANDARD) n'est pas dans VC++, tout comme d'autres fonctions ISO ou POSIX. Pourquoi, ben chepa...

C'est là qu'on voit que c'est pas neutre du tout de s'éloigner du C standard. Mais quand on dit ça, tout le monde croit que c'est de la philosophie...

Le 16 septembre 2005 - 14 h 36, Petit_PimoOosE a écrit : En fait, la libzip est écrite pour *nix, donc y a des appels particuliers (quelques fonctions de fichiers bas niveau), et y avait des fonctions/types bizarres (là je sais pas d'où ça vient) : par exemple, fseeko, ssize_t, et allez savoir pourquoi, VC++ accepte _snprintf mais pas snprintf...

Ouais voila, c'est ce que je voulais dire

Bon, enfin, ça n'a pas servi à rien, tu as gagné en culture C maintenant

J'avoue que c'etait pas aussi impossible que je le pensais

Le 16 septembre 2005 - 15 h 33, bernie38 a écrit : Le 16 septembre 2005 - 14 h 36, Petit_PimoOosE a écrit : En fait, la libzip est écrite pour *nix, donc y a des appels particuliers (quelques fonctions de fichiers bas niveau), et y avait des fonctions/types bizarres (là je sais pas d'où ça vient) : par exemple, fseeko, ssize_t, et allez savoir pourquoi, VC++ accepte _snprintf mais pas snprintf... Bon, enfin, ça n'a pas servi à rien, tu as gagné en culture C maintenant par exeple pour ssize_t, types.h dit : typedef int ssize_t encore queje sais pas trop pourquoi c'est pas plutôt typedef int size_t en tout cas, c'est bien de l'unixerie. Du pas portable, donc, ce qui explique la difficulté rencontrée pour recompiler...

Huh, si tu as types.h, tu t'en fous a la limite s'ils le nomment sux_t, non ?? Donc je vois pas ou est le probleme pour recompiler si tu inclus types.h ...

Quant à faire fonctionner sans bug, ça aussi c'est une autre paire de manches... _snprintf est une pure mircrosofterie, et en effet snprintf (qui fait partie de stdio.h et qui est STANDARD) n'est pas dans VC++, tout comme d'autres fonctions ISO ou POSIX. Pourquoi, ben chepa... C'est là qu'on voit que c'est pas neutre du tout de s'éloigner du C standard. Mais quand on dit ça, tout le monde croit que c'est de la philosophie...

+1