Re: 1.5.19-4: global constructors not working with dlopen()

[vita]

I tried your example duplicating your error. I played with it and change it
little bit to get it to work. Instead of using printf() in your T1_dl.c I used
cout and compiled it with g++ instead of gcc. Could it be you mixed C++ streams
used in your T1 class with old C printf-family what brings your application in
knee? I won't be surprised, I read somewhere that this two concepts should not
be mixed.

PV


> I'm having trouble with global constructors/destructors not
> executing/crashing within a dlopened DLL.
>
> I've attached a test-case.
> FYI: This works fine with 1.5.13-1.
>
> Thanks for your help.
> Martin
>
> ps:
> Here's my shell log.
>
> [EMAIL PROTECTED] make clean
> /bin/rm -f T1_dl *.exe *.dll *.so *~ mapfile
> [EMAIL PROTECTED] make; ./T1_dl
> g++ -Wall -Wl,-Map,mapfile -shared T1.cpp T1_inst.cpp -o T1_inst.dll
> gcc -Wall T1_dl.c -o T1_dl
> opening...
> [EMAIL PROTECTED] make nocygwin; ./T1_dl
> g++ -Wall -mno-cygwin -shared T1.cpp T1_inst.cpp -o T1_inst.dll
> gcc -Wall T1_dl.c -o T1_dl
> opening...
> T1 object created.
> opened successfully
> closing...
> T1 object deleted.
> closed
> [EMAIL PROTECTED] make t1inst; ./T1_inst
> g++ -Wall -DT1_INST_EXE T1.cpp T1_inst.cpp -o T1_inst
> T1 object created.
> running
> exiting...
> T1 object deleted.
> [EMAIL PROTECTED]



Sent through the University of Leoben webmail system


--
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/

Select()

[Vinod Chowdappa]

Hi,

Could somebody tell me how is select() resolved to cygwin_select() eventually?

I believe cygwin_select() is the core select() implementation, but to
the user it is the POSIX API select() that is exported.

I see these lines,

_select = cygwin_select SIGFE
select = cygwin_select SIGFE

in cygwin.din. Not sure what this file is and how is it used exactly?

Would appreciate if these doubts can be clarified.

--
Br,
Vinod

--
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: password-authenticated ssh session..;whoami shows OurSrvr064\sshd_server

[Corinna Vinschen]

On Feb  1 15:54, Tom Rodman wrote:
> The problem shows up only if your account is *not* added to this
> local group.  This local group should have just 1 entry - the
> local administrators group, as in:
> 
>   $ net localgroup toss_at_will
>   Alias name toss_at_will
>   Commenttest group
> 
>   Members
> 
>   
> ---
>   Administrators
>   The command completed successfully.
> 
> Then try sshing in as a user in the 'Administrators' group, using 
> password authentication.  My hope is that you will see the problem.

Finally I could reproduce it.  Apparently I never read your postings
close enough to do the right thing.  D'oh!  Sorry about that.

Following happens:

Ssh calls initgroups(3).  Cygwin's initgroups(3) creates a group list for
later usage in new user tokens by scanning /etc/passwd and /etc/groups,
as well as adding the global and local Win32 groups the user is
"officially" member of.  When looking for local groups, it adds all
local groups for which either the user itself, or another group for
which the user is member of, is member of.  I hope that's roughly clear.

The problem is that so-called "Alias SIDs" can also be members of local
groups, even though that's not officially documented in MSDN.  The GUI
refuses to add Alias SIDs to local groups, while the CLI (net
localgroup) allows it.  Alias SIDs are, for instance "Administrators",
or "Users".  That's somewhat weird and hard to explain.  I'm not sure I
ever understood the idea behind this scheme.

OK, so far, Cygwin just scanned all members of a local group and added
the group to the user's grouplist, if one of the group members was
itself a group which already showed up in the user's group list.  The
problem here is that official logon tokens created by LogonUser don't do
this indirection in case of Alias SIDs.  This additional check is
missing in Cygwin so far, so that the group list contains more
supposedly "official" group members than a group list in a really
official token created by LogonUser.

So, later, when setuid(2) is called, Cygwin checks the validity of the
token created by the password login.  It finds that this password token
is missing a group which formerly has been added to the user's group
list in the initgroups(3) call.  Consequentially the password token is
treated as invalid, and a new token containing the supposedly correct
number of groups is created.  This token is then used for the user
context switch and the password logon is accidentally converted into a
password-less logon, with all the consequences of a password-less logon.

I have checked in a patch to Cygwin which adds the missing test.  Local
groups are now added to the user's group list only, if either the user
is direct member of the group, or if the user is member of a domain
group or well-known SID which is member of the group.

Er... well... all clearness dispelled?  Windows NT security is somewhat
hard to digest, isn't it?

Please give the next snapshot from http://cygwin.com/snapshots/ a try.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Select()

[Corinna Vinschen]

On Feb  2 16:50, Vinod Chowdappa wrote:
> Hi,
> 
> Could somebody tell me how is select() resolved to cygwin_select() eventually?
> 
> I believe cygwin_select() is the core select() implementation, but to
> the user it is the POSIX API select() that is exported.
> 
> I see these lines,
> 
> _select = cygwin_select SIGFE
> select = cygwin_select SIGFE
> 
> in cygwin.din. Not sure what this file is and how is it used exactly?

See the Makefile.  cygwin.din is converted to cygwin.def, a standard
export definition file for the linker.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Exec and parent environment

[Steve Smith]

I have a similar problem to that reported before under this subject  
title.
When I type "env" the environment appears fine. However, when I start  
a tclsh and type


puts [ exec sh -c "env" ]

the environment is almost empty - this is new behaviour, the whole  
environment got fully passed through until recently.


Any ideas?  Thanks.

 
--

Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre

FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726  (fax 222717)

[EMAIL PROTECTED]  http://www.fmrib.ox.ac.uk/~steve
 
--





--
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: Select()

[Vinod Chowdappa]

Hi

On 2/2/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
> > I see these lines,
> >
> > _select = cygwin_select SIGFE
> > select = cygwin_select SIGFE
> >
> > in cygwin.din. Not sure what this file is and how is it used exactly?
>
> See the Makefile.  cygwin.din is converted to cygwin.def, a standard
> export definition file for the linker.
>

Could you briefly explain the format of the .din file? What does SIGFE mean?
Does "select = cygwin_select SIGFE" mean select is a weak alias to
cygwin_select?
And cygwin_select is itself not exported?

TIA
Vinod

--
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: Select()

[Corinna Vinschen]

On Feb  2 18:55, Vinod Chowdappa wrote:
> On 2/2/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
> > > in cygwin.din. Not sure what this file is and how is it used exactly?
> >
> > See the Makefile.  cygwin.din is converted to cygwin.def, a standard
> > export definition file for the linker.
> 
> Could you briefly explain the format of the .din file? What does SIGFE mean?

Basically same format as .def files.  For SIGFE see how-signals-work.txt
in the source dir.

> And cygwin_select is itself not exported?

No, what would that be good for?  The function has another name internally
so that it can be easily distinguished from the WinSock function select.
See net.cc for more examples.  That's the only reason for using another
name.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Select()

[Brian Dessent]

Vinod Chowdappa wrote:

> Could you briefly explain the format of the .din file? What does SIGFE mean?
> Does "select = cygwin_select SIGFE" mean select is a weak alias to
> cygwin_select?
> And cygwin_select is itself not exported?

You need to read the file "how-signals-work.txt" which explains that. 
It's not a weak alias, it's a direct mapping, they are the same
function.

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: Exec and parent environment [attn tcltk maintainer]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Steve Smith on 2/2/2006 5:17 AM:
> 
> I have a similar problem to that reported before under this subject  title.
> When I type "env" the environment appears fine. However, when I start  a
> tclsh and type
> 
> puts [ exec sh -c "env" ]
> 
> the environment is almost empty - this is new behaviour, the whole 
> environment got fully passed through until recently.

Sounds like YA case of
http://sourceware.org/ml/cygwin/2006-01/msg00938.html.  tclsh is one of
the few programs in /bin that does not link against cygwin1.dll, but uses
Windows directly.  So it probably needs to be taught how to interact with
cygwin's updated environment scheme.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4g3p84KuGfSFAYARApooAJ9XylwbSFXiXK1DcBMPPCYrC13QzACcCcKG
aLzCUba8aKW1Vq6iRg/U9Mw=
=z877
-END PGP SIGNATURE-

--
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: Exec and parent environment [attn tcltk maintainer]

[Steve Smith]

Thanks for the feedback. So does this mean that it is the tcl that is  
bundled with Cygwin that is broken?


Is there an easy workaround?

Cheers.


On 2 Feb 2006, at 13:49, Eric Blake wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Steve Smith on 2/2/2006 5:17 AM:


I have a similar problem to that reported before under this  
subject  title.
When I type "env" the environment appears fine. However, when I  
start  a

tclsh and type

puts [ exec sh -c "env" ]

the environment is almost empty - this is new behaviour, the whole
environment got fully passed through until recently.


Sounds like YA case of
http://sourceware.org/ml/cygwin/2006-01/msg00938.html.  tclsh is  
one of
the few programs in /bin that does not link against cygwin1.dll,  
but uses
Windows directly.  So it probably needs to be taught how to  
interact with

cygwin's updated environment scheme.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4g3p84KuGfSFAYARApooAJ9XylwbSFXiXK1DcBMPPCYrC13QzACcCcKG
aLzCUba8aKW1Vq6iRg/U9Mw=
=z877
-END PGP SIGNATURE-



 
--

Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre

FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726  (fax 222717)

[EMAIL PROTECTED]  http://www.fmrib.ox.ac.uk/~steve
 
--





--
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: Exec and parent environment [attn tcltk maintainer]

[Eric Blake]

Ugh - top-posting reformatted.  http://cygwin.com/acronyms/#TOFU

> >> When I type "env" the environment appears fine. However, when I  
> >> start  a
> >> tclsh and type
> >>
> >> puts [ exec sh -c "env" ]
> >>
> >> the environment is almost empty - this is new behaviour, the whole
> >> environment got fully passed through until recently.
> >
> > Sounds like YA case of
> > http://sourceware.org/ml/cygwin/2006-01/msg00938.html.  tclsh is  
> > one of
> > the few programs in /bin that does not link against cygwin1.dll,  
> > but uses
> > Windows directly.  So it probably needs to be taught how to  
> > interact with
> > cygwin's updated environment scheme.

> Thanks for the feedback. So does this mean that it is the tcl that is  
> bundled with Cygwin that is broken?

