delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/06/07/18:22:36

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Robert Collins" <robert DOT collins AT syncretize DOT net>
To: "'Charles Wilson'" <cwilson AT ece DOT gatech DOT edu>
Cc: <Ralf DOT Habacker AT freenet DOT de>, <cygwin AT cygwin DOT com>
Subject: RE: SysV Ipc shm revisited...A new solution
Date: Sat, 8 Jun 2002 08:22:19 +1000
Message-ID: <000e01c20e71$ca0da3a0$0200a8c0@lifelesswks>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3D0119BA.3090407@ece.gatech.edu>


> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com 
> [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Charles Wilson
> Sent: Saturday, 8 June 2002 6:38 AM


> Ah! the fuss was because "key_t" is defined in newlib's 
> types.h file -- 
> which will almost always get included when compiling ipc 
> programs.  But 
> this definition conflicts with what the CURRENT libcygipc.a and 
> ipcdaemon.exe think...so newly compiled, cygipc-based apps 
> will ALWAYS 
> break (at runtime maybe, but more probably at linktime due to 
> conflicting definitions)...more below.
> </rhetorical>
 
Exactly.
 
> So, I'd need to insure that
>    1) ipc-daemon.exe and ipc-daemon2.exe can coexist
>      --> change the ID strings and filenames in IpcNtLit.h, 
> so that new 
> programs use a different ID string when contacting the 
> server, and the 
> new server answers to that new ID string.
>    2) teach ipc-daemon2 (and libcygipc2) that key_t is 64 bits.
> 
> However, in this scenario, there's really no reason for the 
> library name 
> to change.  (But the daemon name MUST change).  The old library, the 
> current libcygipc.a, will be completely useless after 
> cygwin-1.3.11 is 
> released.  So, I might as well let the new (functional) library be 
> libcygipc.a -- that way, existing programs that use libcygipc.a can 
> still -lcygipc and won't need to change their build process 
> to -lcygipc2 
> or somesuch.  But, so that people can have both cygipc daemons 
> running/installed on the same system, the daemon name must be 
> different.
> 
> Furthermore, this modification of the cygipc interface is not 
> "so that 
> people can switch between cygipc and cygdaemon versions 
> easily" -- that 
> still won't be easy, unfortunately.  The mod is necessary "so 
> that you 
> can actually build and link cygipc programs under cygwin-1.3.11".
> 
> Did I get that right, sensei?

The student is learning.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019