Augmenting cygwin woes

Robert Collins
Sat Jun 2 17:53:00 GMT 2001

----- Original Message -----
From: "Jeff Waller" <>
To: "Robert Collins" <>
Cc: <>
Sent: Sunday, June 03, 2001 3:56 AM
Subject: Re: Augmenting cygwin woes

> Robert Collins wrote:
> >----- Original Message -----
> >From: "Jeff Waller" <>
> >
> >Who was "that guy". AFAIK no-one was working on it.
> >
>  From the to-do list, that guy is
> 2000-11-20 {recv,send}msg support
> < >
> O. Paun < >
> Hmm, but perhaps, this is the first guy to ask for it?  If that
> is the case, then I suggest a label for that column "First Requestor"
> which is kinda silly actually.  Since you'd want to contact
> everyone, not just him.  What does it mean anyway?

Actually column labels for that list would probably make sense :] That
list is a list of requested features from the community. So Dimitrie
Paun probably would like to help you test *msg ;].

> >You didn't email or join the cygwin-developers list, which is
> >appropriate for this topic. I suggest you do, as the
> >list is much more relevant to this than the main list.
> >
> As I recall, joining that list is by "invite only," so I was out of
> there.

What that usually means in the open source world, is that you need to
explain why you want to join, rather than it being an automatically
granted right. Thus all you need to do is attempt to join, and the list
moderator will query you (particularly if you haven't been seen on the
cygwin-apps or cygwin mailing list) and then, assuming you actually want
to contribute to the .dll development, you're in.

> >This was is wrong. --prefix should be the final installation
> >not a temporary area.
> >
> Oh, I see.  So something like install in another location and then
> overwrite?
> but that's not possible (see below).

It is _required_.

> >You cannot. Cygwin uses a shared memory area which means that at any
> >time there can only be one version of cygwin in memory. Uses multiple
> >versions _will_ cause problems, which is why cygwin detects that.
> >
> Ok, but you see the reason for it.  What for instance do you do if
> is a
> program avaliable only for a previous version of cygwin that you want
> use on the same machine as an installation of the newest version
> I understand that cygwin must act as a kernel of sorts to allow IPC
> global
> resource allocation, etc.

As you understand that cygwin acts as a kernel of sorts, then it follows
that running two kernels simultaneously won't work :].

The cygwin ABI has not regressed since B20.1. There should be no
binaries that work under an older version that fail under a newer

So the answer to "what do you do if.." is you don't. You backup your old
.dll and install the new one (from outside cygwin).

> >>Second problem:
> >>
> >>Apparently, more than modification of cygwin1.dll
> >>is required to get the new entry points
> >>avaliable.  As the program we're porting still fails
> >>to link (though this might be a matter of recompilation).
> >>We have modified,cygwin.din, and  Is
> >>there something we're missing?
> >>
> >
> >You need to move the built .dll and .lib's to their appropriate
> >locations, or change your mount points after quitting all cygwin
> >programs.
> >
> >Rob
> >
> I was assuming that the setup binary that is built by doing a make
> installed those libraries, etc.  Not so, eh?

The setup binary can be used to install everything, including those
libraries,, but you need to create a install package with the headers
etc in it and add it to the setup.ini. Short answer: copy what you need
over the current install, forget about setup.exe.


Want to unsubscribe from this list?
Check out:

More information about the Cygwin mailing list