Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Wed, Mar 30, 2005 at 11:20:16AM -0800, Jim Kleckner wrote:
>Christopher Faylor wrote:
>
>>On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote:
>
>>>Then strike the link text and limit it to the workaround of adding
>>>the bin to the system path.   My text was a suggested starting point.
>>
>>i.e., a workaround.
>>
The solution that the DLL has to be in the system path is not required
for a sanctioned Cygwin release.  But, then, we've seen before that
clamwin insists on running in a non-cygwin environment.  I don't want
to be in the business of adding advice to the FAQ for fixing up other
people's problems.
>>>
>>>Nobody said the workaround was required.
>>
>>
>>See above.
>
>Above does not say the workaround is required nor did the original
>text.

Ah, semantic fun.  Ok.  I do not want to have an entry in the FAQ which
"suggests" a workaround of setting the system PATH environment variable
to work around other people's problems.

>You complain about 3PPs but don't want to provide any easily found
>directions to them about what not to do.  You can say "search the list"
>but as a practical matter, it isn't effective at guiding their
>behavior.

Corinna already said that she thought that instructions are a good idea.
I am not against providing instructions to 3PPs.  As I said today:

>The problem with a "third party packager's guide" is that it would have
>to be written by a third party who understands the whole deal.  I'm not
>aware of anyone actually trying to do this right.

On rereading this thread, I see that you've volunteered to come up to
speed on this subject so, maybe I was wrong.

Patches tacitly awaited.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote:

Then strike the link text and limit it to the workaround of adding
the bin to the system path.   My text was a suggested starting point.

i.e., a workaround.

The solution that the DLL has to be in the system path is not required
for a sanctioned Cygwin release.  But, then, we've seen before that
clamwin insists on running in a non-cygwin environment.  I don't want to
be in the business of adding advice to the FAQ for fixing up other
people's problems.
Nobody said the workaround was required.

See above.
Above does not say the workaround is required nor did the original
text.
You complain about 3PPs but don't want to provide any easily found
directions to them about what not to do.  You can say "search
the list" but as a practical matter, it isn't effective at guiding
their behavior.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Wed, Mar 30, 2005 at 09:57:44AM -0800, Jim Kleckner wrote:
>Christopher Faylor wrote:
>
>>On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote:
>
>>So, if you're a Unix guy since 1978, that puts you in a unique category.
>>You don't qualify as a FAQ.
>
>I don't quite understand this.  I don't qualify to write FAQ entries
>or shouldn't be allowed to use them?

"F"requently "A"sked "Q"uestions.


>>I have very strong reservations about filling up documentation with
>>every conceivable combination of advice that we could possibly think of.
>>Adding rationales to stop Unix guys from shooting themselves in the foot
>>should not be a focus of the FAQ.  The FAQ is there to give advice to
>>people on what to do, not to provide rationales for why they shouldn't
>>do other things that pop into their heads.
>
>Then strike the link text and limit it to the workaround of adding
>the bin to the system path.   My text was a suggested starting point.

i.e., a workaround.

>>The solution that the DLL has to be in the system path is not required
>>for a sanctioned Cygwin release.  But, then, we've seen before that
>>clamwin insists on running in a non-cygwin environment.  I don't want to
>>be in the business of adding advice to the FAQ for fixing up other
>>people's problems.
>
>Nobody said the workaround was required.

See above.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote:

So, if you're a Unix guy since 1978, that puts you in a unique category.
You don't qualify as a FAQ.
I don't quite understand this.  I don't qualify to write FAQ entries
or shouldn't be allowed to use them?
I have very strong reservations about filling up documentation with
every conceivable combination of advice that we could possibly think of.
Adding rationales to stop Unix guys from shooting themselves in the foot
should not be a focus of the FAQ.  The FAQ is there to give advice to
people on what to do, not to provide rationales for why they shouldn't
do other things that pop into their heads.
Then strike the link text and limit it to the workaround of adding
the bin to the system path.   My text was a suggested starting point.
Look, all I'm trying to do here is save time for other people, not
waste all of our time.  The notion that the email list should be
the primary reference for this kind of issue is wrong.  And it shouldn't
be this hard to try to help out either.