Actually, on further thought, it might be something that cygwin
needs to fix.  Do you mount /bin as cygexec?  (Hint - attaching
the output of cygcheck -svr as a text attachment would have
answered this question).  Prior to cygwin 1.5.19, it was suggested
that mounting /bin as cygexec would speed up operations of
cygwin programs, since the bulk of the files in /bin are linked
against cygwin1.dll.  In 1.5.19, however, cgf improved cygwin
to automatically detect wheter an application is linked against
cygwin or is a native windows program, and in the process
made it so that only native windows programs are handed
a native windows environment.  But if cygexec mounting is
turned on, then a native windows program in that mount
point will be mistakenly treated as a cygwin program, such
that cygwin tries to use only the cygwin method for passing
the environment to the child program.  My guess is that
you are calling tclsh from a cygwin shell (bash?), and that
cygwin is assuming the child (tclsh) can understand cygwin's
environment because it lives in /bin, even though it is a
windows native executable and needs the windows environment.
>From there, when you do the exec in tclsh, the grandchild
sh sees the same environment that tclsh saw.

> 
> Is there an easy workaround?

If my hypothesis was correct, then remount /bin to no
longer be cygexec (cygexec mount points no longer make
sense, now that cygwin can autodetect programs linked
against cygwin).  Or wait and see if a future snapshot
of cygwin learns to recognize native windows apps that
live in a cygexec mountpoint.

Or, if you are ambitious, figure out a way to package
two versions of tcltk in cygwin; the native tcltk is a
requirement (cgf wants the insight debugger to work
no matter what), but a cygwin-aware tcltk would
also be nice.  The issue has come up before, search
the mailing list archives.  Until someone comes up
with a good solution, tclsh will remain one of the few
windows-native programs distributed in /bin.

--
Eric Blake

--
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: Exec and parent environment [attn tcltk maintainer]

[Steve Smith]

When I type "env" the environment appears fine. However, when I
start  a
tclsh and type

puts [ exec sh -c "env" ]

the environment is almost empty - this is new behaviour, the whole
environment got fully passed through until recently.


Sounds like YA case of
http://sourceware.org/ml/cygwin/2006-01/msg00938.html.  tclsh is
one of
the few programs in /bin that does not link against cygwin1.dll,
but uses
Windows directly.  So it probably needs to be taught how to
interact with
cygwin's updated environment scheme.



Thanks for the feedback. So does this mean that it is the tcl that is
bundled with Cygwin that is broken?


Actually, on further thought, it might be something that cygwin
needs to fix.  Do you mount /bin as cygexec?  (Hint - attaching
the output of cygcheck -svr as a text attachment would have
answered this question).  Prior to cygwin 1.5.19, it was suggested
that mounting /bin as cygexec would speed up operations of
cygwin programs, since the bulk of the files in /bin are linked
against cygwin1.dll.  In 1.5.19, however, cgf improved cygwin
to automatically detect wheter an application is linked against
cygwin or is a native windows program, and in the process
made it so that only native windows programs are handed
a native windows environment.  But if cygexec mounting is
turned on, then a native windows program in that mount
point will be mistakenly treated as a cygwin program, such
that cygwin tries to use only the cygwin method for passing
the environment to the child program.  My guess is that
you are calling tclsh from a cygwin shell (bash?), and that
cygwin is assuming the child (tclsh) can understand cygwin's
environment because it lives in /bin, even though it is a
windows native executable and needs the windows environment.
From there, when you do the exec in tclsh, the grandchild
sh sees the same environment that tclsh saw.



Is there an easy workaround?


If my hypothesis was correct, then remount /bin to no
longer be cygexec (cygexec mount points no longer make
sense, now that cygwin can autodetect programs linked
against cygwin).  Or wait and see if a future snapshot
of cygwin learns to recognize native windows apps that
live in a cygexec mountpoint.

Or, if you are ambitious, figure out a way to package
two versions of tcltk in cygwin; the native tcltk is a
requirement (cgf wants the insight debugger to work
no matter what), but a cygwin-aware tcltk would
also be nice.  The issue has come up before, search
the mailing list archives.  Until someone comes up
with a good solution, tclsh will remain one of the few
windows-native programs distributed in /bin.

--
Eric Blake


Thanks very much for the detailed reply. Sadly, it seems like this  
isn't quite the solution yet - my mounts are the defaults that you  
get when you install cygwin:


$ mount
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
C:\cygwin on / type system (binmode)
c: on /cygdrive/c type system (binmode,noumount)

and hence I'm guessing that cygexec is already not being used. Any  
other possibilities?


Thanks very much, Steve.


 
--

Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre

FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726  (fax 222717)

[EMAIL PROTECTED]  http://www.fmrib.ox.ac.uk/~steve
 
--





--
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: Exec and parent environment [attn tcltk maintainer]

[Igor Peshansky]

On Thu, 2 Feb 2006, Eric Blake wrote:

> Ugh - top-posting reformatted.  http://cygwin.com/acronyms/#TOFU

Good point -- I should start including the link to that acronym too... :-)

> > >> When I type "env" the environment appears fine. However, when I
> > >> start  a
> > >> tclsh and type
> > >>
> > >> puts [ exec sh -c "env" ]
> > >>
> > >> the environment is almost empty - this is new behaviour, the whole
> > >> environment got fully passed through until recently.
> > >
> > > Sounds like YA case of
> > > http://sourceware.org/ml/cygwin/2006-01/msg00938.html.  tclsh is one
> > > of the few programs in /bin that does not link against cygwin1.dll,
> > > but uses Windows directly.  So it probably needs to be taught how to
> > > interact with cygwin's updated environment scheme.
>
> > Thanks for the feedback. So does this mean that it is the tcl that is
> > bundled with Cygwin that is broken?
>
> Actually, on further thought, it might be something that cygwin needs to
> fix.  Do you mount /bin as cygexec?  (Hint - attaching the output of
> cygcheck -svr as a text attachment would have answered this question).
> Prior to cygwin 1.5.19, it was suggested that mounting /bin as cygexec
> would speed up operations of cygwin programs, since the bulk of the
> files in /bin are linked against cygwin1.dll.  In 1.5.19, however, cgf
> improved cygwin to automatically detect wheter an application is linked
> against cygwin or is a native windows program, and in the process made
> it so that only native windows programs are handed a native windows
> environment.

I've been thinking along the same lines.  Actually, as of Cygwin 1.5.19,
any program that links to Cygwin1.dll will behave as if it's on a cygexec
mount...  I wonder if there needs to be a symmetric option to mount to
indicate a non-Cygwin executable...

> But if cygexec mounting is turned on, then a native windows program in
> that mount point will be mistakenly treated as a cygwin program, such
> that cygwin tries to use only the cygwin method for passing the
> environment to the child program.  My guess is that you are calling
> tclsh from a cygwin shell (bash?), and that cygwin is assuming the child
> (tclsh) can understand cygwin's environment because it lives in /bin,
> even though it is a windows native executable and needs the windows
> environment.

Well, tclsh is a *Cygwin* executable that uses native Windows calls
(CreateProcess) under the covers (in tcl84.dll).  I'm not sure if it would
even help to be able to mount it as a "non-cygwin executable"...  CGF?

> From there, when you do the exec in tclsh, the grandchild sh sees the
> same environment that tclsh saw.
>
> > Is there an easy workaround?
>
> If my hypothesis was correct, then remount /bin to no longer be cygexec
> (cygexec mount points no longer make sense, now that cygwin can
> autodetect programs linked against cygwin).  Or wait and see if a future
> snapshot of cygwin learns to recognize native windows apps that live in
> a cygexec mountpoint.

Since Cygwin automatically detects Cygwin programs, removing the cygexec
bit won't help.  I guess there isn't an easy workaround at the moment,
short of patching tclsh appropriately and building your own.  That might
not be as hard as it sounds, and I'm sure the maintainer will appreciate a
ready and tested patch.

> Or, if you are ambitious, figure out a way to package two versions of
> tcltk in cygwin; the native tcltk is a requirement (cgf wants the
> insight debugger to work no matter what), but a cygwin-aware tcltk would
> also be nice.  The issue has come up before, search the mailing list
> archives.  Until someone comes up with a good solution, tclsh will
> remain one of the few windows-native programs distributed in /bin.

:-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Exec and parent environment [attn tcltk maintainer]

[Eric Blake]

> > But if cygexec mounting is turned on, then a native windows program in
> > that mount point will be mistakenly treated as a cygwin program, such
> > that cygwin tries to use only the cygwin method for passing the
> > environment to the child program.  My guess is that you are calling
> > tclsh from a cygwin shell (bash?), and that cygwin is assuming the child
> > (tclsh) can understand cygwin's environment because it lives in /bin,
> > even though it is a windows native executable and needs the windows
> > environment.
> 
> Well, tclsh is a *Cygwin* executable that uses native Windows calls
> (CreateProcess) under the covers (in tcl84.dll).  I'm not sure if it would
> even help to be able to mount it as a "non-cygwin executable"...  CGF?

Really?

$ cygcheck tclsh
Found: C:\cygwin\bin\tclsh.exe
C:/cygwin/bin/tclsh.exe
$

My understanding of the cygexec magic was that if it was
determined that an .exe had a startup dependency on
cygwin1.dll, but tclsh has NO dll dependencies at startup
(any dlls are pulled in with dynamic loads during execution),
so how would cygwin1.dll be able to think that tclsh is
a cygwin executable?

--
Eric Blake

--
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: Exec and parent environment [attn tcltk maintainer]

[Christopher Faylor]

On Thu, Feb 02, 2006 at 02:32:08PM +, Steve Smith wrote:
>Thanks for the feedback. So does this mean that it is the tcl that is  
>bundled with Cygwin that is broken?

Yes.

>Is there an easy workaround?

PTC?

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: Exec and parent environment [attn tcltk maintainer]

[Igor Peshansky]

On Thu, 2 Feb 2006, Eric Blake wrote:

> > > But if cygexec mounting is turned on, then a native windows program
> > > in that mount point will be mistakenly treated as a cygwin program,
> > > such that cygwin tries to use only the cygwin method for passing the
> > > environment to the child program.  My guess is that you are calling
> > > tclsh from a cygwin shell (bash?), and that cygwin is assuming the
> > > child (tclsh) can understand cygwin's environment because it lives
> > > in /bin, even though it is a windows native executable and needs the
> > > windows environment.
> >
> > Well, tclsh is a *Cygwin* executable that uses native Windows calls
> > (CreateProcess) under the covers (in tcl84.dll).  I'm not sure if it
> > would even help to be able to mount it as a "non-cygwin executable"...
> > CGF?
>
> Really?
>
> $ cygcheck tclsh
> Found: C:\cygwin\bin\tclsh.exe
> C:/cygwin/bin/tclsh.exe
> $
>
> My understanding of the cygexec magic was that if it was determined that
> an .exe had a startup dependency on cygwin1.dll, but tclsh has NO dll
> dependencies at startup (any dlls are pulled in with dynamic loads
> during execution), so how would cygwin1.dll be able to think that tclsh
> is a cygwin executable?

Because tclsh.exe is a symlink to tclsh84.exe, which has

