Bob Rossi wrote:
On Thu, Feb 02, 2006 at 09:32:27PM +, Eric Blake wrote:
By moving the cygwin1.dll in the executable directory, things begin to
work. However, I don't understand how it's assumed that the new
cygwin1.dll acts the same as the one the executable was linked against.
See what I m
On Thu, Feb 02, 2006 at 09:32:27PM +, Eric Blake wrote:
> > By moving the cygwin1.dll in the executable directory, things begin to
> > work. However, I don't understand how it's assumed that the new
> > cygwin1.dll acts the same as the one the executable was linked against.
> > See what I mean?
On 03 February 2006 02:34, Brian Dessent wrote:
> For example, suppose that the user installs Cygwin and then later
> installs CygwinBasedCommercialProduct (CBCP from here on.) The CBCP
> installer plays nice, notices that the user has Cygwin installed with the
> most recent DLL, so it does not i
Bob Rossi wrote:
> Nice, I was wondering how you could develop on Cygwin without this
> capability. That makes perfect sense. I'm just guessing, but it might be
> a good idea to make this hardcoded constants dynamic, so that any
> arbitrary number of cygwin1.dll's can coexist.
I can imagine that
> So, I guess all I'm saying is it's a complicated issue and there is no
> 100% foolproof way to go if you want to be a provider of Cygwin-based
> software that is meant to interact with other Cygwin-based software --
> other than perhaps introducing your software as an official package, or
> telli
On Thu, Feb 02, 2006 at 05:52:57PM -0800, Brian Dessent wrote:
> Bob Rossi wrote:
>
> > Here's another question I have (sorry). Why wouldn't it be acceptable to
> > have to (different version) cygwin1.dll's running on a single system?
> > That is, 2 completely different Cygwin environments? So, al
On Thu, Feb 02, 2006 at 08:43:52PM -0500, Bob Rossi wrote:
>On Thu, Feb 02, 2006 at 08:38:42PM -0500, Christopher Faylor wrote:
>>I retract my veto. If this is submitted via normal channels, I will
>>have no objections.
>
>Well, I suppose
>
>"anything in computer science is [possible], if you are
Peter Rehley wrote:
> Can we get this added to the faq? It sounds like there are several
> companies out there that install the cygwin1.dll without caring that
> it can cause problems. This would at least provide some information
> for those that read the faq.
I think regardless of what the FAQ
On Feb 2, 2006, at 5:52 PM, Brian Dessent wrote:
Bob Rossi wrote:
Here's another question I have (sorry). Why wouldn't it be
acceptable to
have to (different version) cygwin1.dll's running on a single system?
That is, 2 completely different Cygwin environments? So, all programs
that link ag
Bob Rossi wrote:
> Here's another question I have (sorry). Why wouldn't it be acceptable to
> have to (different version) cygwin1.dll's running on a single system?
> That is, 2 completely different Cygwin environments? So, all programs
> that link against the same cygwin1.dll are in one Cygwin env
On Thu, Feb 02, 2006 at 08:38:42PM -0500, Christopher Faylor wrote:
> On Thu, Feb 02, 2006 at 08:37:12PM -0500, Bob Rossi wrote:
> >On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote:
> >>There's always another alternative - propose to maintain your package
> >>as part of the official cygwi
On Thu, Feb 02, 2006 at 08:37:12PM -0500, Bob Rossi wrote:
>On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote:
>>There's always another alternative - propose to maintain your package
>>as part of the official cygwin distribution. Then you just point
>>people to cygwin.com, and source code
On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote:
> >
> > OK, I understand now, thank you. So, it would be possible to start
> > another process, that has a well known protocol, that distributes the
> > communication between dll's, instead of sharing the memory explicitly?
> >
> > I'm j
On Thu, 2 Feb 2006, Christopher Faylor wrote:
> On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote:
> >[snip a nice summation of the problems with mismatched dlls along with
> >a cogent suggestion for dealing with the problem]
>
> Can I get a gold star here?
Oh, you mean for saying that "
On Thu, Feb 02, 2006 at 09:58:17PM +, Eric Blake wrote:
>[snip a nice summation of the problems with mismatched dlls along with
>a cogent suggestion for dealing with the problem]
Can I get a gold star here?
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem report
>
> OK, I understand now, thank you. So, it would be possible to start
> another process, that has a well known protocol, that distributes the
> communication between dll's, instead of sharing the memory explicitly?
>
> I'm just curious, I know this isn't going to happen.
Yes its possible (prett
On Thu, Feb 02, 2006 at 09:32:27PM +, Eric Blake wrote:
> > OK. I understand the concept of having each application share a single
> > .dll, this is to save space. Unix does this with shared objects.
> >
> > However, here's what I don't understand. Please explain to me why
> > my thinking is
> OK. I understand the concept of having each application share a single
> .dll, this is to save space. Unix does this with shared objects.
>
> However, here's what I don't understand. Please explain to me why
> my thinking is fault. A program called p_v1 depends on v1.dll.
> Another program cal
On Thu, Feb 02, 2006 at 08:42:34PM +, Eric Blake wrote:
> > > No. There must be only ONE cygwin1.dll on your entire system. It
> > > should be in your cygwin /bin directory. Period.
> >
> > Wow, that seems very inflexible. Is this a design decision?
>
> Yes. Cygwin DEPENDS on shared memor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Rossi wrote:
> Wow, that seems very inflexible. Is this a design decision?
Yes.
> Why would 1 cygwin.dll care about another on the system that has nothing
> to do with it?
>
> I have N different versions of our product installed on my windows
>
> > No. There must be only ONE cygwin1.dll on your entire system. It
> > should be in your cygwin /bin directory. Period.
>
> Wow, that seems very inflexible. Is this a design decision?
Yes. Cygwin DEPENDS on shared memory between processes,
in order to emulate POSIX semantics. If you have t
On Thu, Feb 02, 2006 at 02:28:31PM -0600, Yaakov S (Cygwin Ports) wrote:
> Bob Rossi wrote:
> > This is the bin directory where the nx program ran:
> > [EMAIL PROTECTED] /cygdrive/c/Program Files/NX Client for Windows/bin]
> > $ ls -al
> > total 6060
> > drwx--+ 2 bar None 0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Rossi wrote:
> This is the bin directory where the nx program ran:
> [EMAIL PROTECTED] /cygdrive/c/Program Files/NX Client for Windows/bin] $
> ls -al
> total 6060
> drwx--+ 2 bar None 0 Feb 2 14:18 .
> drwx--+ 5 bar
Hi,
I've been plagued with this error message before:
[EMAIL PROTECTED] /cygdrive/c/Program Files/NX Client for Windows/bin] $
./nxssh.exe
c:\Program Files\NX Client for Windows\bin\nxssh.exe (1292): *** proc magic
mismatch
detected - 0xC87757A7/0xD94C588A.
This problem is probably due to using
24 matches
Mail list logo