The solution that the DLL has to be in the system path is not required
for a sanctioned Cygwin release.  But, then, we've seen before that
clamwin insists on running in a non-cygwin environment.  I don't want to
be in the business of adding advice to the FAQ for fixing up other
people's problems.
Nobody said the workaround was required.
I am very grateful for the great lengths you go to to fix other people's
problems who use cygwin.
If this is a problem with clamwin then people should be lobbying them
for a fix, not suggesting that the Cygwin FAQ has to be modified as
a workaround.
Agree that clamwin should be fixed.  I don't use it and don't care to
use it.  But then I share the compute resources.
Jim
- "It is better to light a candle than curse the darkness"
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Wed, Mar 30, 2005 at 08:45:10AM -0800, Jim Kleckner wrote:
>Christopher Faylor wrote:
>
>>On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote:
>>
>>>Christopher Faylor wrote:
>>>
OTOH, perhaps I'm oversimplifying things, but it seems like this thread
went on for quite a while after the simple "delete the nonstandard DLL"
advice was given.  I don't see how any advice is going to be useful if
it isn't followed.
>>>
>>>I agree completely.  All the more reason to pull the concise answers
>>>out of the email list and into the FAQ.  This thread wouldn't have
>>>existed at all.
>>
>>
>>The concise answer is already in *cygwin itself*.  The FAQ could
>>arguably be updated to say "delete the dll that is not in
>>c:\cygwin\bin".  I guess it is assuming that someone has actually
>>taken the time to read the error that cygwin presents.
>>
>>However, again, this concise answer was mentioned in the email list and
>>not followed.  I don't know why anyone would view the FAQ as more
>>authoritative than the people they are soliciting for help here.
>
>Not true at all.  The suggestion was followed.
>
>Note that the FAQ does not state to put the cygwin bin on the system 
>path.  Of course I knew that it would work to do that.  As a Unix guy
>since 1978, I was curious to try using ln to see what it would do. 
>Larry Hall helpfully pointed out that while it would work, it was a 
>brittle solution.

So, if you're a Unix guy since 1978, that puts you in a unique category.
You don't qualify as a FAQ.

I have very strong reservations about filling up documentation with
every conceivable combination of advice that we could possibly think of.
Adding rationales to stop Unix guys from shooting themselves in the foot
should not be a focus of the FAQ.  The FAQ is there to give advice to
people on what to do, not to provide rationales for why they shouldn't
do other things that pop into their heads.

>Look, all I'm trying to do here is save time for other people, not
>waste all of our time.  The notion that the email list should be
>the primary reference for this kind of issue is wrong.  And it shouldn't
>be this hard to try to help out either.

The solution that the DLL has to be in the system path is not required
for a sanctioned Cygwin release.  But, then, we've seen before that
clamwin insists on running in a non-cygwin environment.  I don't want to
be in the business of adding advice to the FAQ for fixing up other
people's problems.

If this is a problem with clamwin then people should be lobbying them
for a fix, not suggesting that the Cygwin FAQ has to be modified as
a workaround.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote:
Christopher Faylor wrote:
OTOH, perhaps I'm oversimplifying things, but it seems like this thread
went on for quite a while after the simple "delete the nonstandard DLL"
advice was given.  I don't see how any advice is going to be useful if
it isn't followed.
I agree completely.  All the more reason to pull the concise answers
out of the email list and into the FAQ.  This thread wouldn't have
existed at all.

The concise answer is already in *cygwin itself*.  The FAQ could
arguably be updated to say "delete the dll that is not in
c:\cygwin\bin".  I guess it is assuming that someone has actually
taken the time to read the error that cygwin presents.
However, again, this concise answer was mentioned in the email list and
not followed.  I don't know why anyone would view the FAQ as more
authoritative than the people they are soliciting for help here.
Not true at all.  The suggestion was followed.
Note that the FAQ does not state to put the cygwin bin on the system 
path.  Of course I knew that it would work to do that.  As a Unix guy
since 1978, I was curious to try using ln to see what it would do. 
Larry Hall helpfully pointed out that while it would work, it was a 
brittle solution.