$ ls -l /bin/tclsh.exe
lrwxrwxrwx  1 Administrators SYSTEM 11 Jul 30  2004 /bin/tclsh.exe -> 
tclsh84.exe*
$ cygcheck tclsh84
Found: C:\cygwin\bin\tclsh84.exe
C:/cygwin/bin/tclsh84.exe
  C:\WINDOWS\System32\KERNEL32.dll
C:\WINDOWS\System32\ntdll.dll
  C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\System32\ADVAPI32.DLL
  C:\WINDOWS\System32\RPCRT4.dll
  C:\cygwin\bin\tcl84.dll
C:\WINDOWS\System32\USER32.dll
  C:\WINDOWS\System32\GDI32.dll

I made the same mistake initially... :-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Exec and parent environment [attn tcltk maintainer]

[Christopher Faylor]

On Thu, Feb 02, 2006 at 05:04:42PM +, Eric Blake wrote:
>$ cygcheck tclsh
>Found: C:\cygwin\bin\tclsh.exe
>C:/cygwin/bin/tclsh.exe
>$

  bash$ ls -l /bin/tclsh*
  lrwxrwxrwx 1 cgf None11 Mar 15  2005 /bin/tclsh.exe -> tclsh84.exe
  -rwxrwxrwx 1 cgf None 16384 Sep  1  2003 /bin/tclsh84.exe
  bash$ cygcheck /bin/tclsh84.exe
  d:/cygwin/bin/tclsh84.exe
L:\WINXP\system32\KERNEL32.dll
  L:\WINXP\system32\ntdll.dll
d:/cygwin/bin\cygwin1.dll
  L:\WINXP\system32\ADVAPI32.DLL
L:\WINXP\system32\RPCRT4.dll
d:/cygwin/bin\tcl84.dll
  L:\WINXP\system32\USER32.dll
L:\WINXP\system32\GDI32.dll

I will look into fixing this.

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: Exec and parent environment [attn tcltk maintainer]

[Igor Peshansky]

On Thu, 2 Feb 2006, Christopher Faylor wrote:

> On Thu, Feb 02, 2006 at 05:04:42PM +, Eric Blake wrote:
> >$ cygcheck tclsh
> >Found: C:\cygwin\bin\tclsh.exe
> >C:/cygwin/bin/tclsh.exe
> >$
>
>   bash$ ls -l /bin/tclsh*
>   lrwxrwxrwx 1 cgf None11 Mar 15  2005 /bin/tclsh.exe -> tclsh84.exe
>   -rwxrwxrwx 1 cgf None 16384 Sep  1  2003 /bin/tclsh84.exe
>   bash$ cygcheck /bin/tclsh84.exe
>   d:/cygwin/bin/tclsh84.exe
> L:\WINXP\system32\KERNEL32.dll
>   L:\WINXP\system32\ntdll.dll
> d:/cygwin/bin\cygwin1.dll
>   L:\WINXP\system32\ADVAPI32.DLL
>   L:\WINXP\system32\RPCRT4.dll
> d:/cygwin/bin\tcl84.dll
>   L:\WINXP\system32\USER32.dll
>   L:\WINXP\system32\GDI32.dll
>
> I will look into fixing this.
>
> cgf

Whatever fix is made, it would be great if cygcheck output the path of
symlinks it had to chase to get the executable.  Also, outputting "Not an
executable" for scripts and such would help.

BTW:
$ cygcheck vi
Error: could not find vi
$ ls -l /usr/bin/vi
lrwxrwxrwx  1 igor Users 7 Dec 20 18:21 /usr/bin/vi -> vim.exe
$ cygcheck awk
Found: C:\cygwin\bin\awk.exe
C:/cygwin/bin/awk.exe
$ ls -l /usr/bin/awk.exe
lrwxrwxrwx  1 igor Users 8 Nov 17 18:25 /usr/bin/awk.exe -> gawk.exe

Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Exec and parent environment [attn tcltk maintainer]

[Christopher Faylor]

On Thu, Feb 02, 2006 at 12:27:53PM -0500, Igor Peshansky wrote:
>On Thu, 2 Feb 2006, Christopher Faylor wrote:
>
>> On Thu, Feb 02, 2006 at 05:04:42PM +, Eric Blake wrote:
>> >$ cygcheck tclsh
>> >Found: C:\cygwin\bin\tclsh.exe
>> >C:/cygwin/bin/tclsh.exe
>> >$
>>
>>   bash$ ls -l /bin/tclsh*
>>   lrwxrwxrwx 1 cgf None11 Mar 15  2005 /bin/tclsh.exe -> tclsh84.exe
>>   -rwxrwxrwx 1 cgf None 16384 Sep  1  2003 /bin/tclsh84.exe
>>   bash$ cygcheck /bin/tclsh84.exe
>>   d:/cygwin/bin/tclsh84.exe
>> L:\WINXP\system32\KERNEL32.dll
>>   L:\WINXP\system32\ntdll.dll
>> d:/cygwin/bin\cygwin1.dll
>>   L:\WINXP\system32\ADVAPI32.DLL
>>  L:\WINXP\system32\RPCRT4.dll
>> d:/cygwin/bin\tcl84.dll
>>   L:\WINXP\system32\USER32.dll
>>  L:\WINXP\system32\GDI32.dll
>>
>> I will look into fixing this.
>
>Whatever fix is made, it would be great if cygcheck output the path of
>symlinks it had to chase to get the executable.  Also, outputting "Not an
>executable" for scripts and such would help.

I will not look into fixing this.

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: Exec and parent environment [attn tcltk maintainer]

[Igor Peshansky]

On Thu, 2 Feb 2006, Christopher Faylor wrote:

> On Thu, Feb 02, 2006 at 12:27:53PM -0500, Igor Peshansky wrote:
> >On Thu, 2 Feb 2006, Christopher Faylor wrote:
> >
> >> On Thu, Feb 02, 2006 at 05:04:42PM +, Eric Blake wrote:
> >> >$ cygcheck tclsh
> >> >Found: C:\cygwin\bin\tclsh.exe
> >> >C:/cygwin/bin/tclsh.exe
> >> >$
> >>
> >>   bash$ ls -l /bin/tclsh*
> >>   lrwxrwxrwx 1 cgf None11 Mar 15  2005 /bin/tclsh.exe -> tclsh84.exe
> >>   -rwxrwxrwx 1 cgf None 16384 Sep  1  2003 /bin/tclsh84.exe
> >>   bash$ cygcheck /bin/tclsh84.exe
> >>   d:/cygwin/bin/tclsh84.exe
> >> L:\WINXP\system32\KERNEL32.dll
> >>   L:\WINXP\system32\ntdll.dll
> >> d:/cygwin/bin\cygwin1.dll
> >>   L:\WINXP\system32\ADVAPI32.DLL
> >>L:\WINXP\system32\RPCRT4.dll
> >> d:/cygwin/bin\tcl84.dll
> >>   L:\WINXP\system32\USER32.dll
> >>L:\WINXP\system32\GDI32.dll
> >>
> >> I will look into fixing this.
> >
> >Whatever fix is made, it would be great if cygcheck output the path of
> >symlinks it had to chase to get the executable.  Also, outputting "Not an
> >executable" for scripts and such would help.
>
> I will not look into fixing this.

I will look into fixing this.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Exec and parent environment [attn tcltk maintainer]

[Dave Korn]

On 02 February 2006 17:28, Igor Peshansky wrote:


> 
> Whatever fix is made, it would be great if cygcheck output the path of
> symlinks it had to chase to get the executable.  


  There wouldn't be much point doing that without making cygcheck /actually/ 
chase symlinks first...!   ;-)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Exec and parent environment [attn tcltk maintainer]

[Eric Blake]

> 
> Because tclsh.exe is a symlink to tclsh84.exe, which has
> 
> $ ls -l /bin/tclsh.exe
> lrwxrwxrwx  1 Administrators SYSTEM 11 Jul 30  2004 /bin/tclsh.exe -> 
> tclsh84.exe*

Hmm - we should teach cygcheck to dereference symlinks.


--
Eric Blake

--
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: Exec and parent environment [attn tcltk maintainer]

[Dave Korn]

On 02 February 2006 17:53, Eric Blake wrote:

>> Because tclsh.exe is a symlink to tclsh84.exe, which has
>> 
>> $ ls -l /bin/tclsh.exe
>> lrwxrwxrwx  1 Administrators SYSTEM 11 Jul 30  2004 /bin/tclsh.exe ->
>> tclsh84.exe*
> 
> Hmm - we should teach cygcheck to dereference symlinks.


  Or at least to notice if the file it opens is not an exe at all!

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: [ANNOUNCEMENT] Updated: OpenSSH-4.3p1-1

[David Rothenberger]

I get the following error when trying to compile openssh-4.3p1-1
using cygwin 1.5.19-4.

scp.c: In function `rsource':
scp.c:698: error: structure has no member named `d_ino'

The error comes from this code:

while ((dp = readdir(dirp)) != NULL) {
if (dp->d_ino == 0)
continue;
if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, ".."))
continue;
...
}

I "solved" the problem with the attached patch, which detects the
missing d_ino in configure and removes the test and continue if
d_ino isn't present.

Is this the appropriate thing to do?

Also, Corinna, how did you make the binaries for openssh-4.3p1-1?

-- 
David Rothenbergerspammer? -> [EMAIL PROTECTED]
GPG/PGP: 0x92D68FD8, DB7C 5146 1AB0 483A 9D27 DFBA FBB9 E328 92D6 8FD8

But Captain -- the engines can't take this much longer!
--- openssh-4.3p1-1/config.h.in 2006-02-01 03:33:49.0 -0800
+++ openssh-4.3p1-2/config.h.in 2006-02-01 20:41:16.134875000 -0800
@@ -77,6 +77,9 @@
 /* Define if you want to specify the path to your wtmp file */
 #undef CONF_WTMP_FILE
 
+/* Define if your struct dirent doesn't contain d_ino */
+#undef DIRENT_MISSING_D_INO
+
 /* Define if your platform needs to skip post auth file descriptor passing */
 #undef DISABLE_FD_PASSING
 
--- openssh-4.3p1-1/configure   2006-02-01 03:33:51.0 -0800
+++ openssh-4.3p1-2/configure   2006-02-01 20:41:11.634875000 -0800
@@ -10346,6 +10346,63 @@
 rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext 
conftest.$ac_ext
 fi
 
