tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Tsp-devel] Chti prob de compil


From: PAGNOT, Robert
Subject: RE: [Tsp-devel] Chti prob de compil
Date: Thu, 23 Sep 2004 08:44:08 +0200

Je réponds sur le pb GETOPT (vive le ping-pong ...)

        Solaris : #include <stdlib.h>, mais c'est une erreur, voir
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00757.html
        Linux : #include <unistd.h>
        VxWorks : n'existe pas, mais on s'en fout ...
        OpenBSD : je ne sais pas, tu dis donc #include <getopt.h> ? Le GNU
indique bien unistd.h ...

Je pense que l'include de unistd sera suffisant. Ceci étant, il est vrai que
la compil d'un client_res est plutôt chargée d'autres petits pbs. Nettoyage
en cours ...

A+
        Bob


> -----Original Message-----
> From: Frederik Deweerdt [mailto:address@hidden
> Sent: Thursday, September 23, 2004 12:19 AM
> To: address@hidden
> Subject: [Tsp-devel] Chti prob de compil
> 
> 
> Lut,
> 
> OpenBSD lève un sourcil suspicieux sur client_res.c :) 
> Ci-joint un patch qui lui permet
> de retrouver ses petits.
> J'avais commencé à me poser des questions sur l'ajout d'un 
> protocole de transport
> Corba, XML/RPC ou HTTP avec surcouche maison. Je me demandais 
> si quelqu'un avait 
> déjà une idée sur l'architecturation de la chose: faut-il 
> développer des libs 
> tsp client et serveur parallèles à leur cousines RPC? 
> Elles auraient, j'imagine, le mode opératoire suivant:
> Je fais mon server et mon consumer tsp, et je les linke 
> ensuite à la lib de mon choix
> rpc ou corba. Et là surgit un problème: un client corba ne 
> comprend que du corba...
> Ou alors me fourvois-je et dans ce cas quelqu'un serait-il 
> assez aimable pour éclairer 
> ma lanterne?
> 
> A+
> Fred
> 

Attachment: important_notice.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]