Look, all I'm trying to do here is save time for other people, not
waste all of our time.  The notion that the email list should be
the primary reference for this kind of issue is wrong.  And it shouldn't
be this hard to try to help out either.
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Wed, Mar 30, 2005 at 08:08:16AM -0800, Jim Kleckner wrote:
>Christopher Faylor wrote:
>>OTOH, perhaps I'm oversimplifying things, but it seems like this thread
>>went on for quite a while after the simple "delete the nonstandard DLL"
>>advice was given.  I don't see how any advice is going to be useful if
>>it isn't followed.
>
>I agree completely.  All the more reason to pull the concise answers
>out of the email list and into the FAQ.  This thread wouldn't have
>existed at all.

The concise answer is already in *cygwin itself*.  The FAQ could
arguably be updated to say "delete the dll that is not in
c:\cygwin\bin".  I guess it is assuming that someone has actually
taken the time to read the error that cygwin presents.

However, again, this concise answer was mentioned in the email list and
not followed.  I don't know why anyone would view the FAQ as more
authoritative than the people they are soliciting for help here.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Christopher Faylor wrote:
OTOH, perhaps I'm oversimplifying things, but it seems like this thread
went on for quite a while after the simple "delete the nonstandard DLL"
advice was given.  I don't see how any advice is going to be useful if
it isn't followed.
I agree completely.  All the more reason to pull the concise answers
out of the email list and into the FAQ.  This thread wouldn't have
existed at all.
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Wed, Mar 30, 2005 at 09:31:50AM +0200, Corinna Vinschen wrote:
>The idea of a "third party packager's guide" sounds good to me.  I'd
>rather have third parties not to pack Cygwin in their packages at all
>and to point the user to install Cygwin from cygwin.com instead, but I
>guess that's rather unrealistically.

The problem with a "third party packager's guide" is that it would have
to be written by a third party who understands the whole deal.  I'm not
aware of anyone actually trying to do this right.

OTOH, perhaps I'm oversimplifying things, but it seems like this thread
went on for quite a while after the simple "delete the nonstandard DLL"
advice was given.  I don't see how any advice is going to be useful if
it isn't followed.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Corinna Vinschen]

On Mar 29 22:55, Larry Hall wrote:
> At 05:49 PM 3/29/2005, you wrote:
> >If there is interest, I am willing to take a crack at pulling
> >together the information that is sprinkled in email threads
> >about how to avoid trampling on existing cygwin installations.
> >
> >Eventually, there really should be a section in the user guide
> >about the topic "How (and how not) to create and distribute an
> >application that depends on cygwin".  I'm willing to help with
> >that but I suspect other people can write something many times
> >more quickly and more accurately.
> 
> 
> I think this is a great idea, though perhaps this is more appropriate as
> the basis for a "third party packager's guide".  Although it is not really 
> hard to make a third party package that plays nice with Cygwin, if the 
> Cygwin site provides a helpful recipe and guidelines, there's a chance 
> we'll see more compliance, if only because we can then shame people into 
> it. ;-)  If you're willing to put together the substance of this and neither
> Chris nor Corinna dislike the idea, please post what you come up with to 
> this list.  I, for one, would be happy to review your contribution.

The idea of a "third party packager's guide" sounds good to me.  I'd rather
have third parties not to pack Cygwin in their packages at all and to point
the user to install Cygwin from cygwin.com instead, but I guess that's
rather unrealistically.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Larry Hall]