+echo "$as_me:$LINENO: checking whether struct dirent contains d_ino" >&5
+echo $ECHO_N "checking whether struct dirent contains d_ino... $ECHO_C" >&6
+if test "$cross_compiling" = yes; then
+
+   { echo "$as_me:$LINENO: WARNING: cross compiling: assuming 
DIRENT_MISSING_D_INO" >&5
+echo "$as_me: WARNING: cross compiling: assuming DIRENT_MISSING_D_INO" >&2;}
+   cat >>confdefs.h <<\_ACEOF
+#define DIRENT_MISSING_D_INO 1
+_ACEOF
+
+
+
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+#include 
+#include 
+int main(void){struct dirent d;exit(sizeof(d.d_ino)>=0);}
+
+_ACEOF
+rm -f conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+else
+  echo "$as_me: program exited with status $ac_status" >&5
+echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+( exit $ac_status )
+
+   echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+
+cat >>confdefs.h <<\_ACEOF
+#define DIRENT_MISSING_D_INO 1
+_ACEOF
+
+
+fi
+rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext 
conftest.$ac_ext
+fi
+
 echo "$as_me:$LINENO: checking for /proc/pid/fd directory" >&5
 echo $ECHO_N "checking for /proc/pid/fd directory... $ECHO_C" >&6
 if test -d "/proc/$$/fd" ; then
@@ -26883,9 +26940,10 @@
   # 1. Remove the extension, and $U if already installed.
   ac_i=`echo "$ac_i" |
 sed 's/\$U\././;s/\.o$//;s/\.obj$//'`
-  # 2. Add them.
-  ac_libobjs="$ac_libobjs $ac_i\$U.$ac_objext"
-  ac_ltlibobjs="$ac_ltlibobjs $ac_i"'$U.lo'
+  # 2. Prepend LIBOBJDIR.  When used with automake>=1.10 LIBOBJDIR
+  #will be set to the directory where LIBOBJS objects are built.
+  ac_libobjs="$ac_libobjs \${LIBOBJDIR}$ac_i\$U.$ac_objext"
+  ac_ltlibobjs="$ac_ltlibobjs \${LIBOBJDIR}$ac_i"'$U.lo'
 done
 LIBOBJS=$ac_libobjs
 
@@ -27157,9 +27215,9 @@
 exec 5>>config.log
 {
   echo
-  sed 'h;s/./-/g;s/^.../## /;s/...$/ ##/;p;x;p;x' <&5
 cat >&5 <<_CSEOF
 
--- openssh-4.3p1-1/configure.ac2006-01-29 05:22:39.0 -0800
+++ openssh-4.3p1-2/configure.ac2006-02-01 20:38:45.978625000 -0800
@@ -950,6 +950,25 @@
]
 )
 
+AC_MSG_CHECKING([whether struct dirent contains d_ino])
+AC_RUN_IFELSE(
+   [AC_LANG_SOURCE([[
+#include 
+#include 
+int main(void){struct dirent d;exit(sizeof(d.d_ino)>=0);}
+   ]])],
+   [AC_MSG_RESULT(yes)],
+   [
+   AC_MSG_RESULT(no)
+   AC_DEFINE(DIRENT_MISSING_D_INO, 1,
+   [Define if your struct dirent doesn't contain d_ino])
+   ],
+   [
+   AC_MSG_WARN([cross compiling: assuming DIRENT_MISSING_D_INO])
+   AC_DEFINE(DIRENT_MISSING_D_INO)
+   ]
+)
+
 AC_MSG_CHECKING([for /proc/pid/fd directory])
 if test -d "/proc/$$/fd" ; then
AC_DEFINE(HAVE_PROC_PID, 1, [Define if you have /proc/$pid/fd])
--- openssh-4.3p1-1/scp.c   2006-01-31 03:11:38.0 -0800
+++ openssh-4.3p1-2/scp.c   2006-02-01 20

Re: [ANNOUNCEMENT] Updated: OpenSSH-4.3p1-1

[Corinna Vinschen]

On Feb  2 10:41, David Rothenberger wrote:
> I get the following error when trying to compile openssh-4.3p1-1
> using cygwin 1.5.19-4.
> 
> scp.c: In function `rsource':
> scp.c:698: error: structure has no member named `d_ino'
> 
> The error comes from this code:
> 
> while ((dp = readdir(dirp)) != NULL) {
> if (dp->d_ino == 0)
> continue;
> if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, ".."))
> continue;
> ...
> }
> 
> I "solved" the problem with the attached patch, which detects the
> missing d_ino in configure and removes the test and continue if
> d_ino isn't present.
> 
> Is this the appropriate thing to do?

The appropriate thing to do would be to use the binaries from the
distro.  Also, the absence of d_ino in 1.5.19 is temporary.  The
snapshots and the upcoming 1.5.20 release will bring it back.

> Also, Corinna, how did you make the binaries for openssh-4.3p1-1?

See /usr/share/doc/Cygwin/openssh.README.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/

mismatched dll

[Bob Rossi]

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 incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

Last time I had this problem, I actually had to modify the executable I
was running to fix it, by pointing to the correct dll.
  http://sourceware.org/ml/cygwin/2005-03/msg00700.html