At 05:49 PM 3/29/2005, you wrote:
>Larry Hall wrote:
>> At 10:20 PM 3/24/2005, Brian Dessent wrote:
>>> A symlink won't work, because it's Windows own loader that searches
>>> for and loads any .DLLs called for by an .exe. Windows does not
>>> understand symlinks as they are a Cygwin thing, so you can't
>>> symlink a DLL and expect it to load.
>>>
>>> NTFS does not support symbolic links but it does support hard
>>> links, see
>>> .
>>>  If the volume is NTFS, 'ln' will use this capability. On 9x or FAT
>>> it will make a copy (I think.)
>
>Right, that is what I saw.  Symlink failed but hard link worked.
>
>> Right. It will. It's also worth noting that hard links break again as
>>  soon as you update either clamwin or Cygwin, even on NTFS volumes.
>> Alternatively, if you make sure that clamwin can see your Cygwin
>> installation, it will seamlessly work through Cygwin updates. But the
>>  only way you're going to get clamwin to work seamlessly through
>> updates of clamwin is to get clamwin's installation to change.
>
>A compelling reason to not use hard links.
>
>OK, one last attempt, in the spirit of PTC and to help fellow
>travelers.  The existing FAQ entry at this location reads:
>  http://cygwin.com/faq/faq_3.html#SEC50
>
>Is it OK to have multiple copies of the DLL?
>
>You should only have one copy of the Cygwin DLL on your
>system. If you have multiple versions, they will conflict
>and cause problems.
>
>If you get the error "shared region is corrupted" or "shared
>region version mismatch" it means you have multiple versions
>of cygwin1.dll running at the same time. This could happen,
>for example, if you update cygwin1.dll without exiting all
>Cygwin apps (including inetd) beforehand.
>
>If you're trying to find multiple versions of the DLL that
>are causing this problem, reboot first, in case DLLs still
>loaded in memory are the cause. Then use the Windows System
>find utility to search your whole machine, not just
>components in your PATH (as 'type' would do) or
>cygwin-mounted filesystems (as Cygwin 'find' would do).
>
>Based on the information in this thread, I would suggest some
>variation of the following additional paragraph at the end of
>that text:
>
>When you find copies of cygwin1.dll remove all of them
>except the cygwin-installed version.  As a workaround, you
>might be able to make the offending application work with

 ^
This should say "will".


>the installed DLL by adding the cygwin bin directory to your
>system path environment variable.  Although you could hard
>link the cygwin DLL into the location of the application
>directory containing the duplicate copy instead of changing
>the system path, this is not a good idea because when you
>update the cygwin package, that link will break and you will
>once again have two copies of the cygwin DLL.
>
>Hopefully, this will help fellow travelers and is in the
>interest of reducing the amount traffic on this list.  Such
>common problems seem logical to me to document in the FAQ rather
>than wasting the OP's time and everyone on the list.  If there
>is a place where this is already documented, the FAQ should
>point there.


Beyond the email archives, no this isn't documented anywhere.  
Judging by the previous responses to adding something like this
to the FAQ, for reasons already covered, I doubt this will be 
added as part of the FAQ.  But I don't speak for anyone but
myself.


>If there is interest, I am willing to take a crack at pulling
>together the information that is sprinkled in email threads
>about how to avoid trampling on existing cygwin installations.
>
>Eventually, there really should be a section in the user guide
>about the topic "How (and how not) to create and distribute an
>application that depends on cygwin".  I'm willing to help with
>that but I suspect other people can write something many times
>more quickly and more accurately.


I think this is a great idea, though perhaps this is more appropriate as
the basis for a "third party packager's guide".  Although it is not really 
hard to make a third party package that plays nice with Cygwin, if the 
Cygwin site provides a helpful recipe and guidelines, there's a chance 
we'll see more compliance, if only because we can then shame people into 
it. ;-)  If you're willing to put together the substance of this and neither
Chris nor Corinna dislike the idea, please post what you come up with to 
this list.  I, for one, would be happy to review your contribution.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Pr

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Larry Hall wrote:
> At 10:20 PM 3/24/2005, Brian Dessent wrote:
>> A symlink won't work, because it's Windows own loader that searches
>> for and loads any .DLLs called for by an .exe. Windows does not
>> understand symlinks as they are a Cygwin thing, so you can't
>> symlink a DLL and expect it to load.
>>
>> NTFS does not support symbolic links but it does support hard
>> links, see
>> 
.
>>  If the volume is NTFS, 'ln' will use this capability. On 9x or FAT
>> it will make a copy (I think.)

Right, that is what I saw.  Symlink failed but hard link worked.
> Right. It will. It's also worth noting that hard links break again as
>  soon as you update either clamwin or Cygwin, even on NTFS volumes.
> Alternatively, if you make sure that clamwin can see your Cygwin
> installation, it will seamlessly work through Cygwin updates. But the
>  only way you're going to get clamwin to work seamlessly through
> updates of clamwin is to get clamwin's installation to change.
A compelling reason to not use hard links.
OK, one last attempt, in the spirit of PTC and to help fellow
travelers.  The existing FAQ entry at this location reads:
  http://cygwin.com/faq/faq_3.html#SEC50
Is it OK to have multiple copies of the DLL?
You should only have one copy of the Cygwin DLL on your
system. If you have multiple versions, they will conflict
and cause problems.
If you get the error "shared region is corrupted" or "shared
region version mismatch" it means you have multiple versions
of cygwin1.dll running at the same time. This could happen,
for example, if you update cygwin1.dll without exiting all
Cygwin apps (including inetd) beforehand.
If you're trying to find multiple versions of the DLL that
are causing this problem, reboot first, in case DLLs still
loaded in memory are the cause. Then use the Windows System
find utility to search your whole machine, not just
components in your PATH (as 'type' would do) or
cygwin-mounted filesystems (as Cygwin 'find' would do).
Based on the information in this thread, I would suggest some
variation of the following additional paragraph at the end of
that text:
When you find copies of cygwin1.dll remove all of them
except the cygwin-installed version.  As a workaround, you
might be able to make the offending application work with
the installed DLL by adding the cygwin bin directory to your
system path environment variable.  Although you could hard
link the cygwin DLL into the location of the application
directory containing the duplicate copy instead of changing
the system path, this is not a good idea because when you
update the cygwin package, that link will break and you will
once again have two copies of the cygwin DLL.
Hopefully, this will help fellow travelers and is in the
interest of reducing the amount traffic on this list.  Such
common problems seem logical to me to document in the FAQ rather
than wasting the OP's time and everyone on the list.  If there
is a place where this is already documented, the FAQ should
point there.
If there is interest, I am willing to take a crack at pulling
together the information that is sprinkled in email threads
about how to avoid trampling on existing cygwin installations.
Eventually, there really should be a section in the user guide
about the topic "How (and how not) to create and distribute an
application that depends on cygwin".  I'm willing to help with
that but I suspect other people can write something many times
more quickly and more accurately.
Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Igor Pechtchanski]

On Thu, 24 Mar 2005, Jim Kleckner wrote:

> PS.  Since cgf is steadfast, perhaps this explanation could be added to
> the FAQ entry located here that partially explains why multiple dlls is
> a problem:
>  http://cygwin.com/faq/faq_3.html#SEC50

We have a link for such applications: .
I'd be willing to add a link to the page that lists known 3PPs, if someone
else offered to maintain such a list.  We can then point people to the 3PP
acronym entry.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Larry Hall]

At 10:20 PM 3/24/2005, you wrote:
>Jim Kleckner wrote:
>
>> This is helpful, thank you.  Being curious and trying to be minimal
>> about changes
>> to the system in question, I tried removing and linking the dll in
>> place.  I first tried
>> "ln -s /bin/cygwin1.dll" in the clamwin/bin directory and wasn't
>> surprised that it
>> didn't work.  Being Unix person by background, I then tried "ln
>> /bin/cygwin1.dll"
>> and that surprised me by working.  I expected to see an NTFS cygwin1.dll.lnk
>> file in there but using "cmd.exe" and "dir" or the windows explorer
>> looks like a
>> full copy of the dll file.  An "ls -l" tantalizingly shows a link count
>> of 2.  "info ln"
>> doesn't give any cygwin-specific info.  The section of the user guide
>> located here:
>>   http://cygwin.com/cygwin-ug-net/using-effectively.html#id2950938
>> has some wording that implies this might work but isin't definitive.
>> 
>> My question now is, can "ln" be used to work around this issue or is
>> that a "bad idea"?
>
>A symlink won't work, because it's Windows own loader that searches for
>and loads any .DLLs called for by an .exe.  Windows does not understand
>symlinks as they are a Cygwin thing, so you can't symlink a DLL and
>expect it to load.
>
>NTFS does not support symbolic links but it does support hard links, see
>.
> 
>If the volume is NTFS, 'ln' will use this capability.  On 9x or FAT it
>will make a copy (I think.)


Right.  It will.  It's also worth noting that hard links break again as 
soon as you update either clamwin or Cygwin, even on NTFS volumes.   
Alternatively, if you make sure that clamwin can see your Cygwin 
installation, it will seamlessly work through Cygwin updates.  But the
only way you're going to get clamwin to work seamlessly through updates 
of clamwin is to get clamwin's installation to change.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Brian Dessent]

Jim Kleckner wrote:

> This is helpful, thank you.  Being curious and trying to be minimal
> about changes
> to the system in question, I tried removing and linking the dll in
> place.  I first tried
> "ln -s /bin/cygwin1.dll" in the clamwin/bin directory and wasn't
> surprised that it
> didn't work.  Being Unix person by background, I then tried "ln
> /bin/cygwin1.dll"
> and that surprised me by working.  I expected to see an NTFS cygwin1.dll.lnk
> file in there but using "cmd.exe" and "dir" or the windows explorer
> looks like a
> full copy of the dll file.  An "ls -l" tantalizingly shows a link count
> of 2.  "info ln"
> doesn't give any cygwin-specific info.  The section of the user guide
> located here:
>   http://cygwin.com/cygwin-ug-net/using-effectively.html#id2950938
> has some wording that implies this might work but isin't definitive.
> 
> My question now is, can "ln" be used to work around this issue or is
> that a "bad idea"?

A symlink won't work, because it's Windows own loader that searches for
and loads any .DLLs called for by an .exe.  Windows does not understand
symlinks as they are a Cygwin thing, so you can't symlink a DLL and
expect it to load.

NTFS does not support symbolic links but it does support hard links, see
.
 
If the volume is NTFS, 'ln' will use this capability.  On 9x or FAT it
will make a copy (I think.)

You shouldn't need to do either though, as long as your original
cygwin1.dll from the Cygwin installation is in the path.  Windows will
search for DLLs in: the directory of the .exe, the system directory, the
wondows directory, the current directory, and directories in the PATH,
in that order.  See

for details.  So all you need to do is put \cygwin\bin in your path.

Care is taken by the maintainers to make sure the Cygwin DLL is
backwards-compatible, so the current cygwin1.dll should always be able
to replace any weird older Cygwin DLL that some installer uses (but not
the Bxx series.)  However the reverse is not true, you cannot use a
binary that was compiled against a recent cygwin1.dll with an older copy
of the DLL.  So in other words, all you have to do is ensure that you
only have one cygwin1.dll on your system and in the path, and that it's
the current version.  Remove any other copies.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Thu, Mar 24, 2005 at 06:13:55PM -0800, Jim Kleckner wrote:
>My question now is, can "ln" be used to work around this issue or is 
>that a "bad idea"?

It's a bad idea.  Just delete the spurious DLL.  No special action is
required if the cygwin dll is in the PATH.

>PS.  Since cgf is steadfast, perhaps this explanation could be added to
>the FAQ entry located here that partially explains why multiple dlls is
>a problem: http://cygwin.com/faq/faq_3.html#SEC50

No.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Jim Kleckner wrote:
This is helpful, thank you.  Being curious and trying to be minimal 
about changes to the system in question, I tried removing and linking
the dll in place.  I first tried "ln -s /bin/cygwin1.dll" in the
clamwin/bin directory and wasn't surprised that it didn't work.
Being Unix person by background, I then tried "ln /bin/cygwin1.dll"
And yes, I did reboot after removing to be sure caches were clear.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

Larry Hall wrote:
At 01:50 PM 3/24/2005, you wrote:
 

I had a user install clamwin and as discussed on the list here:
http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00288.html
it blithely installs cygwin1.dll regardless of any installation
of cygwin.  This predictably causes problems.
Searching through the user guide and faq doesn't yield
a suggestion for solutions or workarounds and searching
the list archives yields so much material that it is
hard to focus in on what specifically to do.  Obviously,
I can have the person uninstall clamwin.  Is there anything
else that makes sense (and, no, uninstalling cygwin doesn't
make sense)?  
   