However, I think this is different. I've used nx from
(http://nomachine.com/) for a while now. After I upgraded Cygwin
recently to get readline-5.1, this program stopped working. The error is
above.

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 None   0 Feb  2 14:20 ..
-rwx--+ 1 bar None 1723392 Dec 13 10:50 NXWin.exe
-rwx--+ 1 bar None 1152000 Dec 13 10:50 cygXcomp.dll
-rwx--+ 1 bar None 1067008 Dec  9 10:34 cygcrypto-0.9.8.dll
-rwx--+ 1 bar None  134656 Dec  9 10:34 cygjpeg-62.dll
-rwx--+ 1 bar None   20992 Dec  9 10:34 cygminires.dll
-rwx--+ 1 bar None  235520 Dec  9 10:34 cygpng12.dll
-rwx--+ 1 bar None  105472 Dec 13 10:50 cygserver.exe
-rwx--+ 1 bar None 1295582 Dec  9 10:34 cygwin1.dll
-rwx--+ 1 bar None   61440 Dec  9 10:34 cygz.dll
-rwx--+ 1 bar None   26112 Dec 13 10:50 nxauth.exe
-rwx--+ 1 bar None   50176 Dec 13 10:50 nxesd.exe
-rwx--+ 1 bar None   27136 Dec 13 10:50 nxkill.exe
-rwx--+ 1 bar None   28672 Sep 13 19:14 nxsetup.exe
-rwx--+ 1 bar None  253952 Dec 13 10:50 nxssh.exe

I would appreciate any help. Just for my information, isn't it OK to put
the cygwin1.dll in the same directory as the program you are running? Is
this the approved way of releasing cygwin with an application?

Thanks,
Bob Rossi

Cygwin Configuration Diagnostics
Current System Time: Thu Feb 02 14:29:46 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   c:\Lint
C:\cygwin\home\bar\bin
C:\cygwin\home\bar\bin\fun
C:\cygwin\usr\packages\distcc-2.18.3\bin
C:\cygwin\home\bar\bin
C:\cygwin\home\Qt\tmake-1.4\bin
C:\cygwin\home\Qt\qt-2.3.0\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
c:\Perl\bin
c:\GNAT\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\InstallShield\InstallShield 5.5 Professional 
Edition\Program

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1003(bar)  GID: 513(None)
0(root) 513(None)   544(Administrators) 545(Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1003(bar)  GID: 513(None)
0(root) 513(None)   544(Administrators) 545(Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'bar'
PWD = '/home/bar'
HOME = '/home/bar'
MAKE_MODE = 'unix'

HOMEPATH = '\Documents and Settings\bar.BAR-NT'
MANPATH = ':/usr/ssl/man:/usr/X11R6/man'
APPDATA = 'C:\Documents and Settings\bar.BAR-NT\Application Data'
GNATMAKE = 'gnatmake -j5'
HOSTNAME = 'bar-nt'
VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
VCAST_ASSERTIONS = 'true'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel'
WINDIR = 'C:\WINDOWS'
VCAST_VRESULT_SHOW_ERRORS = 'true'
LATEST = '/home/LATEST'
CVSROOT = ':pserver:[EMAIL PROTECTED]:/home/CVS/cvsroot'
PUBLIC = '/home/PUBLIC'
OLDPWD = '/cygdrive/c/Program Files/NX Client for Windows/bin'
USERDOMAIN = 'BAR-NT'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINDOWS'
USERS = '/home/USERS'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/BAR~1.BAR/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\'
USERNAME = 'bar'
PROCESSOR_LEVEL = '15'
BASELINE = '/home/BASELINE'
VCAST_SPLASH_TIMEOUT = '0'
BUILD = '/home/BUILD'
GHS_LMHOST = '@ultra'
FP_NO_HOST_CHECK = 'NO'
BASH_PROFILE_CONFIG_DIR = '/home/USERS/bar/cvs/bob/config/bash'
SYSTEMDRIVE = 'C:'
EDITOR = 'vim'
BASH_PROFILE_NETWORK_NAME = 'vector'
VECTORCAST_DIR = 'c:\vcast\baseline'
USERPROFILE = 'C:\Documents and Settings\bar.BAR-NT'
CLIENTNAME = 'Console'
PS1 = '[EMAIL PROTECTED] \w] $ '
LOGONSERVER = '\\BAR-NT'
LM_LICENSE_FILE = '[EMAIL PROTECTED]'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL

[ANNOUNCEMENT] New Package: glitz-0.4.4-2

[Yaakov S (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The following packages have been added to the Cygwin net release:

*** glitz-0.4.4-2
*** libglitz-glx1-0.4.4-2
*** libglitz1-0.4.4-2

Glitz is an OpenGL image compositing library. Glitz provides
Porter/Duff compositing of images and implicit mask generation for
geometric primitives including trapezoids, triangles, and rectangles.

Glitz is an optional backend for cairo, and is part of the cairographics
project.


Yaakov

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD4l3spiWmPGlmQSMRAumnAKDkjHXXeNHVRtJT+4PKHu45arVwnQCgvRpP
dthAnk0Wx6ml3NNdZAU7Ldc=
=z9iv
-END PGP SIGNATURE-

--
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: mismatched dll

[Yaakov S (Cygwin Ports)]

-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 None   0 Feb  2 14:20 ..
> -rwx--+ 1 bar None 1723392 Dec 13 10:50 NXWin.exe
> -rwx--+ 1 bar None 1152000 Dec 13 10:50 cygXcomp.dll
> -rwx--+ 1 bar None 1067008 Dec  9 10:34 cygcrypto-0.9.8.dll
> -rwx--+ 1 bar None  134656 Dec  9 10:34 cygjpeg-62.dll
> -rwx--+ 1 bar None   20992 Dec  9 10:34 cygminires.dll
> -rwx--+ 1 bar None  235520 Dec  9 10:34 cygpng12.dll
> -rwx--+ 1 bar None  105472 Dec 13 10:50 cygserver.exe
> -rwx--+ 1 bar None 1295582 Dec  9 10:34 cygwin1.dll
**^^^
> -rwx--+ 1 bar None   61440 Dec  9 10:34 cygz.dll
> -rwx--+ 1 bar None   26112 Dec 13 10:50 nxauth.exe
> -rwx--+ 1 bar None   50176 Dec 13 10:50 nxesd.exe
> -rwx--+ 1 bar None   27136 Dec 13 10:50 nxkill.exe
> -rwx--+ 1 bar None   28672 Sep 13 19:14 nxsetup.exe
> -rwx--+ 1 bar None  253952 Dec 13 10:50 nxssh.exe
> 
> I would appreciate any help. Just for my information, isn't it OK to put
> the cygwin1.dll in the same directory as the program you are running?

No.  There must be only ONE cygwin1.dll on your entire system.  It
should be in your cygwin /bin directory.  Period.

> Is this the approved way of releasing cygwin with an application?

AFAIK there is no approved way of releasing cygwin together with
*anything*, as it is bound to lead to such problems.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD4mtvpiWmPGlmQSMRAtNwAJ4ytZjJmi7wPopQo1tejJ3ArKMMegCgtAQD
DqQLSd0AezfsUv3ZnnaV09s=
=pHHs
-END PGP SIGNATURE-

--
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: mismatched dll

[Bob Rossi]

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 Feb  2 14:18 .
> > drwx--+ 5 bar None   0 Feb  2 14:20 ..
> > -rwx--+ 1 bar None 1723392 Dec 13 10:50 NXWin.exe
> > -rwx--+ 1 bar None 1152000 Dec 13 10:50 cygXcomp.dll
> > -rwx--+ 1 bar None 1067008 Dec  9 10:34 cygcrypto-0.9.8.dll
> > -rwx--+ 1 bar None  134656 Dec  9 10:34 cygjpeg-62.dll
> > -rwx--+ 1 bar None   20992 Dec  9 10:34 cygminires.dll
> > -rwx--+ 1 bar None  235520 Dec  9 10:34 cygpng12.dll
> > -rwx--+ 1 bar None  105472 Dec 13 10:50 cygserver.exe
> > -rwx--+ 1 bar None 1295582 Dec  9 10:34 cygwin1.dll
> **^^^
> > -rwx--+ 1 bar None   61440 Dec  9 10:34 cygz.dll
> > -rwx--+ 1 bar None   26112 Dec 13 10:50 nxauth.exe
> > -rwx--+ 1 bar None   50176 Dec 13 10:50 nxesd.exe
> > -rwx--+ 1 bar None   27136 Dec 13 10:50 nxkill.exe
> > -rwx--+ 1 bar None   28672 Sep 13 19:14 nxsetup.exe
> > -rwx--+ 1 bar None  253952 Dec 13 10:50 nxssh.exe
> > 
> > I would appreciate any help. Just for my information, isn't it OK to put
> > the cygwin1.dll in the same directory as the program you are running?
> 
> 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?

> > Is this the approved way of releasing cygwin with an application?
> 
> AFAIK there is no approved way of releasing cygwin together with
> *anything*, as it is bound to lead to such problems.

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
machine, and each has a slightly diffferent vresion of qt.dll. This
isn't a problem at all. What's limiting Cygwin?

BTW, this worked before I upgraded cygwin. So it is at least possible if
they are the same version?

Thanks,
Bob Rossi

--
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: mismatched dll

[Yaakov S (Cygwin Ports)]

-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
> machine, and each has a slightly diffferent vresion of qt.dll. This
> isn't a problem at all. What's limiting Cygwin?
>
> BTW, this worked before I upgraded cygwin. So it is at least possible if
> they are the same version?

http://cygwin.com/faq/faq-nochunks.html#faq.using.multiple-copies


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFD4m7ipiWmPGlmQSMRAr/1AJQKRZ998caA658zLVv4LSk/sG1LAJ9Ko6eh
u9VtbZmrNhhwmKBx6s9EhQ==
=gIOC
-END PGP SIGNATURE-

--
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: mismatched dll

[Eric Blake]

> > 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 two different
.dlls trying to share the same memory, but with different
ideas of what the semantics of that memory are, you invariably
have problems.  Cygwin prints out the error message you saw
rather than trying to be backwards compatible to all earlier
releases of the .dll in how this shared memory is used, because
it is just easier that way.

> 
> > > Is this the approved way of releasing cygwin with an application?
> > 
> > AFAIK there is no approved way of releasing cygwin together with
> > *anything*, as it is bound to lead to such problems.
> 
> Why would 1 cygwin.dll care about another on the system that has nothing
> to do with it?

Because it DOES have something to do with it.  See also
http://cygwin.com/acronyms/#3PP

> 
> I have N different versions of our product installed on my windows
> machine, and each has a slightly diffferent vresion of qt.dll. This
> isn't a problem at all. What's limiting Cygwin?

Windows .dll design.

> 
> BTW, this worked before I upgraded cygwin. So it is at least possible if
> they are the same version?

Possible?  Yes.  Wise?  No.  You are tempting fate - almost
as surely as you try this, you will forget to upgrade one of
the two copies, and be right back at this issue.  Hence the
official stance of this list is to only ever have a SINGLE
cygwin1.dll on your machine.

--
Eric Blake

--
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: mismatched dll

[Bob Rossi]

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 memory between processes,
> in order to emulate POSIX semantics.  If you have two different
> .dlls trying to share the same memory, but with different
> ideas of what the semantics of that memory are, you invariably
> have problems.  Cygwin prints out the error message you saw
> rather than trying to be backwards compatible to all earlier
> releases of the .dll in how this shared memory is used, because
> it is just easier that way.

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 called p_v2 depends on v2.dll. For every p_v1 or 
p_v2 you start, only a single version of the associated dll is opened.

The reason this design is nice is because you can have multiple versions
of the .dll installed, and they will be shared between executables
nicely.

On Cygwin, for some reason you assert this condition is not true. I
believe that what you are asserting is based in fact, and would really
like to understand why.

> > BTW, this worked before I upgraded cygwin. So it is at least possible if
> > they are the same version?
> 
> Possible?  Yes.  Wise?  No.  You are tempting fate - almost
> as surely as you try this, you will forget to upgrade one of
> the two copies, and be right back at this issue.  Hence the
> official stance of this list is to only ever have a SINGLE
> cygwin1.dll on your machine.

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?

Another reason I'm asking is, I was trying to think of how I could
package CGDB for people.

Thanks for the great help,
Bob Rossi

--
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: [ANNOUNCEMENT] Updated: OpenSSH-4.3p1-1

[David Rothenberger]

On 2/2/2006 10:52 AM, Corinna Vinschen wrote:

On Feb  2 10:41, David Rothenberger wrote:

Is this the appropriate thing to do?


The appropriate thing to do would be to use the binaries from the
distro.  


I can't. I need to apply a patch to OpenSSH to restore compatability 
with SSH2 from ssh.com .


> Also, the absence of d_ino in 1.5.19 is temporary.  The

snapshots and the upcoming 1.5.20 release will bring it back.


Yes, I'm aware of that, but as I use this in a production environment, I 
don't want to use a snapshot.


I'm don't completely understand the semantics of d_ino. I was just
hoping someone would confirm that it's reasonable to ignore that test
with 1.5.19-4.


Also, Corinna, how did you make the binaries for openssh-4.3p1-1?


Yes, I followed those instructions, which led to the error I mentioned. 
I was just curious what environment you used to get the compilation to 
succeed.


--
David Rothenbergerspammer? -> [EMAIL PROTECTED]
GPG/PGP: 0x92D68FD8, DB7C 5146 1AB0 483A 9D27 DFBA FBB9 E328 92D6 8FD8

Xerox your lunch and file it under "sex offenders"!


--
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: mismatched dll

[Eric Blake]

> 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 called p_v2 depends on v2.dll. For every p_v1 or 
> p_v2 you start, only a single version of the associated dll is opened.

The difference is not the .dll itself, but the shared memory region
that cygwin uses.  Every process linked against cygwin1.dll
opens a shared memory region, known by a fixed name/location, so
that information can be passed between cygwin processes
via this shared memory area.  And there are enough POSIX
semantics that require sharing info between cygwin processes
that it is QUITE difficult to try opening different shared
memory regions when different .dlls are used.

http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5&content-type=text/plain&cvsroot=src

http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?rev=1.1&content-type=text/plain&cvsroot=src


> 
> The reason this design is nice is because you can have multiple versions
> of the .dll installed, and they will be shared between executables
> nicely.

Yes, we know.  For example, /bin/cygreadline[4-6].dll all nicely
coexist, so that your application can choose which API level
of readline you want to use (4.x, 5.0 with 32-bit offset, or 5.x
with 64-bit offset).

> 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?

There's a difference here.  Cygwin does not maintain binary
compatibility of its use of its shared memory region between
versions.  But it DOES maintain binary compatibility of the API
it exposes.  Cygwin releases try very hard to guarantee that
something compiled against an older cygwin1.dll will continue
to run when a newer cygwin1.dll is put in its place.  The
underlying details may change (such as the shared memory
region), but the API continues to work.  And that is exactly
what shared libraries were invented for.

> 
> Another reason I'm asking is, I was trying to think of how I could
> package CGDB for people.

By far the easiest is to tell them to download cygwin themselves,
then you don't have to worry about it.  But yes, this is not
very user-friendly.  So you will have to come up with some
scheme where if cygwin is already on the machine, you make
sure it is new enough for your needs, and if it is not present,
you make sure the user is informed that you are installing a
cygwin1.dll and that if they ever want more cygwin features
they should replace/delete the one you installed.  Otherwise,
you risk becoming the dreaded http://cygwin.com/acronyms/#3PP.

Oh, and remember that cygwin1.dll is GPLd, so if you distribute
the dll yourself, you must also distribute the source code for
the version you are shipping, as well as make sure your
own project is open source per the cygwin license.

--
Eric Blake

--
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: mismatched dll

[Bob Rossi]

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 fault. A program called p_v1 depends on v1.dll.
> > Another program called p_v2 depends on v2.dll. For every p_v1 or 
> > p_v2 you start, only a single version of the associated dll is opened.
> 
> The difference is not the .dll itself, but the shared memory region
> that cygwin uses.  Every process linked against cygwin1.dll
> opens a shared memory region, known by a fixed name/location, so
> that information can be passed between cygwin processes
> via this shared memory area.  And there are enough POSIX
> semantics that require sharing info between cygwin processes
> that it is QUITE difficult to try opening different shared
> memory regions when different .dlls are used.
> 
> http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5&content-type=text/plain&cvsroot=src
> 
> http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/src/winsup/cygwin/how-cygtls-works.txt?rev=1.1&content-type=text/plain&cvsroot=src

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.

> > 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?
> 
> There's a difference here.  Cygwin does not maintain binary
> compatibility of its use of its shared memory region between
> versions.  But it DOES maintain binary compatibility of the API
> it exposes.  Cygwin releases try very hard to guarantee that
> something compiled against an older cygwin1.dll will continue
> to run when a newer cygwin1.dll is put in its place.  The
> underlying details may change (such as the shared memory
> region), but the API continues to work.  And that is exactly
> what shared libraries were invented for.

Yeah, that's nice. However, what happens when this changes? 

> > Another reason I'm asking is, I was trying to think of how I could
> > package CGDB for people.
> 
> By far the easiest is to tell them to download cygwin themselves,
> then you don't have to worry about it.  But yes, this is not
> very user-friendly.  So you will have to come up with some
> scheme where if cygwin is already on the machine, you make
> sure it is new enough for your needs, and if it is not present,
> you make sure the user is informed that you are installing a
> cygwin1.dll and that if they ever want more cygwin features
> they should replace/delete the one you installed.  Otherwise,
> you risk becoming the dreaded http://cygwin.com/acronyms/#3PP.
> 
> Oh, and remember that cygwin1.dll is GPLd, so if you distribute
> the dll yourself, you must also distribute the source code for
> the version you are shipping, as well as make sure your
> own project is open source per the cygwin license.

I love Cygwin, so the following is not an attack against it, just
critism that one day could hopefully be resolved. The way Cygwin
currently can be distributed (as described above) is not 'packager
friendly'. If the user does happen to install your package (which has
cygwin1.dll in it) and then they install cygwin, the currently installed
package will no longer work.  I don't see any way to prevent this from a
packaging perspective.

As far as the licensing, Yeah, that's not a problem in any way.

Thanks for your help,
Bob Rossi

--
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: mismatched dll

[Eric Blake]

> 
> 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 (pretty much anything in computer science is,
if you are willing to write the code and wait long enough).  The
difference is that shared memory is SO much faster than a
data-copying communication protocol that it isn't even funny.
Have you ever run cygwin on a Win9x machine, where the entire
shared region has to be copied into the correct location because
Windows didn't provide a convenient way to lock addresses, vs.
a WinNT machine, where the shared memory already lives in the
correct location?  The timing difference on every fork() or exec()
is staggering, and can't be blamed on processor speed alone.  And
yet even cygwin on WinNT is slower than native Linux, because
Windows doesn't provide the nice copy-on-write semantics of
memory pages shared between processes on a fork(), at least
not in a way easily used by cygwin.

> > versions.  But it DOES maintain binary compatibility of the API
> > it exposes.  Cygwin releases try very hard to guarantee that
> > something compiled against an older cygwin1.dll will continue
> > to run when a newer cygwin1.dll is put in its place.  The
> 
> Yeah, that's nice. However, what happens when this changes? 

People gripe on this list.  And it usually gets fixed pretty quickly,
although you may have to rely on snapshots for a while.  And
the snapshots exist to prevent this sort of mishap on general
releases, if people would test them.

> I love Cygwin, so the following is not an attack against it, just
> critism that one day could hopefully be resolved. The way Cygwin
> currently can be distributed (as described above) is not 'packager
> friendly'. If the user does happen to install your package (which has
> cygwin1.dll in it) and then they install cygwin, the currently installed
> package will no longer work.  I don't see any way to prevent this from a
> packaging perspective.

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 distribution
becomes cygwin.com's problem instead of yours.

--
Eric Blake

--
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: mismatched dll

[Christopher Faylor]

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 reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: OpenSSH-4.3p1-2

[Corinna Vinschen]

I've just updated the version of OpenSSH to 4.3p1-2.

The new 4.3p1 release of OpenSSH contained a configure bug which
prevented a correct evaluation of utmp header files.  In turn,
the utmp and wtmp entries created by sshd are bogus with sshd
from the openssh-4.3p1-1 package.

The new 4.3p1-2 package has been created with a patched configure
file and creates correct utmp and wtmp entries again.

And now, enjoy the official release message of 4.3p1 again:


OpenSSH 4.3 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

We have also recently completed another Internet SSH usage scan, the
results of which may be found at http://www.openssh.com/usage.html

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots and purchased
T-shirts or posters.

T-shirt, poster and CD sales directly support the project. Pictures
and more information can be found at:
http://www.openbsd.org/tshirts.html and
http://www.openbsd.org/orders.html

For international orders use http://https.openbsd.org/cgi-bin/order
and for European orders, use http://https.openbsd.org/cgi-bin/order.eu

Changes since OpenSSH 4.2:


Security bugs resolved in this release:

 * CVE-2006-0225: scp (as does rcp, on which it is based) invoked a
   subshell to perform local to local, and remote to remote copy
   operations. This subshell exposed filenames to shell expansion
   twice; allowing a local attacker to create filenames containing
   shell metacharacters that, if matched by a wildcard, could lead
   to execution of attacker-specified commands with the privilege of
   the user running scp (Bugzilla #1094)

This is primarily a bug-fix release, only one new feature has been
added:

 * Add support for tunneling arbitrary network packets over a
   connection between an OpenSSH client and server via tun(4) virtual
   network interfaces. This allows the use of OpenSSH (4.3+) to create
   a true VPN between the client and server providing real network
   connectivity at layer 2 or 3. This feature is experimental and is
   currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and
   FreeBSD. Other operating systems with tun/tap interface capability
   may be added in future portable OpenSSH releases. Please refer to
   the README.tun file in the source distribution for further details
   and usage examples.

Some of the other bugs resolved and internal improvements are:

 * Reduce default key length for new DSA keys generated by ssh-keygen
   back to 1024 bits. DSA is not specified for longer lengths and does
   not fully benefit from simply making keys longer. As per FIPS 186-2
   Change Notice 1, ssh-keygen will refuse to generate a new DSA key
   smaller or larger than 1024 bits

 * Fixed X forwarding failing to start when a the X11 client is executed
   in background at the time of session exit (Bugzilla #1086)

 * Change ssh-keygen to generate a protocol 2 RSA key when invoked
   without arguments (Bugzilla #1064)

 * Fix timing variance for valid vs. invalid accounts when attempting
   Kerberos authentication (Bugzilla #975)

 * Ensure that ssh always returns code 255 on internal error (Bugzilla
   #1137)

 * Cleanup wtmp files on SIGTERM when not using privsep (Bugzilla #1029)

 * Set SO_REUSEADDR on X11 listeners to avoid problems caused by
   lingering sockets from previous session (X11 applications can
   sometimes not connect to 127.0.0.1:60xx) (Bugzilla #1076)

 * Ensure that fds 0, 1 and 2 are always attached in all programs, by
   duping /dev/null to them if necessary.

 * Xauth list invocation had bogus "." argument (Bugzilla #1082)

 * Remove internal assumptions on key exchange hash algorithm and output
   length, preparing OpenSSH for KEX methods with alternate hashes.

 * Ignore junk sent by a server before  it sends the "SSH-" banner
   (Bugzilla #1067)

 * The manpages has been significantly improves and rearranged, in
   addition to other specific manpage fixes:
   #1037 - Man page entries for -L and -R should mention -g.
   #1077 - Descriptions for "ssh -D" and DynamicForward should mention
   they can specify "bind_address" optionally.
   #1088 - Incorrect descriptions in ssh_config man page for 
   ControlMaster=no.
   #1121 - Several corrections for ssh_agent manpages

 * Lots of cleanups, including fixes to memory leaks on error paths
   (Bugzilla #1109, #1110, # and more) and possible crashes (#1092)

 * Portable OpenSSH-specific fixes:

   - Pass random seed during re-exec for each connection: speeds up
 processing of new connections on platforms using the OpenSSH's
 builtin entropy co

Updated [experimental]: tcltk-20060202-1

[Christopher Faylor]

I've made a new version of tcltk available for downloading.  This
version is a refresh from sourceware.org.

This package contains an updated tclsh which will properly fill out the
environment when starting a subprocess -- when used in conjunction with
the latest cygwin snapshots.  Without the use of a cygwin snapshot DLL,
tclsh will behave as described here:

http://cygwin.com/ml/cygwin/2006-02/msg00055.html

Since improved behavior only happens with cygwin snapshots, means that
thist package must be labelled as experimental.  If no problems are
reported, this package will be marked as current when cygwin 1.5.20 is
released.  To download a cygwin DLL snapshot, check out the cygwin web
page for links to the snapshot page and, if necessary, check out the
cygwin FAQ for help installing a snapshot.

To update your tcltk installation, click on the "Install Cygwin now"
link on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Use setup.exe to update your installation.

If you have questions or comments, please send them to the Cygwin
mailing list.  See http://cygwin.com/lists.html for details.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#faq

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Christopher Faylor
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/

Re: mismatched dll

[Igor Peshansky]

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 "anything in computer science is [possible],
if you are willing to write the code and wait long enough"? :-)

Done.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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/

Possible bug with mmap on XP?

[Dave Bodenstab]

I searched the mailing list archives and googled, but failed to find
anything specific to XP regarding this...

I am using the latest version (1.5.19-4) of Cygwin.

I had previously ported a unix prog that used mmap to Cygwin.  On win2k
it works fine.  When I copied the prog to a newly-installed win XP
professional system, I get:

  mmap failed (Permission denied)

when attempting to do a 

  mmap(0,1500,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE,,0)

I've found that changing the permissions (chmod +x) on the file being
mmap'ed makes the problem go away.

Is this the way things are supposed to work on XP?

PS.  I have a test program that demonstrates this problem, but I wanted
to ask if this is a known problem before I start posting test programs.

PPS.  If this is a limitation for XP, is there a way for a Cygwin program
to tell if it's running on XP?

Thank you.

[
  My program generates x86 machine code and writes it to a file.
  The program then mmap's the file and executes the code.
  The problem is that I want the file prepended with '#!/bin/myprog\n"
  to be "executable", but I don't want a file with just the raw
  x86 code to be "executable" -- because it isn't without being
  run under control of my program that generated it.  This works
  entirely correctly on Linux, FreeBSD and Solaris.
]

--
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/

SSH Local Port Forwarding

[Jon Dixon]

The snapshot of 02-02-06 works well.  It has passed the relevant
hijack attack scenarios.

Thanks again

Jon

--
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: mismatched dll

[Bob Rossi]

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 just curious, I know this isn't going to happen.
> 
> Yes its possible (pretty much anything in computer science is,
> if you are willing to write the code and wait long enough).  The
> difference is that shared memory is SO much faster than a
> data-copying communication protocol that it isn't even funny.
> Have you ever run cygwin on a Win9x machine, where the entire
> shared region has to be copied into the correct location because
> Windows didn't provide a convenient way to lock addresses, vs.
> a WinNT machine, where the shared memory already lives in the
> correct location?  The timing difference on every fork() or exec()
> is staggering, and can't be blamed on processor speed alone.  And
> yet even cygwin on WinNT is slower than native Linux, because
> Windows doesn't provide the nice copy-on-write semantics of
> memory pages shared between processes on a fork(), at least
> not in a way easily used by cygwin.

OK, now I understand. It's currently the only practical way to
accomplish the task. 

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 environment. If
there is another version of the cygwin1.dll, and programs link against
it, they would be in another Cygwin environment, completely independent.

You know, I'm sure this has been thought of before, but if it hasn't ...

> > I love Cygwin, so the following is not an attack against it, just
> > critism that one day could hopefully be resolved. The way Cygwin
> > currently can be distributed (as described above) is not 'packager
> > friendly'. If the user does happen to install your package (which has
> > cygwin1.dll in it) and then they install cygwin, the currently installed
> > package will no longer work.  I don't see any way to prevent this from a
> > packaging perspective.
> 
> 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 distribution
> becomes cygwin.com's problem instead of yours.

OK, here I do have some evidence to support me when I say you are
partially wrong.  
http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00064.html
So, that is not a good alternative. 

Anyways, it's running circles around the point. I want to allow users to
run my program with out install Cygwin. In some situations, it's
possible installing Cygwin wouldn't even be allowed, where as simply
untaring a directory with an executable might be OK.

I've already installed 2 programs that I know of that use Cygwin. GNAT
and nx (nomachine.com). Both of these companies deliver the cygwn1.dll,
which totally borks my environment because I have Cygwin installed.
So I have the problem on both ends. I want to package my software to be
allowed in Cygwin (without borking others), and I know longer want to be
borked when I install other people's software that use Cygwin.

BTW, Cygwin is amazing, thanks for _all_ the great work. Hope I don't
come off ungrateful. I could literally quit programming if I had to work
on windows with out it. :)

Thanks,
Bob Rossi

--
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: mismatched dll

[Christopher Faylor]

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 distribution becomes cygwin.com's
>>problem instead of yours.
>
>OK, here I do have some evidence to support me when I say you are
>partially wrong.
>http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00064.html So, that is
>not a good alternative.

I retract my veto.  If this is submitted via normal channels, I will have
no objections.

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: mismatched dll

[Bob Rossi]

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 cygwin distribution.  Then you just point
> >>people to cygwin.com, and source code distribution becomes cygwin.com's
> >>problem instead of yours.
> >
> >OK, here I do have some evidence to support me when I say you are
> >partially wrong.
> >http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00064.html So, that is
> >not a good alternative.
> 
> 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 willing to write 
the code and wait long enough"?

Thanks,
Bob Rossi

--
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: mismatched dll

[Brian Dessent]

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 environment. If
> there is another version of the cygwin1.dll, and programs link against
> it, they would be in another Cygwin environment, completely independent.

It *is* possible to create two Cygwin DLLs that can co-exist.  But to do
so requires much more than just naming them differently.  The source
code must be modified to use a different filename/identifier for the
shared memory region, as well as different registry keys for the mount
table.  The Cygwin testsuite does a limited version of this to allow
running the just-built Cygwin DLL for the purposes of executing the
tests, from within the developer's existing Cygwin environment.

So yes, it can be done.  But it is a very bad idea to do so.  If you
made two DLLs that were isolated in this way they would be truly
isolated -- you could not send signals from one to the other, they would
not see each others processes in their PID tables, and so on.  It would
be the absolute worst way to have two sets of software interact.

This is ESPECIALLY true when the code goes to great lengths to be
backward compatible.  The idea is that you can ALWAYS replace an
existing cygwin1.dll with a newer one, without recompiling the old apps
that were linked against the old version of the DLL.  You of course
can't go in the other direction (using an older DLL with newer .exes)
but this backwards compatibility is in theory good all the way back to
version 1.0.0 from circa 1998-ish.  So there is no reason why you should
ever need two Cygwin DLLs in the first place, because you can always
replace an older one with a newer one.

If you are writing an installer of a third party application the basic
logic should thus be:

Is a cygwin1.dll already on the system somewhere?
  Yes:
 Is it newer than mine?
Yes: Install my .exe, but do not install my cygwin1.dll,
 use the existing one.
No:  Prompt user of the situation, and either bail or 
 overwrite older DLL with newer DLL.
  No:
 Install my DLL.

Essentially, you must ensure that if a Cygwin DLL already exists you
either use it as-is or replace it with a newer one.  Never install a
second copy, and never overwrite a newer one with an older verison.

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/

Driftnet for Windows

[Amruta]

Hello People,

I am new to Cygwin. I have a very basic question.
There is a tool Driftnet available only for Unix. I want to write 
it for I Windows making a few improvements as a part of my 
Master's thesis. I am confused here, can cygwin provide me some 
files like netinet/tcp.h etc. available in Linux (which are used 
for coding driftnet) in Windows? I want to write my code in 
Microsoft Visual Studio.net and I found out that winpcap library 
and winsock dll contain many files equivalent to the files 
available in Linux for network programming. But it doesn't provide 
anything for netinet/tcp.h and a few more may be.


I'm not even sure if I am in the right place. I mean can 
installing cygwin help me with this?


Please some body help me with this.


Thanks in advance,


Amruta Tilaye

Graduate Assistant
University of Nevada, Las Vegas,
USA.

--
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: mismatched dll

[Peter Rehley]

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 against the same cygwin1.dll are in one Cygwin  
environment. If
there is another version of the cygwin1.dll, and programs link  
against
it, they would be in another Cygwin environment, completely  
independent.







If you are writing an installer of a third party application the basic
logic should thus be:

Is a cygwin1.dll already on the system somewhere?
  Yes:
 Is it newer than mine?
Yes: Install my .exe, but do not install my cygwin1.dll,
 use the existing one.
No:  Prompt user of the situation, and either bail or
 overwrite older DLL with newer DLL.
  No:
 Install my DLL.

Essentially, you must ensure that if a Cygwin DLL already exists you
either use it as-is or replace it with a newer one.  Never install a
second copy, and never overwrite a newer one with an older verison.


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.


Peter


--
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/

GCC compiler

[djh]

My current version of gcc that setup.exe downloaded for me is:

gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

The other day I downloaded gcc 4.0.2
  filename:  gcc-4.0.2.tar.bz2

did a configure, make, and makeinstall

and the build was successfull.  I compiled a program with it and it 
seems to work.  


My question is, am I fooling myself?
Was there a lot of tweaking involved in getting the setup.exe downloaded 
version of gcc to work with cygwin?


Regards,
Darel

--
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: mismatched dll

[Brian Dessent]

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 says there will still be 3PPs that
don't follow its advice, and instead supply their own cygwin1.dll
regardless of the state of the machine.

>From the perspective of the software vendor that is selling a product
(or otherwise has some vested interest in having their software work)
there are a few problems with the procedure in my last post.

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 install its own copy.  Everyone is
happy.  But then say six months later the under removes Cygwin, unaware
the CBCP was relying on its DLL, and now CBCP fails to start or fails in
other strange ways.  From the standpoint of the user, he doesn't really
care what the underlying reason is, his CBCP now doesn't work and it's
obviously a CBCP bug.  You can repeat this scenario in several
permutations, say for example if there are two CBCPs installed on the
system, and one is using the DLL provided by the other. 
Upgrade/downgrade/remove one and the other breaks.

There's also the scary notion of an installer potentially messing with
files from a software package it does not "own."  In order for the "one
Cygwin DLL" plan to work in the face of 3PPs and CBCPs you have to be
prepared to accept that at some point you might have to delete or
overwrite the .dll shipped with the product, if it's older than what is
current or what you are shipping.  Here again your options are to either
play nice, and try to inform/educate the user that you're about to go
messing with some other software's files, potentially something
completely unrelated to yours, all because their DLL is too old but it
was there first.  Or you can just trudge ahead and be a quinessential
3PP and have no regard for what might have been installed already -- of
course you also don't have to shoulder the burden of possibly FUBARing
some existing software because you messed with its DLL.

And then on top of all this there is the "stability" argument, where you
have 3PPs that (for better or worse) only care about trying to support
their CBCP with a certain known version of the cygwin DLL.  If you have
other cygwin.dll-consumers on your system and try to "do the right
thing" by keeping the sole copy as the latest version, you risk losing
support from the stubborn 3PP that will not budge on the fact that
you're doing something they don't want to have any part of.

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
telling users to install Cygwin from the cygwin.com mirrors first and
then integrating with that.  But for some vendors that is too many steps
and not "turnkey" enough.

I think at the end of the day, user education as to the nature of the
problem is really what is required.

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: mismatched dll

[Christopher Faylor]

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 willing to
>write the code and wait long enough"?

Uh.  You're welcome?

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: mismatched dll

[Bob Rossi]

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, all programs
> > that link against the same cygwin1.dll are in one Cygwin environment. If
> > there is another version of the cygwin1.dll, and programs link against
> > it, they would be in another Cygwin environment, completely independent.
> 
> It *is* possible to create two Cygwin DLLs that can co-exist.  But to do
> so requires much more than just naming them differently.  The source
> code must be modified to use a different filename/identifier for the
> shared memory region, as well as different registry keys for the mount
> table.  The Cygwin testsuite does a limited version of this to allow
> running the just-built Cygwin DLL for the purposes of executing the
> tests, from within the developer's existing Cygwin environment.

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.

> So yes, it can be done.  But it is a very bad idea to do so.  If you
> made two DLLs that were isolated in this way they would be truly
> isolated -- you could not send signals from one to the other, they would
> not see each others processes in their PID tables, and so on.  It would
> be the absolute worst way to have two sets of software interact.

OK, we are looking at things from 2 different perspectives. I want to
make it so that they can not interact at all. That would be my goal. I
want to deliver a cygwin1.dll with a program, and ensure that it will
never ever interact with the users cygwin1.dll.

> This is ESPECIALLY true when the code goes to great lengths to be
> backward compatible.  The idea is that you can ALWAYS replace an
> existing cygwin1.dll with a newer one, without recompiling the old apps
> that were linked against the old version of the DLL.  You of course
> can't go in the other direction (using an older DLL with newer .exes)
> but this backwards compatibility is in theory good all the way back to
> version 1.0.0 from circa 1998-ish.  So there is no reason why you should
> ever need two Cygwin DLLs in the first place, because you can always
> replace an older one with a newer one.

There is at least 1 single reason. There is no possible way for a
developer to package a project and deliver it, and guarantee that it
will work. Either the user has cygwin installed (possibly catchable). Or
the user doesn't have Cygwin installed, installs your package, and then
later installs Cygwin (your package just got borked).

However, I see your point about backwards compatibity. That's wonderful.

> If you are writing an installer of a third party application the basic
> logic should thus be:
> 
> Is a cygwin1.dll already on the system somewhere?
>   Yes:
>  Is it newer than mine?
> Yes: Install my .exe, but do not install my cygwin1.dll,
>  use the existing one.
> No:  Prompt user of the situation, and either bail or 
>  overwrite older DLL with newer DLL.
>   No:
>  Install my DLL.

OK, see my comment above please. Also, what do I do about these jerks?
that package cygwin1.dll in there projects even though I have Cygwin
installed?

Brian, thanks for the input, it's very valuable. All in all, I can live
with your suggestions above, and will figure out a way to get done what
I need done. I'm just trying to suggest that there is a good reason to
possibly do the suggestion I have in the top paragraph. I think it would
help the community a lot.

People (not developers) downloading softare want to install an
executable throng some kind of package installer, and then run an
executable. They do not want to install Cygwin, and then start a
terminal, and then start a program. This is all just my opinion.

Thanks,
Bob Rossi

--
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: mismatched dll

[Bob Rossi]

> 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
> telling users to install Cygwin from the cygwin.com mirrors first and
> then integrating with that.  But for some vendors that is too many steps
> and not "turnkey" enough.
> 
> I think at the end of the day, user education as to the nature of the
> problem is really what is required.

Hi Brian,

This is very informative. I do have 1 point to make. Software get's
better and is easier to use, when the user doesn't have to become to
knowledgable about how to install or configure it.

IMHO, Cygwin needs a better way to allow distributers to distribute
software built on top of it. The windows world could see a lot more
smooth open source deliveries if this was possible.

Remember, it only takes 2 open source projects doing the correct thing
to potentially not work in your scenario. Unless both store the
cygwin1.dll in SYSTEM32, or some place where 1 can find the other,
there's going to be problems. Right?

Thanks,
Bob Rossi

--
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: GCC compiler

[Tim Prince]

djh wrote:


My current version of gcc that setup.exe downloaded for me is:

gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

The other day I downloaded gcc 4.0.2
  filename:  gcc-4.0.2.tar.bz2

did a configure, make, and makeinstall

and the build was successfull.  I compiled a program with it and it 
seems to work. 
My question is, am I fooling myself?
Was there a lot of tweaking involved in getting the setup.exe downloaded 
version of gcc to work with cygwin?
You could run make -k check and compare your results with those posted 
by others at gcc-testsuite.  This would show how well the standard 
tested functions of gcc itself are working.  If you don't care to use 
additional features of the cygming special, such as -mno-cygwin, you may 
be set up to do what matters to you.


--
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: mismatched dll

[Brian Dessent]

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 it should be possible for someone relatively familiar
with the cygwin build system to write in a few hours a patch that would
parameterize this, so that you could do something like

./configure --with-shared-id=foobar \
--with-mount-table-id=foobar --with-dllname=foobar

and end up with a "cygfoobar1.dll" that uses "foobar" in the shared
memory region name and registry mount keys.  Then (using the proper gcc
parameters) you could compile your package to use this cygfoobar1.dll
and have no dependence on cygwin1.dll, and be completely isolated from
any existing cygwin on a system.

Of course, nobody associated with Cygwin would then want anything to do
with trying to support such a frankensteined installation.  And it's not
clear to me that such a patch would even be accepted.  But it should be
relatively easy.

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/

gnome on cgywin

[qinglong]

Hi,
trying out cgywin and is trying to build gnome 2.12 on it.
anyone actually got GNOME running ??

will be cool if you can



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


--
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: gnome on cgywin

[Yaakov S (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
> trying out cgywin and is trying to build gnome 2.12 on it.
> anyone actually got GNOME running ??

If you mean the desktop, no, it doesn't work right now.  But if you just
want apps, I have plenty of them, just not in the distro yet.  I'm
trying to get GNOME into the distro as quickly as the ITP process allows.

Hint:  http://cygwinports.dotsrc.org/  But those packages are *NOT*
supported here, rather on their own lists, so questions should go there
(URLs on the website).

> will be cool if you can

No disagreements here. :-)


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD4s5KpiWmPGlmQSMRAkPVAJ9aUvOKnbcQgs01tRtRD7xoU2M/cgCg/pih
M3R4TNZiQwimhN05/eJ4sZ0=
=4z4w
-END PGP SIGNATURE-

--
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: Possible bug with mmap on XP?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dave Bodenstab on 2/2/2006 5:16 PM:
>   mmap(0,1500,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE,,0)
> 
> I've found that changing the permissions (chmod +x) on the file being
> mmap'ed makes the problem go away.
> 
> Is this the way things are supposed to work on XP?

Cygwin's behavior sounds reasonable to me - POSIX permits an
implementation to fail with EACCESS if the prot parameter requests writes
but filedes was not opened for writing, and permits failure with ENOTSUP
if a combination of prot flags is not supported.  But I see nothing in
POSIX that requires PROT_EXEC to either fail or succeed based on whether
filedes is tied to a file that has execute privileges, so you are treading
in unspecified waters.

> PS.  I have a test program that demonstrates this problem, but I wanted
> to ask if this is a known problem before I start posting test programs.

A test program would be very helpful.

> PPS.  If this is a limitation for XP, is there a way for a Cygwin program
> to tell if it's running on XP?

Yes, uname(2) can be used to give you an idea of what version of Windows
you are running on.

>   My program generates x86 machine code and writes it to a file.
>   The program then mmap's the file and executes the code.
>   The problem is that I want the file prepended with '#!/bin/myprog\n"
>   to be "executable", but I don't want a file with just the raw
>   x86 code to be "executable" -- because it isn't without being
>   run under control of my program that generated it.  This works
>   entirely correctly on Linux, FreeBSD and Solaris.

"works entirely correctly" is subjective, since there is no standards
document that requires it to either succeed or to fail.  However, since
cygwin strives to emulate Linux, I imagine Corinna will probably
investigate this further to see if it really is an inherent limitation of
XP.  And in the meantime, you have a workaround of marking files
executable that have executable bytes, even if they are not executable in
isolation.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4uB784KuGfSFAYARAnb1AJ4zzF35RJOCxrd1phaKMc3WPyl3ewCfePkw
Ga9x7IY1cFr8BL/KI3HPhQ0=
=qcdC
-END PGP SIGNATURE-

--
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: Driftnet for Windows

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Amruta on 2/2/2006 6:54 PM:
> Hello People,
> 
> I am new to Cygwin. I have a very basic question.
> There is a tool Driftnet available only for Unix. I want to write it for
> I Windows making a few improvements as a part of my Master's thesis. I
> am confused here, can cygwin provide me some files like netinet/tcp.h
> etc. available in Linux (which are used for coding driftnet) in Windows?

Yes, cygwin has .  In fact, if you have source code that
compiles under Linux, it is often the case that the same source code will
compile under cygwin with minimal tweaking.

> I'm not even sure if I am in the right place. I mean can installing
> cygwin help me with this?

Probably.  But the only way to know for sure is to try it.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD4uD084KuGfSFAYARAjXkAJ4xaQ2CWGs29+maXSNQm589wAJuSwCgyKIT
V76Me4kkhvIkro3FMSFRzbE=
=rnWV
-END PGP SIGNATURE-

--
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/

davfs for cygwin rsync?

[Siegfried Heintze]

I'm looking at the man page for rsync and I need a little help.

I just learned on the Boulder Linux UG mailing list that it is possible to
mount a Web DAV file system with davfs and use rsync with it on a linux
system. I assume this works with another utility too, like unison and
rbackup.

Hmmm... I cannot find rbackup in the man pages on cygwin. What about cygwin
rsync? Can that be used with davfs or something similar on cygwin?
Apparently not. According to the man page "Once installed, you can use rsync
to any machine that you can access via remote shell. For remote transfers,
rsync uses ssh for its communications."...

I was hoping to find a commercial service for which I could use cygwin/rsync
for daily backup. It is easy to find services for WebDAV -- but it is not
clear that cygwin rsync can use WebDAV like linux rsync can. Can someone
please clarify?

Are there commercial hosting services that provide ssh access? 

The man page as a section titled "STARTING AN RSYCN DAEMON TO ACCEPT
CONNECTIONS". I'm confused: I thought I needed an ssh deamon.

Thanks,
siegfried


--
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: Possible bug with mmap on XP?

[Dave Bodenstab]

Thanks for the reply.

On Thu, 02 Feb 2006 21:47:55 -0700 Eric Blake <[EMAIL PROTECTED]> wrote:

> According to Dave Bodenstab on 2/2/2006 5:16 PM:
> >   mmap(0,1500,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE,,0)
> > 
> > I've found that changing the permissions (chmod +x) on the file being
> > mmap'ed makes the problem go away.
> > 
> > Is this the way things are supposed to work on XP?
>
> Cygwin's behavior sounds reasonable to me - POSIX permits an
> implementation to fail with EACCESS if the prot parameter requests writes
> but filedes was not opened for writing, and permits failure with ENOTSUP
> if a combination of prot flags is not supported.  But I see nothing in
> POSIX that requires PROT_EXEC to either fail or succeed based on whether
> filedes is tied to a file that has execute privileges, so you are treading
> in unspecified waters.
>
> > PS.  I have a test program that demonstrates this problem, but I wanted
> > to ask if this is a known problem before I start posting test programs.
>
> A test program would be very helpful.

It can be found at http://www.bodenstab.org/files/mmaptest.c

> > PPS.  If this is a limitation for XP, is there a way for a Cygwin program
> > to tell if it's running on XP?
>
> Yes, uname(2) can be used to give you an idea of what version of Windows
> you are running on.

Is there a reference for what is returned for each windows release?  On my
only windows (I only have these for a couple of games and the digital cameras)
systems I get:

 Win98SE   sysname="CYGWIN_98-4.10"
 WinXP sysname="CYGWIN_NT-5.1"

I would have expected "XP" rather than "NT"... I thought I read somewhere
that NT is obsolete or at least unsupported now?  Does the 4.10 or 5.1
mean anything important?


--
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: Possible bug with mmap on XP?

[Christopher Faylor]

On Fri, Feb 03, 2006 at 12:36:42AM -0600, Dave Bodenstab wrote:
>Is there a reference for what is returned for each windows release?  On my
>only windows (I only have these for a couple of games and the digital cameras)
>systems I get:
>
> Win98SE   sysname="CYGWIN_98-4.10"
> WinXP sysname="CYGWIN_NT-5.1"
>
>I would have expected "XP" rather than "NT"... I thought I read somewhere
>that NT is obsolete or at least unsupported now?  Does the 4.10 or 5.1
>mean anything important?

Don't worry.  Cygwin automatically downgrades your Windows software to
the level that it requires for correct operation -- NT-5.1 in this case.

You're actually pretty lucky since, in many cases, Cygwin may end up
downgrading the OS all the way back to MS-DOS 6.0, and in certain rare
cases straight to CPM.  One person even reported that a Cygwin bug
caused OS "wrapping" and he found himself running FreeBSD, but I think
that might have just been a cockpit error.

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: Select()

[Jim Easton]

Hi,

Brian Dessent wrote:
> Vinod Chowdappa wrote:
> 
> > Could you briefly explain the format of the .din file? What does SIGFE mean?
> > Does "select = cygwin_select SIGFE" mean select is a weak alias to
> > cygwin_select?
> > And cygwin_select is itself not exported?
> 
> You need to read the file "how-signals-work.txt" which explains that. 
> It's not a weak alias, it's a direct mapping, they are the same
> function.
> 
> Brian

I hate to display my ignorance like this but where does one find
"how-signals-work.txt"?  Google didn't help me much.

Thank you in advance.

Jim Easton


--
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/