The "standard" solution in these cases is to remove the cygwin1.dll 
from the offending 3rd party package after installing and make sure 
that the 3rd party package can find the already existing cygwin1.dll
in the Cygwin installation (C:\cygwin\bin by default).  The easiest 
way to do this is to put the Cygwin installation path/bin in your
Windows path.  As Chris points out, this could all be automated with 
some minor effort on the part of the 3rd party providers but in the
absence of such support, you have to do it manually. :-(  A better 
question might be to ask the clamwin folks why they can't augment
their installer to accommodate an existing Cygwin installation.  If
their package breaks a Cygwin installation, it's really not a Cygwin
problem per-se.
 

This is helpful, thank you.  Being curious and trying to be minimal 
about changes
to the system in question, I tried removing and linking the dll in 
place.  I first tried
"ln -s /bin/cygwin1.dll" in the clamwin/bin directory and wasn't 
surprised that it
didn't work.  Being Unix person by background, I then tried "ln 
/bin/cygwin1.dll"
and that surprised me by working.  I expected to see an NTFS cygwin1.dll.lnk
file in there but using "cmd.exe" and "dir" or the windows explorer 
looks like a
full copy of the dll file.  An "ls -l" tantalizingly shows a link count 
of 2.  "info ln"
doesn't give any cygwin-specific info.  The section of the user guide 
located here:
 http://cygwin.com/cygwin-ug-net/using-effectively.html#id2950938
has some wording that implies this might work but isin't definitive. 

My question now is, can "ln" be used to work around this issue or is 
that a "bad idea"?

Thanks again - Jim
PS.  Since cgf is steadfast, perhaps this explanation could be added to 
the FAQ
entry located here that partially explains why multiple dlls is a problem:
 http://cygwin.com/faq/faq_3.html#SEC50

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Larry Hall]

At 01:50 PM 3/24/2005, you wrote:
>I had a user install clamwin and as discussed on the list here:
> http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00288.html
>it blithely installs cygwin1.dll regardless of any installation
>of cygwin.  This predictably causes problems.
>
>Searching through the user guide and faq doesn't yield
>a suggestion for solutions or workarounds and searching
>the list archives yields so much material that it is
>hard to focus in on what specifically to do.  Obviously,
>I can have the person uninstall clamwin.  Is there anything
>else that makes sense (and, no, uninstalling cygwin doesn't
>make sense)?  


The "standard" solution in these cases is to remove the cygwin1.dll 
from the offending 3rd party package after installing and make sure 
that the 3rd party package can find the already existing cygwin1.dll
in the Cygwin installation (C:\cygwin\bin by default).  The easiest 
way to do this is to put the Cygwin installation path/bin in your
Windows path.  As Chris points out, this could all be automated with 
some minor effort on the part of the 3rd party providers but in the
absence of such support, you have to do it manually. :-(  A better 
question might be to ask the clamwin folks why they can't augment
their installer to accommodate an existing Cygwin installation.  If
their package breaks a Cygwin installation, it's really not a Cygwin
problem per-se.




--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clamwin installs incompatible copy of cygwin1.dll

[Christopher Faylor]

On Thu, Mar 24, 2005 at 10:50:07AM -0800, Jim Kleckner wrote:
>I had a user install clamwin and as discussed on the list here:
>http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00288.html it blithely
>installs cygwin1.dll regardless of any installation of cygwin.  This
>predictably causes problems.
>
>Searching through the user guide and faq doesn't yield a suggestion for
>solutions or workarounds and searching the list archives yields so much
>material that it is hard to focus in on what specifically to do.
>Obviously, I can have the person uninstall clamwin.  Is there anything
>else that makes sense (and, no, uninstalling cygwin doesn't make
>sense)?  This would be a good candidate for the FAQ, I think.

Sorry.  I will steadfastedly refuse to document as a "FAQ" problems with
broken software that installs their own version of the cygwin dll.  This
is nothing more than the standard multiple version of cygwin problem
aggravated by software providers who are too lazy to figure out how to
install their product without messing up a cygwin installation.

Regardless of that, however, I don't believe that this qualifies as a
"FAQ" since it hasn't been a frequently asked question.
--
Christopher Faylor  spammer? -> [EMAIL PROTECTED]
Cygwin Co-Project Leader[EMAIL PROTECTED]
TimeSys, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

clamwin installs incompatible copy of cygwin1.dll

[Jim Kleckner]

I had a user install clamwin and as discussed on the list here:
 http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00288.html
it blithely installs cygwin1.dll regardless of any installation
of cygwin.  This predictably causes problems.
Searching through the user guide and faq doesn't yield
a suggestion for solutions or workarounds and searching
the list archives yields so much material that it is
hard to focus in on what specifically to do.  Obviously,
I can have the person uninstall clamwin.  Is there anything
else that makes sense (and, no, uninstalling cygwin doesn't
make sense)?  This would be a good candidate for the FAQ,
I think.
Many thanks - Jim
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/