RE: Link errors related to vtable

[George]

Hi Dave,
I am sorry as I am new to c++ I need more help in
doing what you said is required.

thanks

--- Dave Korn <[EMAIL PROTECTED]> wrote:

> On 10 January 2007 13:04, Eric Blake wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > According to George on 1/9/2007 11:02 PM:
> >> Hi,
> >> I am getting link errors like below when I
> compile my
> >> code(systemc) which is  on cygwin 1.5.23 with gcc
> >> 3.4.4
> >> (systemc is a c++ class library)
> > 
> > No wonder.  C++ code MUST be compiled with g++,
> not gcc (unless you REALLY
> > know what you are doing).
> 
>   I guess George does, since...
> 
> On 10 January 2007 06:03, George wrote:
> 
> >
>
---
> > g++ -O3 -Wall -I. -I.. -I../../../include -L. -L..
> > -L../../../lib-linux -o run.x packet.o
> > packet_generator.o hub.o main.o -lsystemc -lm 
> 2>&1 |
> > c++filt
> >
>
main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fi
> fo::packet_fifo(sc_core::sc_module_name)]+0x91):
> > undefined reference to `VTT for packet_fifo'
> 
>   George, this will be hard for me to diagnose
> without an STC.  The first
> thing you should do is read "6.4 Vague Linkage" in
> the gcc manual which
> explains how and when gcc decides to emit the vtable
> for a class; then try
> running nm over the object files and seeing if it's
> there in the expected one
> or not.  Maybe there's a link-ordering problem or
> something.
> 
>   If you can produce an STC based only on snippets
> of main and packet_fifo I'd
> be able to figure it out in more detail.
> 
> 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/
> 
> 




 

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

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

struct passwd problem : running on XP

[DEMARCHE]

Here is the history ; Gcc compiled correctly my program with default options.
"gcc -c mqutils.c ".
I wanted to have my program independant of the Cygwin environment using -mno-
cygwin option. "gcc -mno-cygwin -c mqutils.c ". My aim was to deploy my program 
onto Windows Operating system wihtout cygwin installed.

Here is the result :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
gcc -mno-cygwin -g -I. -I"/cygdrive/c/Program Files/IBM/WebSphere 
MQ/Tools/c/include"  -c mqutils.c
In file included from mqutils.c:34:
/usr/include/pwd.h:53: error: parse error before "uid_t"
/usr/include/pwd.h:53: warning: no semicolon at end of struct or union
/usr/include/pwd.h:54: warning: data definition has no type or storage class
/usr/include/pwd.h:59: error: parse error before '}' token
/usr/include/pwd.h:62: warning: parameter names (without types) in function 
declaration
/usr/include/pwd.h:66: error: parse error before "struct"
mqutils.c: In function `PutMsg':
mqutils.c:106: error: dereferencing pointer to incomplete type
make: *** [mqutils.o] Error 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Here is my program :
line 100 if(strlen(userId) == 0) {
line 101 struct passwd *pwd;
line 102
line 103 memset(userId, 0, sizeof(userId));
line 104 pwd = getpwuid(getuid());
line 105 if(pwd)
line 106 strcpy(userId, pwd->pw_name);
line 107 }
line 108


I hope these information will help you.

Regards

Bruno D.

==


--
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: cygport-0.2.8-1

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The following package has been updated in the Cygwin net release:

*** cygport-0.2.8-1

cygport is a new, and increasingly popular, way to create Cygwin
packages.  You only need cygport if you're a package developer or
building cygport-based Cygwin packages from source.

New features in 0.2.8:
* wxwidgets: NEW cygclass for building wxWidgets-dependent packages.

Bug fixes in 0.2.8:
* Support autoconf-2.61.
* Fix application of .cygwin.patch file.
* gtk2-perl: Update Gnome2-Rsvg deps.  Fix DEPS_PATH.


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.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFrGnmpiWmPGlmQSMRCHjSAJ0Sa9uIpthmS4MAzGD0xZ+YeXkyLgCgsOXO
pZ9g1n+U0I5RXd4xizmgTF8=
=oNiK
-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: Link errors related to vtable

[George]

Or, since I am suspecting this might be a problem with
the gnu c++ compiler ver 3.4.4 which is there in the
cygwin 1.5.23 is there a way that I can download the
4.1 version of the c++ compiler which might solve the
problem?

thanks

--- George <[EMAIL PROTECTED]> wrote:

> Hi Dave,
> I am sorry as I am new to c++ I need more help in
> doing what you said is required.
> 
> thanks
> 
> --- Dave Korn <[EMAIL PROTECTED]> wrote:
> 
> > On 10 January 2007 13:04, Eric Blake wrote:
> > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > > 
> > > According to George on 1/9/2007 11:02 PM:
> > >> Hi,
> > >> I am getting link errors like below when I
> > compile my
> > >> code(systemc) which is  on cygwin 1.5.23 with
> gcc
> > >> 3.4.4
> > >> (systemc is a c++ class library)
> > > 
> > > No wonder.  C++ code MUST be compiled with g++,
> > not gcc (unless you REALLY
> > > know what you are doing).
> > 
> >   I guess George does, since...
> > 
> > On 10 January 2007 06:03, George wrote:
> > 
> > >
> >
>
---
> > > g++ -O3 -Wall -I. -I.. -I../../../include -L.
> -L..
> > > -L../../../lib-linux -o run.x packet.o
> > > packet_generator.o hub.o main.o -lsystemc -lm 
> > 2>&1 |
> > > c++filt
> > >
> >
>
main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fi
> > fo::packet_fifo(sc_core::sc_module_name)]+0x91):
> > > undefined reference to `VTT for packet_fifo'
> > 
> >   George, this will be hard for me to diagnose
> > without an STC.  The first
> > thing you should do is read "6.4 Vague Linkage" in
> > the gcc manual which
> > explains how and when gcc decides to emit the
> vtable
> > for a class; then try
> > running nm over the object files and seeing if
> it's
> > there in the expected one
> > or not.  Maybe there's a link-ordering problem or
> > something.
> > 
> >   If you can produce an STC based only on snippets
> > of main and packet_fifo I'd
> > be able to figure it out in more detail.
> > 
> > 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/
> > 
> > 
> 
> 
> 
> 
>  
>

> Need Mail bonding?
> Go to the Yahoo! Mail Q&A for great tips from Yahoo!
> Answers users.
>
http://answers.yahoo.com/dir/?link=list&sid=396546091
> 
> --
> 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/
> 
> 




 

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

--
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: struct passwd problem : running on XP

[Corinna Vinschen]

On Jan 16 08:53, DEMARCHE wrote:
> Here is the history ; Gcc compiled correctly my program with default options.
> "gcc -c mqutils.c ".
> I wanted to have my program independant of the Cygwin environment using -mno-
> cygwin option. "gcc -mno-cygwin -c mqutils.c ". My aim was to deploy my 
> program 
> onto Windows Operating system wihtout cygwin installed.
> 
> Here is the result :
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> gcc -mno-cygwin -g -I. -I"/cygdrive/c/Program Files/IBM/WebSphere 
> MQ/Tools/c/include"  -c mqutils.c
> In file included from mqutils.c:34:
> /usr/include/pwd.h:53: error: parse error before "uid_t"
> /usr/include/pwd.h:53: warning: no semicolon at end of struct or union
> /usr/include/pwd.h:54: warning: data definition has no type or storage class
> /usr/include/pwd.h:59: error: parse error before '}' token
> /usr/include/pwd.h:62: warning: parameter names (without types) in function 
> declaration
> /usr/include/pwd.h:66: error: parse error before "struct"
> mqutils.c: In function `PutMsg':
> mqutils.c:106: error: dereferencing pointer to incomplete type
> make: *** [mqutils.o] Error 1
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> 
> Here is my program :
> line 100 if(strlen(userId) == 0) {
> line 101 struct passwd *pwd;
> line 102
> line 103 memset(userId, 0, sizeof(userId));
> line 104 pwd = getpwuid(getuid());
> line 105 if(pwd)
> line 106 strcpy(userId, pwd->pw_name);
> line 107 }
> line 108
> 
> 
> I hope these information will help you.

Your header files seem to be broken.  The above error is generated
because it can't find the definition for uid_t which is available in
cygwin/types.h, which is included automatically by pwd.h through
including sys/type.h.  Somehow your header files are mixed up.
gcc -E might be helpful.  Do you have a fresh Cygwin install?


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: 1.5.23: ip_mreq_source not defined in cygwin/sockets.h

[Corinna Vinschen]

On Jan 16 12:24, Shishir Birmiwal wrote:
> Hi,
> 
> I recently tried building live55 streaming media (live555.com) on 
> cygwin-1.5.23.
> While building, it complained of the structure ip_mreq_source being not 
> defined.
> [...]
> I do see that both the entities are defined in w32api/ws2tcpip.h

Thanks for the report.  I will add the missing structures to Cygwin.
They will not be available any time soon, though.

> Would it make sense for cygwin/sockets.h to include w32api/ws2tcpip.h?
> I'm afraid that it might add to the kludge that is winsock/winsock2,
> and break some things :)

Don't do that.  Define the missing strcutures manually in your application
instead.

Also keep in mind that ip_mreq_source, ip_msfilter, in_pktinfo are only
available starting with Windows XP.  If you use them in your application,
it will not be backward compatible to NT4, W2K, or, FWIW, 95/98/Me.


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: Python 2.4 + PIL 1.1.6 compile error

[Vaidas]

This helped for me http://permalink.gmane.org/gmane.os.cygwin/85616




--
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: struct passwd problem : running on XP

[Dave Korn]

On 16 January 2007 10:29, Corinna Vinschen wrote:

> On Jan 16 08:53, DEMARCHE wrote:
>> I wanted to have my program independant of
>> the Cygwin environment using -mno- cygwin option. "gcc -mno-cygwin -c
>> mqutils.c ". My aim was to deploy my program onto Windows Operating system
>> wihtout cygwin installed. 

  Heh.  Then what on earth is it supposed to do when it tries to look up a
password and there's no such thing as /etc/passwd and no such library function
as getpwent?

>> Here is the result :
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> gcc -mno-cygwin -g -I. -I"/cygdrive/c/Program Files/IBM/WebSphere
>> MQ/Tools/c/include"  -c mqutils.c

  See, with -mno-cygwin, you really get what you're asking for:  NO cygwin!

>> In file included from mqutils.c:34:
>> /usr/include/pwd.h:53: error: parse error before "uid_t"
>> /usr/include/pwd.h:53: warning: no semicolon at end of struct or union
>> /usr/include/pwd.h:54: warning: data definition has no type or storage
>> class /usr/include/pwd.h:59: error: parse error before '}' token
>> /usr/include/pwd.h:62: warning: parameter names (without types) in
>> function declaration /usr/include/pwd.h:66: error: parse error before
>> "struct" 
>> mqutils.c: In function `PutMsg':
>> mqutils.c:106: error: dereferencing pointer to incomplete type
>> make: *** [mqutils.o] Error 1
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  So, no /etc/passwd, no getpwent, no struct passwd, no uids or gids, nothing
posix-y at all.  You have a logical problem in your design here: you want to
use cygwin features, yet you want to use them without cygwin

> Your header files seem to be broken

  Corinna, you missed the mno-cygwin flag I think?  I wouldn't expect to find
all these things in mingw headers.  There's that bug in the shared 'gcc'
driver that still allows cygwin's /usr/include in the default search path with
-mno-cygwin, which is why pwd.h is even found, but then all the necessary
types (uid_t, gid_t etc) in sys/types.h are different because the correct
(mingw) include/sys subdir is chosen.  


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: email and gmail

[Jeremy T. Harrison]

René Berber wrote:

>Jeremy T. Harrison wrote:
>> I am trying, fruitlessly, to get the email program to work with my 
gmail

>> account. I have ssmtp working fine (I did need to do some patching and
>> recompile ssmtp). The email program, on the other hand, is just
>> slightly beyond me. :-(
>>
>> My debugging indicates that email is not passing the parameters
>> (username/password) to ssmtp to initiate the TLS/SSL connection. This
>> from the following error message:
>> email: FATAL: Smtp error: 530 5.7.0 Must issue a STARTTLS command first
>> f16sm6837732qba
>
>You have everything mixed up.
>
>Where did you saw that email can do TLS? It doesn't, the -u/-i 
parameters are

>for doing SMTP AUTH which is a different thing.
>
>> Are there any builds of email available that pass parameters correctly
>> to ssmtp? I indicate SMTP server in the email-config dialog -- is that
>> wrong?
>
>Doesn't matter, you can use -r , and even change the 
port, nothing
>will make email use SSL (which is needed for TLS)-- the library is not 
linked.


From my perspective, email doesn't need to do TLS, that is left to 
ssmtp. The only
thing email should be doing is passing the various commands/directives 
from the

command line to ssmtp.

I know that ssmtp can/does do TLS - I fixed that myself, and it works 
fine (from

the command line).

Relinking the TLS library with email, occurs to be redundant to me.  
Nevertheless,

if that is necessary, has anyone made a patch available to do that?

My objective is to get a command-line e-mail; if there are alternates to 
email,

please send me some suggestions.

Thanks!
Jeremy Harrison




--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Robin Walker]

--On 15 January 2007 15:42 -0800 Ross Patterson wrote:


But I'm also curious about rebase and to understand more about how one
chooses what base address and offset to use.


My curiosity is deeper than that.  I would welcome some instruction or 
elucidation on this issue.


My understanding (please correct me if I get this wrong) of normal Windows 
DLLs is that, when they need to be loaded into memory (or mapped into an 
address space), if their preferred base address and range is not free, then 
Windows will slot them in elsewhere and automatically fix-up all the 
embedded pointers in RAM to be consistent with the actual assigned run-time 
DLL base.


So, usually, no-one need be too concerned about DLL base addresses: DLLs 
just work, even if their preferred base is not available.  Things are more 
efficient if the preferred base is free, but they still work, albeit slower 
and less efficiently, if the preferred base is not free.


So, what is it about Cygwin DLLs that makes them apparently sensitive to 
base address in a way that normal Windows DLLs are not?


What is it that Cygwin "rebase" does, that Windows dynamic run-time 
rebasing cannot or does not do?


--
Robin Walker (Junior Bursar), Queens' College, Cambridge CB3 9ET, UK
[EMAIL PROTECTED]  http://www.queens.cam.ac.uk/  Tel:+44 1223 335528

p7sPfy4tzvmxf.p7s
Description: S/MIME cryptographic signature

Re: 1.5.23: ip_mreq_source not defined in cygwin/sockets.h

[Shishir Birmiwal]

Thanks, Corinna


> Would it make sense for cygwin/sockets.h to include w32api/ws2tcpip.h?
> I'm afraid that it might add to the kludge that is winsock/winsock2,
> and break some things :)

Don't do that.  Define the missing strcutures manually in your application
instead.

Also keep in mind that ip_mreq_source, ip_msfilter, in_pktinfo are only
available starting with Windows XP.  If you use them in your application,
it will not be backward compatible to NT4, W2K, or, FWIW, 95/98/Me.


Appreciate the heads-up. Thanks again.

Regards
Shishir

--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Christopher Faylor]

On Tue, Jan 16, 2007 at 11:37:46AM +, Robin Walker wrote:
>So, what is it about Cygwin DLLs that makes them apparently sensitive to 
>base address in a way that normal Windows DLLs are not?

"fork()"

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: Cygwin Python/PIL TCL/TK fork rebase solution

[Brian Dessent]

Robin Walker wrote:

> So, what is it about Cygwin DLLs that makes them apparently sensitive to
> base address in a way that normal Windows DLLs are not?

Because in order to emulate fork(), Cygwin has to be able to re-execute
the binary and have it load with the same memory layout.  If there are
DLLs that overlap and need remapping by the OS then the memory layout
becomes non-deterministic.  If Cygwin cannot create a child process with
the same memory layout as the parent, then it cannot fork and you get
the "unable to remap" error.

Keep in mind that Cygwin jumps through inordinate hoops to emulate this
"fork" concept that does not exist natively in any shape or form on
Win32, but which is a fundamental syscall around which all process
management is based on all POSIX systems.

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: Cygwin Python/PIL TCL/TK fork rebase solution

[Robin Walker]

--On 16 January 2007 07:12 -0500 Christopher Faylor wrote:


On Tue, Jan 16, 2007 at 11:37:46AM +, Robin Walker wrote:

So, what is it about Cygwin DLLs that makes them apparently sensitive to
base address in a way that normal Windows DLLs are not?


"fork()"


Sorry, I don't understand this reply.  Can you elucidate?

--
Robin Walker (Junior Bursar), Queens' College, Cambridge CB3 9ET, UK
[EMAIL PROTECTED]  http://www.queens.cam.ac.uk/  Tel:+44 1223 335528

p7sAvnrS0r8SJ.p7s
Description: S/MIME cryptographic signature

Re: Cygwin Python/PIL TCL/TK fork rebase solution

[Christopher Faylor]

On Tue, Jan 16, 2007 at 12:32:02PM +, Robin Walker wrote:
>--On 16 January 2007 07:12 -0500 Christopher Faylor wrote:
>>On Tue, Jan 16, 2007 at 11:37:46AM +, Robin Walker wrote:
>>>So, what is it about Cygwin DLLs that makes them apparently sensitive to
>>>base address in a way that normal Windows DLLs are not?
>>
>>"fork()"
>
>Sorry, I don't understand this reply.  Can you elucidate?

If Brian's response didn't help, then please do some googling on what
fork() is and how it works.  Then, if necessary, you can re-ask this
question with some context.

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/

struct passwd problem : running on XP

[DEMARCHE]

Thank you all for your help and support.

To Corinna :
well, my program was designed for being compiled even on Unix and Windows 
platform.
As far as I understand, /etc/passwd file may be designed differently depending 
on the system.

To Dave :
Yes, the use of mno-cygwin option seems to call a bad uid_t definition found on 
mingw/sys/types.h file.
Is there a way to call another types.h file without modifying pwd.h header ?
Which definition of uid_t is correct ?
Cheers,

Bruno.



--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Brian Dessent]

Brian Dessent wrote:

> Because in order to emulate fork(), Cygwin has to be able to re-execute
> the binary and have it load with the same memory layout.  If there are
> DLLs that overlap and need remapping by the OS then the memory layout
> becomes non-deterministic.  If Cygwin cannot create a child process with
> the same memory layout as the parent, then it cannot fork and you get
> the "unable to remap" error.

Also note that this explains why binaries that dynamically load modules
at runtime with dlopen() (such as Perl, Python, Apache, ...) are
particular likely to be affected by this whereas if you are just running
ordinary binaries that do no dynamic loading you almost never have to
mess with rebasing.  Specifically, if a process loads modules at runtime
and those modules need to be relocated by the OS then the memory layout
depends now on countless details of the execution of the script or the
logic flow of the binary.  Or put differently, the Windows process image
loader (i.e. the thing that loads a .exe and all DLLs that it was linked
against at link time) is relatively deterministic and repeatable, so you
can get away with unbased DLLs if there is no runtime loading since the
memory layout is still somewhat repeatably reproducable.

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: struct passwd problem : running on XP

[Dave Korn]

On 16 January 2007 12:53, DEMARCHE wrote:

> Thank you all for your help and support.
> 
> To Corinna :
> well, my program was designed for being compiled even on Unix and Windows
> platform.
> As far as I understand, /etc/passwd file may be designed differently
> depending on the system.

  On windows, "differently" means "non-existent".

> To Dave :
> Yes, the use of mno-cygwin option seems to call a bad uid_t definition
> found on mingw/sys/types.h file.
> Is there a way to call another types.h file without modifying pwd.h header ?

  No, there is not, and that is because the pwd.h header does not go with
mingw.  It is for cygwin only.  Mingw does not provide pwd.h.

> Which definition of uid_t is correct ?

  None.  Mingw does not support uid_t.  Mingw does not implement getpwent.
You cannot do any of this stuff with mingw.

  (PS.  This is not a mingw mailing list.  Mingw programming questions should
go to the mingw mailing list.  When you use -mno-cygwin to compile, you are
using mingw, not cygwin.)

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: Link errors related to vtable

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

> --- George  wrote:
  ^

Ugh - raw email addresses from headers (even your own) should be munged,
to avoid feeding spammers - http://cygwin.com/acronyms/#PCYMTNQREAIYR

>
>> Hi Dave,
>> I am sorry as I am new to c++ I need more help in
>> doing what you said is required.

According to George on 1/16/2007 3:18 AM:
> Or, since I am suspecting this might be a problem with
> the gnu c++ compiler ver 3.4.4 which is there in the
> cygwin 1.5.23 is there a way that I can download the
> 4.1 version of the c++ compiler which might solve the
> problem?

There is no official cygwin version of gcc 4.1 yet.  But you are welcome
to help move in that direction by downloading gcc 4.1 from gcc.gnu.org and
compiling it yourself, and help us work out the bugs.  But read what you
were told earlier in this thread: don't compile C++ code with gcc, use g++
instead.

- --
Don't work too hard, make some time for fun as well!

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

iD8DBQFFrNA884KuGfSFAYARAm2DAJsGRjYZQelAsZ9EUxBj3377xvss1ACeLKBq
cK4/WWyx3hAT27e6ciHifXM=
=Lv/h
-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: Link errors related to vtable

[Dave Korn]

On 16 January 2007 08:11, George wrote:

> Hi Dave,
> I am sorry as I am new to c++ I need more help in
> doing what you said is required.

  OK, step by step:

> ---
>>> g++ -O3 -Wall -I. -I.. -I../../../include -L. -L..
>>> -L../../../lib-linux -o run.x packet.o
>>> packet_generator.o hub.o main.o -lsystemc -lm 2>&1 | c++filt
>>> 
>> 
>
main.o:main.cpp:(.text$_ZN11packet_fifoC1EN7sc_core14sc_module_nameE[packet_fi
>> fo::packet_fifo(sc_core::sc_module_name)]+0x91):
>>> undefined reference to `VTT for packet_fifo'


  We have an undefined reference in main.o to the packet_fifo class vtable.
That means you have something in main.cpp, probably a function call to a
virtual function of class packet_fifo, that is trying to access the vtable and
it isn't being found at the link stage.

  So the questions you need answered are:

1.  Did the vtable get compiled by the compiler into any of the .o modules?
1a.  If yes, then why is it not being found at link-time?
1b.  If no, then where should it have been compiled and why wasn't it.

  You could answer question 1. by using 'nm' on the .o files to see whether
they contain the symbol for the vtable as seen in your error message above.
You could answer question 1a. by looking at the order of .o files in the link
command, references need to come before the things they refer to - maybe
main.o should move earlier in the list.  You could answer question 1b. by
reference to that section of the gcc manual I pointed at to see when and where
it should have been compiled and what condition for that it failed to meet.

  OTOH, I just put "undefined reference to VTT for" into google, and the very
first hit has this explanation:

http://www.centibyte.org/me/obscure-errors.html
The class [ ... ] has a virtual function (probably a destructor?) declared
that is not actually implemented. For example:


  So, did you forget to provide the implementation of a function that is
declared virtual in the class header file?


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/

.exe won't launch

[tyger tyger]

Dear all

If I compile a c/c++/f95 program to produce an executable, and I try
to launch that executable I have a problem:

If I try to launch the .exe from the same folder containing the .exe
(i.e just by typing the .exe's filename) cygwin returns

'command not found'

If I got to folder above, and launch (by typing the lower folder name,
backslash, .exe filename) the executable launches fine.

Any ideas?

With thanks

Tony

--
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: Changed handling of "!" in /bin/sh?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Luke Kendall on 1/15/2007 9:34 PM:
> On 15 Jan, Eric Blake wrote:
>>  > 
>> SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor
>>  
>>   
>>  There you go.  You have "history" enabled in SHELLOPTS, which is a 
>>  non-POSIX extension, and explains why /bin/sh is not doing what you 
>>  expected.  Your shell scripts are inheriting interactive behavior, and 
>>  trying to do history expansion when they encounter !.
> 
> Ah!  I'm not setting that - it comes "for free". :-)

Yes, bash always has a read-only variable named SHELLOPTS.  The difference
is whether it is exported to the environment, or local to the shell.

> 
> Any idea how to turn it off?

set +o history

>  I grepped in /etc/* and /etc/profile.d/*
> for SHELLOPTS but didn't find it.

And you won't, because by default the cygwin base files don't currently
export SHELLOPTS, for the very reason that it tends to interfere with
non-interactive scripts.

>  In the System Env Vars in Windows I
> define SHELLOPTS to be igncr (only).

There you go - that is the action that exported it into the environment,
instead of leaving it shell-local.

>  If I echo %SHELLOPTS% in a
> cmd.exe window it's set to igncr only.  What's defining the other
> things?

bash, as part of it's normal operation, makes SHELLOPTS track all shell
options, not just the ones requested at startup.

>  It's a readonly env variable, isn't it?  I.e. I don't think I
> can correct it from within a bash shell?

You can correct it in bash indirectly by setting shell options.

> 
> We are working in a heterogeneous environment, and use CVS for source
> code (and script) management, so that's why we want to allow CR/LF in
> script files.

Have you considered using text mounts for your script files instead?  I
intentionally ordered my recommendations in the release announcement in
the order that I thought were most supported; and setting SHELLOPTS is a
lower-rated feature (in my mind) than using proper line endings or proper
mount points.

> 
> Well, I think we have to use it to define igncr.  And all bash users 
> who use it for interactive shells would expect to have a history, yes!

Then write wrappers around your development tools that disable igncr, or
write a script and set BASH_ENV pointing to that script that only sets
igncr if the current shell is interactive (if $- contains i), rather than
setting SHELLOPTS.  Or use /bin/sh instead of /bin/bash as your shell.

> 
> Are the extra options being turned on automatically only for
> interactive shells?

Yes - the fact that you ran bash interactively first is what set the
interactive shell options that are in conflict with POSIX, and the fact
that you exported SHELLOPTS is why /bin/sh picked up on those same options.

>  Do you mean that if I want POSIX behaviour from
> shell scripts then I can't have history for interactive shells? 

No, you just have to be more careful about how you go about getting igncr
behavior.

> 
> Perhaps a simple workaround is to replace /bin/sh with /bin/ash?

If you use /bin/sh as your login shell, then fewer options will be set in
SHELLOPTS automatically.  I would not recommend using /bin/ash; the
version on cygwin is quite buggy, and lacking several POSIX-compliant
fixes that linux compilations have added in the past few years.

> 
> I'm puzzled that others haven't found the same problem, so I still
> suspect there must be something unusual about my setup.

Actually, others have reported the problem of SHELLOPTS interfering with
scripts before.  I just haven't had time to try and analyze how easy or
hard it would be to patch bash to unset interactive options when starting
non-interactively.

- --
Don't work too hard, make some time for fun as well!

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

iD8DBQFFrNO984KuGfSFAYARAhJmAJ4kq9rK5pmj+lMeM06vtGNFhcxztwCeNaWJ
Ax09lfzodr16Sqg78/NlAoM=
=Mdu0
-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: .exe won't launch

[Dave Korn]

On 16 January 2007 13:30, tyger tyger wrote:

> Dear all
> 
> If I compile a c/c++/f95 program to produce an executable, and I try
> to launch that executable I have a problem:
> 
> If I try to launch the .exe from the same folder containing the .exe
> (i.e just by typing the .exe's filename) cygwin returns
> 
> 'command not found'
> 
> If I got to folder above, and launch (by typing the lower folder name,
> backslash, .exe filename) the executable launches fine.
> 
> Any ideas?

  You could stay in the same folder and use dot, backslash, exe filename as
well.  That's how posix shells work.  The current directory ('.') isn't
included in the path by default, which is different from how DOS works; hence
your surprise.  (This is in the FAQ, btw.)


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: git 1.4.4.4 problem on windows xp.

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to William Adams on 1/15/2007 11:06 PM:
> I have a git repository that I can clone fine from linux and macosx
> clients, but when I try to
> clone it on windows I get a "cannot  find shell32" error.

I haven't really seen that error before.  Are you running any invasive
buggy driver, that might be causing problems?  Known culprits include
agnitum outpost, mcafee virus scanner, logitech webcam, ...

> 
> I have attached the info from cygcheck.

No you haven't.

- --
Don't work too hard, make some time for fun as well!

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

iD8DBQFFrNZc84KuGfSFAYARArkwAJ0RD398f3XQur1WGcN+gN61mjoK+QCgzpPC
vr19xBsRR6kJX1g1F/23znU=
=svWQ
-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: .exe won't launch

[Tim Prince]

[EMAIL PROTECTED] wrote:

Dear all

If I compile a c/c++/f95 program to produce an executable, and I try
to launch that executable I have a problem:

If I try to launch the .exe from the same folder containing the .exe
(i.e just by typing the .exe's filename) cygwin returns

'command not found'

If I got to folder above, and launch (by typing the lower folder name,
backslash, .exe filename) the executable launches fine.

Any ideas?
There are useful documentation links, and suggestions about how to 
report problems, at the bottom of your report.  Did you try the normal 
way of invoking from the current directory

./some.exe  ?

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

git 1.4.4.4 problem on windows xp follow up.

[William Adams]

I neglected to include the cygcheck output the second time I sent
this, I am sorry for
double posting to this list.  I have included the original message below.

Original message follows:

I have a git repository that I can clone fine from linux and macosx
clients, but when I try to
clone it on windows I get a "cannot  find shell32" error.  Now,
shell32 exists happily in my
c:\WINDOWS\system32 directory, and that directory is a part of my
path.  I do not have
the exact error from the git-clone command, but essentially the same
thing happens if
I copy over a working clone's .git directory to windows, and do
git-checkout master.  I get:

$ git-checkout master
12 [main] git-read-tree 1680 C:\cygwin\bin\git-read-tree.exe: *** fatal err
or - could not load shell32, Win32 error 487
12 [main] git-read-tree 1680 C:\cygwin\bin\git-read-tree.exe: *** fatal err
or - could not load shell32, Win32 error 487

I have attached the info from cygcheck.  I'm sure it says this, but I
do have unix line-feeds set, not
dos line feeds.

Thanks much.


cygcheck.out
Description: Binary data
--
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: email and gmail

[René Berber]

Jeremy T. Harrison wrote:
[snip]
> From my perspective, email doesn't need to do TLS, that is left to
> ssmtp.

Correct, but it can be done by both (as mailx and probably mutt does).

> The only
> thing email should be doing is passing the various commands/directives
> from the command line to ssmtp.

Not true, from email to ssmtp you could use any method available, plain message
passing, smtp auth, TLS, whatever.

> I know that ssmtp can/does do TLS - I fixed that myself, and it works
> fine (from the command line).

Works fine?  You don't seem to know how it should work.

Easy solution: get rid of your ssmtp and install Exim, then configure it to do
TLS (that means installing a certificate).

I don't know what exactly you have to do with Gmail, as I don't use it, but if
TLS is not enough and you need SMTP AUTH (they are two separate things, TLS and
AUTH) then just configure Exim to use Gmail as relay with authentication 
required.

> Relinking the TLS library with email, occurs to be redundant to me. 
> Nevertheless,
> if that is necessary, has anyone made a patch available to do that?
> 
> My objective is to get a command-line e-mail; if there are alternates to
> email,
> please send me some suggestions.

The email+Exim option works fine; don't waste your time with mailx, it doesn't
work under Cygwin (it can be compiled but it has many problems, and not only
under Cygwin).
-- 
René Berber


--
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: Endianess not declared

[Kovarththanan Rajaratnam]

Hello Dave,

Dave Korn wrote:

  The headers are part of the base cygwin package; do you have the same
version as me?

/win/t $ cygcheck -f /usr/include/ieeefp.h
cygwin-1.5.23-2


It seems so:

$ cygcheck -f /usr/include/ieeefp.h
cygwin-1.5.23-2

--
Best Regards
Kovarththanan Rajaratnam


--
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: Endianess not declared

[Dave Korn]

On 16 January 2007 17:01, Kovarththanan Rajaratnam wrote:

> Hello Dave,
> 
> Dave Korn wrote:
>>   The headers are part of the base cygwin package; do you have the same
>> version as me? 
>> 
>> /win/t $ cygcheck -f /usr/include/ieeefp.h
>> cygwin-1.5.23-2
> 
> It seems so:
> 
> $ cygcheck -f /usr/include/ieeefp.h
> cygwin-1.5.23-2


~ $ md5sum /usr/include/ieeefp.h
21e83ac9763e6898351107c2f840be91 */usr/include/ieeefp.h

?


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: Cygwin Python/PIL TCL/TK fork rebase solution

[Robin Walker]

--On 16 January 2007 04:58 -0800 Brian Dessent wrote:


Because in order to emulate fork(), Cygwin has to be able to re-execute
the binary and have it load with the same memory layout.  If there are
DLLs that overlap and need remapping by the OS then the memory layout
becomes non-deterministic.  If Cygwin cannot create a child process with
the same memory layout as the parent, then it cannot fork and you get
the "unable to remap" error.

Also note that this explains why binaries that dynamically load modules
at runtime with dlopen() (such as Perl, Python, Apache, ...) are
particular likely to be affected by this whereas if you are just running
ordinary binaries that do no dynamic loading you almost never have to
mess with rebasing.  Specifically, if a process loads modules at runtime
and those modules need to be relocated by the OS then the memory layout
depends now on countless details of the execution of the script or the
logic flow of the binary.  Or put differently, the Windows process image
loader (i.e. the thing that loads a .exe and all DLLs that it was linked
against at link time) is relatively deterministic and repeatable, so you
can get away with unbased DLLs if there is no runtime loading since the
memory layout is still somewhat repeatably reproducable.


Brian,

Thanks for the explanations.  So, if I've understood things correctly, the 
difficulty boils down to cloning a parent process's address space layout 
within that of a child, which includes ensuring that DLLs appear at the 
same base within both processes.


For this to be the problem it appears to be, I'm guessing that there must 
be some shortcoming in the Windows APIs in this area when compared with 
facilities available within other Posix-compliant OSs.


How does Linux deal with the same issues of having libraries (or whatever 
are logically equivalent to DLLs) potentially linked at different bases in 
the two address spaces?


--
Robin Walker (Junior Bursar), Queens' College, Cambridge CB3 9ET, UK
[EMAIL PROTECTED]  http://www.queens.cam.ac.uk/  Tel:+44 1223 335528

p7swZXaByzmlQ.p7s
Description: S/MIME cryptographic signature

Re: Cygwin Python/PIL TCL/TK fork rebase solution

[Christopher Faylor]

On Tue, Jan 16, 2007 at 05:50:06PM +, Robin Walker wrote:
>For this to be the problem it appears to be, I'm guessing that there must 
>be some shortcoming in the Windows APIs in this area when compared with 
>facilities available within other Posix-compliant OSs.

It isn't a shortcoming at all.  Windows is perfectly within its rights
to put DLLs whereever it wants.  Windows doesn't implement fork() so it
doesn't have to worry about creating a new process whose addresss space
is a carbon copy of another process.

>How does Linux deal with the same issues of having libraries (or whatever 
>are logically equivalent to DLLs) potentially linked at different bases in 
>the two address spaces?

fork() is part of the OS in Linux and the fork() function is absolutely
intrinsic and necessary for anything on Linux or UNIX to work correctly.
It doesn't have to deal with anything like this since a fork is in the
low level of the OS, not in a library running in an application.

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: Cygwin Python/PIL TCL/TK fork rebase solution

[Ross Patterson]

Christopher Faylor <[EMAIL PROTECTED]> writes:

> On Tue, Jan 16, 2007 at 05:50:06PM +, Robin Walker wrote:
>>For this to be the problem it appears to be, I'm guessing that there must 
>>be some shortcoming in the Windows APIs in this area when compared with 
>>facilities available within other Posix-compliant OSs.
>
> It isn't a shortcoming at all.  Windows is perfectly within its rights
> to put DLLs whereever it wants.  Windows doesn't implement fork() so it
> doesn't have to worry about creating a new process whose addresss space
> is a carbon copy of another process.
>
>>How does Linux deal with the same issues of having libraries (or whatever 
>>are logically equivalent to DLLs) potentially linked at different bases in 
>>the two address spaces?
>
> fork() is part of the OS in Linux and the fork() function is absolutely
> intrinsic and necessary for anything on Linux or UNIX to work correctly.
> It doesn't have to deal with anything like this since a fork is in the
> low level of the OS, not in a library running in an application.

This has been an illuminating discussion and has given a lot more
detail to what I already understood about the rebase/fork issue.

I'd still like to understand how one chooses base address and offset
values for rebase, seeing as I was just shooting in the dark until
something said "OWW!"  :)

Anyone?

Ross


--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Brian Dessent]

Robin Walker wrote:

> Thanks for the explanations.  So, if I've understood things correctly, the
> difficulty boils down to cloning a parent process's address space layout
> within that of a child, which includes ensuring that DLLs appear at the
> same base within both processes.

Note that the "cloning" that is happening in the case of Cygwin is done
entirely in userspace without any co-operation from the OS/kernel,
essentially by faking it -- spawn another copy of the binary and hope
that it takes the same layout.  Note that Cygwin can do some fixups on
things like file handles and things that were allocated under its
control, but it's totally at the mercy of the operating system for
things out of its control like where DLLs get loaded.

> For this to be the problem it appears to be, I'm guessing that there must
> be some shortcoming in the Windows APIs in this area when compared with
> facilities available within other Posix-compliant OSs.

It's not so much a shortcoming, it's just a fundamental difference in
how the two operating systems were designed.  The core of process
management on Win32 is CreateProcess(), which spawns a new process from
scratch, whereas the core of process management on posix systems is
fork(), which makes a duplicate copy of an existing process.

> How does Linux deal with the same issues of having libraries (or whatever
> are logically equivalent to DLLs) potentially linked at different bases in
> the two address spaces?

The "issue" does not even exist on posix systems, as fork() is simply a
kernel syscall.  You ask the kernel to make a copy of the process and it
does.  By definition the child has the exact same memory layout as the
parent, because the kernel memory manager arranges it so.

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: Cygwin Python/PIL TCL/TK fork rebase solution

[Robin Walker]

--On 16 January 2007 10:09 -0800 Ross Patterson wrote:


This has been an illuminating discussion and has given a lot more
detail to what I already understood about the rebase/fork issue.

I'd still like to understand how one chooses base address and offset
values for rebase, seeing as I was just shooting in the dark until
something said "OWW!"


"Process Explorer" from 
 allows you to 
view all the DLLs of a process and their preferred and actual base 
addresses.  So if you have a running Cygwin process, Process Explorer can 
at least give you a hint where there are gaps in its address space.


--
Robin Walker (Junior Bursar), Queens' College, Cambridge CB3 9ET, UK
[EMAIL PROTECTED]  http://www.queens.cam.ac.uk/  Tel:+44 1223 335528

p7sJ0qU4SMUnv.p7s
Description: S/MIME cryptographic signature

Re: Snapshot speed on managing files

[Brian Ford]

On Sat, 13 Jan 2007, Corinna Vinschen wrote:
> On Jan 12 10:34, Brian Ford wrote:
> > On Fri, 12 Jan 2007, Corinna Vinschen wrote:
> > > Current CVS contains a change which is probably the cause for that.
> > > Before deleting a file, the file is moved to the recycle bin.
> >
> > Couldn't we make this conditional only if a "regular" delete fails because
> > the file is in use?  Would it then only penalize deletes of open files?
> >
> > (Incidentally, I've noticed this as well.)

Ok, I only noticed this anecdotally, not scientifically.  See below...

> Ok, next thing is taking the time with the current implementation
> which always moves the file to the bin:
>
>   $ ./deltest.sh
>   Creating files... Ok.
>   Deleting files ...
>   real0m2.546s
>   user0m0.233s
>   sys 0m0.578s

With this test case, I'm in your league:

$ ./deltest.sh
Creating files... Ok.
Deleting files ...
real0m2.828s
user0m0.296s
sys 0m1.531s

I'm also running "VirusScan Enterprise 8.0.0 On Access Scanner
Enabled" (corporate policy).

With On Access Scan disabled, I can reproduce the OP's result:

$ ./deltest.sh
Creating files... Ok.
Deleting files ...
real1m45.333s
user0m0.093s
sys 0m1.359s

A quick look via Filemon doesn't show where the time is going.  But since
I don't regularly run this way, I'm not that interested in pursuing this
further.

I regularly delete 100,000 files at a time under 1.5.18, and the rm return
is rather snappy.  About two weeks ago I was cleaning space of my drive
under a then current CVS build with On Access Scan enabled (before my 64k
I/O change, although I don't think that's relevant), and deleting a few
thousand files was very slow comparatively.  So, I presumed I had seen the
problem.

Since I can't duplicate this observation now, I'm sorry for the wasted
effort.

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...



--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Brian Dessent]

Ross Patterson wrote:

> I'd still like to understand how one chooses base address and offset
> values for rebase, seeing as I was just shooting in the dark until
> something said "OWW!"  :)

Well normally you don't really choose anything.  There are two ways to
assign the base address.  And again keep in mind that for a lot of
users, this won't matter; it tends to only comes into play in the
presence of dynamically loaded modules.

If you run rebaseall, it just takes a list of all known Cygwin DLLs on
the system (based on the /etc/setup/*.lst.gz files created by setup) and
starting at some address near the top of memory (currently 0x7000
but this might have been 0x6800 in the recent past) it assigns them
in back to back slots, in descending order.  This should fix most
problems as it ensures that every known DLL loads to a unique spot in
virtual memory.

But it requires the user to run rebaseall, which in turn requires that
all DLLs be not in use so they can be modified, and it requires that
once this has been done the first that it be repeated any time a new
DLL-containing package is installed. 

It also fails if the program you're running tries to use a DLL not known
by setup.exe, such as a user-compiled binary, or something that loads a
DLL not managed by setup.exe.  In that case you're supposed to supply a
list of any such extra DLLs to rebaseall with -T so that it can include
them in the assignment.

In other words, this is the "guarantee that it works but requires a lot
of effort" method.

The other way, which is a lot better in general, is to just let the
linker assign a base address it when it creates the DLL.  If you pass
--enable-auto-image-base to ld (thus, "-Wl,--enable-auto-image-base" as
option to gcc/g++) then it will use a hash function to assign the base
address based on the filename of the DLL.  That function is currently:

static unsigned long
compute_dll_image_base (const char *ofile)
{
  unsigned long hash = strhash (ofile);
  return 0x6130 + ((hash << 16) & 0x0FFC);
}

..which means it will end up somewhere between 0x6130 and
0x712C.  This does not guarantee that there are no overlapping DLLs
since it's only just a simple hash, but it is much more convenient as
the package creator can do this once when compiling the package and it
will be set for all users.  I don't know whether ld defaults to
--enable-auto-image-base being enabled or not, but I do know that if you
use e.g. libtool it will automatically add this option for you. 
Ideally, if all packages were compiled this way we would not need
rebase/rebaseall at all.  

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: Cygwin Python/PIL TCL/TK fork rebase solution

[Ross Patterson]

Robin Walker <[EMAIL PROTECTED]> writes:

> --On 16 January 2007 10:09 -0800 Ross Patterson wrote:
>
>> This has been an illuminating discussion and has given a lot more
>> detail to what I already understood about the rebase/fork issue.
>>
>> I'd still like to understand how one chooses base address and offset
>> values for rebase, seeing as I was just shooting in the dark until
>> something said "OWW!"
>
> "Process Explorer" from
>  allows
> you to view all the DLLs of a process and their preferred and actual
> base addresses.  So if you have a running Cygwin process, Process
> Explorer can at least give you a hint where there are gaps in its
> address space.

Thanks!

Ross


--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Dave Korn]

On 16 January 2007 18:49, Brian Dessent wrote:


> 
> static unsigned long
> compute_dll_image_base (const char *ofile)
> {
>   unsigned long hash = strhash (ofile);
>   return 0x6130 + ((hash << 16) & 0x0FFC);
> }
> 
> ..which means it will end up somewhere between 0x6130 and
> 0x712C.  This does not guarantee that there are no overlapping DLLs
> since it's only just a simple hash, but it is much more convenient as
> the package creator can do this once when compiling the package and it
> will be set for all users.  I don't know whether ld defaults to
> --enable-auto-image-base being enabled or not, but I do know that if you
> use e.g. libtool it will automatically add this option for you.
> Ideally, if all packages were compiled this way we would not need
> rebase/rebaseall at all.


  We probably still would.  First, the hash might collide and put two dlls in
the same slot, and second, any dll greater than 1Mb overlaps into the next
hash slot.


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: Cygwin Python/PIL TCL/TK fork rebase solution

[Brian Dessent]

Dave Korn wrote:

>   We probably still would.  First, the hash might collide and put two dlls in
> the same slot, and second, any dll greater than 1Mb overlaps into the next
> hash slot.

Well, if we found either of those things happening I think the logical
choice would be to robustify the hashing code in ld to try to avoid it
rather than fall back to running rebaseall again, but I take your point.

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: SVN not working correctly...

[Leo28C]

I'm here to get help on Cygwin because I'm forced to use it by this program
that I need. >:-(

Now, this is what I did step by step...

1. Downloaded Cygwin from here: http://www.cygwin.com/setup.exe
2. Installed it with "devel" set to Install and "wget" set to the latest
version.
3. Downloaded the program from here: http://ps2dev.org/psp/Tools/Toolchain/
4. Extracted it (using WinZip, with folder names) to
"C:\cygwin\home\\".
5. Opened up a Cygwin shell and navigated to ~/psptoolchain (the root folder
inside the archive).
6. Typed in "svn update". I got those errors... :'(

I'm pretty sure the problem HAS to do with the line endings, because after I
changed all the files from \r\n to just \n it worked well, but then there
were more files complaining... There are endless folders, so I don't wanna
go through all of them... :-/

I'd like to keep trying that, one of my first C++ apps was one that changed
line endings, but guess what, I formatted and... wait, maybe I have it
backed up... I'll see if I can find that and make it iterate through all the
files. But tell me if there's anything wrong with the steps.

Thanks! ;-)


Christopher Faylor-8 wrote:
> 
> On Mon, Jan 15, 2007 at 07:09:08PM -0800, Leo28C wrote:
>>ARGH, Linux and anything to do with it makes me SO mad... >:(
> 
> Then what in the world are you doing here?
> 
> Go away!
> 
> 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/
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/SVN--not-working-correctly...-tf3018143.html#a8398398
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
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: SVN not working correctly...

[David Rothenberger]

On 1/16/2007 12:40 PM, Leo28C wrote:

Now, this is what I did step by step...

4. Extracted it (using WinZip, with folder names) to
"C:\cygwin\home\\".


Try using the "tar" program from Cygwin to extract instead. I downloaded 
the file, extracted with tar, and did an "svn update" with no problems 
at all. Maybe WinZip is "helping" you by doing some conversions to 
Windows line endings...


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

Does a one-legged duck swim in a circle?


--
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: struct passwd problem : running on XP

[Corinna Vinschen]

On Jan 16 11:37, Dave Korn wrote:
> On 16 January 2007 10:29, Corinna Vinschen wrote:
> > Your header files seem to be broken
> 
>   Corinna, you missed the mno-cygwin flag I think?

Indeed, sorry.


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: SVN not working correctly...

[Leo28C]

...
..

...
.

I cannot believe I fell for that. :-/
Thanks y'all! ;-)
* Hides *

David Rothenberger wrote:
> 
> On 1/16/2007 12:40 PM, Leo28C wrote:
>> Now, this is what I did step by step...
>> 
>> 4. Extracted it (using WinZip, with folder names) to
>> "C:\cygwin\home\\".
> 
> Try using the "tar" program from Cygwin to extract instead. I downloaded 
> the file, extracted with tar, and did an "svn update" with no problems 
> at all. Maybe WinZip is "helping" you by doing some conversions to 
> Windows line endings...
> 
> -- 
> David Rothenbergerspammer? -> [EMAIL PROTECTED]
> GPG/PGP: 0x92D68FD8, DB7C 5146 1AB0 483A 9D27 DFBA FBB9 E328 92D6 8FD8
> 
> Does a one-legged duck swim in a circle?
> 
> 
> --
> 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/
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/SVN--not-working-correctly...-tf3018143.html#a8399273
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Christopher Faylor]

On Tue, Jan 16, 2007 at 10:13:17AM -0800, Brian Dessent wrote:
>Robin Walker wrote:
>>Thanks for the explanations.  So, if I've understood things correctly,
>>the difficulty boils down to cloning a parent process's address space
>>layout within that of a child, which includes ensuring that DLLs appear
>>at the same base within both processes.
>
>Note that the "cloning" that is happening in the case of Cygwin is done
>entirely in userspace without any co-operation from the OS/kernel,
>essentially by faking it -- spawn another copy of the binary and hope
>that it takes the same layout.  Note that Cygwin can do some fixups on
>things like file handles and things that were allocated under its
>control, but it's totally at the mercy of the operating system for
>things out of its control like where DLLs get loaded.

I did add some code to cygwin many years ago which attempts to
dynamically load dlls at the right place by allocating memory up to the
place where the dll is supposed to load.  You can't do that with DLLs
loaded by the OS, though.

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: 1.7.0 CVS mmap failure

[Brian Ford]

On Wed, 10 Jan 2007, Brian Ford wrote:

> On Wed, 10 Jan 2007, Corinna Vinschen wrote:
>
> > I implemented the above mentioned technique, which isn't much code
> > anyway.  It reserves a memory lot big enough to fit in the whole
> > mapping, memorizes the address, free's the memory again and then uses
> > the new address in the subsequent real mappings.
> >
> > This should work (knock on wood) on all systems now.  My testcases still
> > work on my 512 MB machine, so I'd appreciate if you could give the latest
> > snapshot a try on /3GB enabled machines.
>
> Yes, this fixes my STC and the application from which it was derived.
> Thanks.

But, it breaks another application that supplies a suggested mmap address
(not MAP_FIXED) that is not available.  The VirtualAlloc needs a retry in
that case.  Maybe the retries can then be removed from the other two
locations?

I'd try a patch, but I'm afraid I'd not catch all the cases
correctly.  Let me know if you'd prefer I try anyway.

Thanks.

PS: In an strace of this, I see three fstat64s called from within a
single mmap64.  Do you know where they all are, and if two should be
optimized away?

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...



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

cygwin1.dll problem

[dkfj fjdk]

When I run the Make utility I get:
C:\cygwin\lib\gcc\i686-pc-cygwin\3.4.4\cc1plus.exe (5916): *** proc magic 
mismach detected - 0x704D1F7E/0xD079E02.
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.
make: *** [copyfile.o] Error 1

I can't find any other versions of cygwin1.dll to delete.

I tried to reinstall cygwin to solve the problem but I get:
An old version of cygwin1.dll was found here:
C:\WINDOWS\System32\cygwin1.dll
Delete?

And it can't be deleted.  I can't find it in that folder.

Can you help me with this problem?

_
Your Space. Your Friends. Your Stories. Share your world with Windows Live 
Spaces. http://discoverspaces.live.com/?loc=en-CA


cygcheck.out
Description: Binary data
--
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: cygwin1.dll problem

[Dave Korn]

On 17 January 2007 00:09, dkfj fjdk wrote:


> installed the cygwin distribution.  Rebooting is also suggested if you
> are unable to find another cygwin DLL.
> make: *** [copyfile.o] Error 1
> 
> I can't find any other versions of cygwin1.dll to delete.

  Rebooting is also suggested if you are unable to find another cygwin dll.
 
> I tried to reinstall cygwin to solve the problem but I get:
> An old version of cygwin1.dll was found here:
> C:\WINDOWS\System32\cygwin1.dll
> Delete?
> 
> And it can't be deleted.  I can't find it in that folder.
> 
> Can you help me with this problem?

  Looks like Altera may be http://cygwin.com/acronyms#3PP

HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
C__altera_quartus60_bin_cygwin_bin_cygwin1_dll

  Check for a stray copy in the altera quartus bin dir, and rename it to
something else.  You may still need to reboot.

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/

git 1.4.4.4 problem on windows xp, solution!

[William Adams]

Sorry all, I didn't google the right term, namely "Win32 error 487", which meant
a simple rebaseall fixed the issue.  All apologies for wasting people's time.

Bill

--
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: email and gmail

[andy wang]

Hi, Jeremy,

Or on another way, just get rid of SMTP+TLS stuff and directly use
Google API to access your  gmail. Unless you need your own smtp server
to talk with gmail server..

Regards,

Andy

--
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: Changed handling of "!" in /bin/sh?

[Luke Kendall]

Executive summary: thanks to Eric's reply and information, I have
a couple of workable soultions.  Thanks, Eric!

For people who want the details, see below.

On 16 Jan, Eric Blake wrote:
>  -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>  
>  According to Luke Kendall on 1/15/2007 9:34 PM:
> > On 15 Jan, Eric Blake wrote:
>  >>  > 
> SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor
>  
>  >>   
>  >>  There you go.  You have "history" enabled in SHELLOPTS, which is a 
>  >>  non-POSIX extension, and explains why /bin/sh is not doing what you 
>  >>  expected.  Your shell scripts are inheriting interactive behavior, and 
>  >>  trying to do history expansion when they encounter !.
> > 
> > Ah!  I'm not setting that - it comes "for free". :-)
>  
>  Yes, bash always has a read-only variable named SHELLOPTS.  The difference
>  is whether it is exported to the environment, or local to the shell.
>  
> > 
> > Any idea how to turn it off?
>  
>  set +o history

Ah, okay.  But I'm still hoping for a solution that won't require me to
edit 200+ scripts (e.g. to add set +o history 2> /dev/null).

> >  I grepped in /etc/* and /etc/profile.d/*
> > for SHELLOPTS but didn't find it.
>  
>  And you won't, because by default the cygwin base files don't currently
>  export SHELLOPTS, for the very reason that it tends to interfere with
>  non-interactive scripts.

Although, as you imply, some of the options are specifically to control
some behaviours of non-interactive scripts.

> >  In the System Env Vars in Windows I
> > define SHELLOPTS to be igncr (only).
>  
>  There you go - that is the action that exported it into the environment,
>  instead of leaving it shell-local.

Yes, because I need a way to affect all the non-interactive scripts for
all the Cygwin users who access the shared drive with the scripts on
it, or who cvs checkout a local copy of scripts.

But thanks for explaining the operation.

> >  If I echo %SHELLOPTS% in a
> > cmd.exe window it's set to igncr only.  What's defining the other
> > things?
>  
>  bash, as part of it's normal operation, makes SHELLOPTS track all shell
>  options, not just the ones requested at startup.

Thanks for that explanation, too.


> >  It's a readonly env variable, isn't it?  I.e. I don't think I
> > can correct it from within a bash shell?
>  
>  You can correct it in bash indirectly by setting shell options.

Do you mean, like adding set +o history into /etc/profile?  Er, but
that would turn it off for interactive use.  And if I set igncr so that
everything can see it then it has a side effect of exporting the
SHELLOPTS, so then the automatically set options are of course in the
env so they affect every sub shell.

Ouch!

It seems like I'm in a catch 22 situation.

Unless I'm still misunderstanding?

> > We are working in a heterogeneous environment, and use CVS for source
> > code (and script) management, so that's why we want to allow CR/LF in
> > script files.
>  
>  Have you considered using text mounts for your script files instead?  I
>  intentionally ordered my recommendations in the release announcement in
>  the order that I thought were most supported; and setting SHELLOPTS is a
>  lower-rated feature (in my mind) than using proper line endings or proper
>  mount points.

The other day I mailed that this was no longer working.  Some more
investigation just now clarifies it: I misunderstood.

(For reference, I wrote Re: CR/LF problems after upgrade

With a freshly-installed Cygwin from a mirror that's a few days old, and
with c:\cygwin\bin mounted textmode and a network share directory of
bash scripts also mounted in textmode, using scripts that had CR/LF
endings, each blank line in the script caused an error, and there were
other errors too.

In short, I don't think the text mounts are doing their magic
correctly at the moment.  (The scripts mentioned above did work
correctly in much older Cygwins using text mounts.)
)

I have "\\samba\x" mounted as "X:", a textmode mount.  But (to avoid
having "x:/cygnus" in my ":"-separated PATH), I have "//samba/x/cygnus"
in my PATH.

I assumed (wrongly) that because of the text mount of that share that it
would do the CR/LF mapping.

I think a solution is therefore to mount "x:" in textmode and *also*
mount "//samba/x" in text mode. I just tried this, below, and it does
indeed fix the problem.  So that's one solution - thanks, Eric!

mkdir /var/samba-x-mountpoint
mount -tfx //samba/x /var/samba-x-mountpoint

> > Well, I think we have to use it to define igncr.  And all bash users 
> > who use it for interactive shells would expect to have a history, yes!
>  
>  Then write wrappers around your development tools that disable igncr, or
>  write a script and set BASH_ENV pointing to that script that only sets
>  igncr if the current shell is interactive (if $- contains i), rather than
>  setting SHELLOPTS.  Or use /bin/sh instead of /bin/bash a

svn fails with 'svn: Can't convert string from 'UTF-8' to native encoding:'

[_Random_]

Hi,

I'm running a fresh cygwin installation on Windows XP.

I'm using the SVN client to checkout some files from
the server. I get the following error 'svn: Can't
convert string from 'UTF-8' to native encoding:'

However, if I use the 'native' SVN client, it works.

Any idea?

Thanks,
-S.




 

Never Miss an Email
Stay connected with Yahoo! Mail on your mobile.  Get started!
http://mobile.yahoo.com/services?promote=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/

Login shell?

[Luke Kendall]

A long time ago, we had the weird problem that Cygwin users who used zsh
as their main shell, would find that the .zprofile (or whatever it's
called) would not be run at login - but only if their home directory had
been created by Cygwin's mkdir!  (It *would* run if their $HOME
directory had been created by Windows explorer!)

Despite examining closely with Windows GUI tools and getfacl/setfacl,
we couldn't resolve the problem.  But Michael Wardle, a subscriber
on this list, kindly provided shell.c (on Mar 24 2005, I think), which
opened /etc/passwd, found the user's preferred shell, and started that
(falling back to /bin/bash by default in case of problems).

So I changed our Cygwin startup .bat file to run shell.exe instead of
the hard-coded "bash --login -i", and all was well.

I just want to confirm, that the traditional Cygwin way of achieving
this same result is still to modify cygwin.bat on a PC-by-PC basis
(assuming one user per PC), rather than to take the traditional Unix
way and change the shell field in /etc/passwd?

Or has some other system been instituted?  Sorry, I'm a bit out of
touch.

luke



--
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: Snapshot speed on managing files

[Larry Hall (Cygwin)]

Brian Ford wrote:



A quick look via Filemon doesn't show where the time is going.  But since
I don't regularly run this way, I'm not that interested in pursuing this
further.

I regularly delete 100,000 files at a time under 1.5.18, and the rm return
is rather snappy.  About two weeks ago I was cleaning space of my drive
under a then current CVS build with On Access Scan enabled (before my 64k
I/O change, although I don't think that's relevant), and deleting a few
thousand files was very slow comparatively.  So, I presumed I had seen the
problem.

Since I can't duplicate this observation now, I'm sorry for the wasted
effort.



Did you update your build recently?  Corinna checked in a fix for this on
Saturday .


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

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Cygwin Python/PIL TCL/TK fork rebase solution

[Ross Patterson]

Brian Dessent <[EMAIL PROTECTED]> writes:

> Ross Patterson wrote:
>
>> I'd still like to understand how one chooses base address and offset
>> values for rebase, seeing as I was just shooting in the dark until
>> something said "OWW!"  :)
>
> Well normally you don't really choose anything.  There are two ways to
> assign the base address.  And again keep in mind that for a lot of
> users, this won't matter; it tends to only comes into play in the
> presence of dynamically loaded modules.
>
> If you run rebaseall, it just takes a list of all known Cygwin DLLs on
> the system (based on the /etc/setup/*.lst.gz files created by setup) and
> starting at some address near the top of memory (currently 0x7000
> but this might have been 0x6800 in the recent past) it assigns them
> in back to back slots, in descending order.  This should fix most
> problems as it ensures that every known DLL loads to a unique spot in
> virtual memory.

Interesting, in my case, rebaseall wasn't working.  I just verified
that tk84.dll was in the /etc/setup/*.gz files and it was.  I'm
assuming that /usr/bin/tk84.dll is the same file as /bin/tk84.dll,
because /usr/bin/tk84.dll is what was in the /etc/setup/*.gz file but
/bin/tk84.dll is what I had to rebase to fix my problem.

> But it requires the user to run rebaseall, which in turn requires that
> all DLLs be not in use so they can be modified, and it requires that
> once this has been done the first that it be repeated any time a new
> DLL-containing package is installed. 

Yup, I did my rebaseall calls after a reboot and before I did anything
else every time.

Ross


--
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: Changed handling of "!" in /bin/sh?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Luke Kendall on 1/16/2007 6:53 PM:
> Do you mean, like adding set +o history into /etc/profile?  Er, but
> that would turn it off for interactive use.  And if I set igncr so that
> everything can see it then it has a side effect of exporting the
> SHELLOPTS, so then the automatically set options are of course in the
> env so they affect every sub shell.
> 
> Ouch!
> 
> It seems like I'm in a catch 22 situation.

Yes, unless I can come up with a patch that makes bash smarter about which
SHELLOPTS options it will pay attention to when started non-interactively.

> 
> I have "\\samba\x" mounted as "X:", a textmode mount.  But (to avoid
> having "x:/cygnus" in my ":"-separated PATH), I have "//samba/x/cygnus"
> in my PATH.

Why not put /cygdrive/x/cygnus in your path, then?

> 
> Sorry, let me see if I understand.  We want igncr enabled, not disabled
> (or the text mount idea above).  By developer tools do you mean all the
> scripts?  I just read up on BASH_ENV: so I could have its script say:
> 
> if expr "$-" : ".*i" > /dev/null
> then
>   :
> else
>   set +o history
> fi

Or, more efficiently (fewer processes, and fewer lines):

case $- in *i*) ;; *) set +o history ; esac

> 
> Or, copy /bin/ash.exe to replace /bin/sh.exe.

Not recommended.  The reason cygwin moved to bash as /bin/sh was to avoid
ash bugs.

> 
> Please let me restate, to check I understand what you mean by "you ran
> bash interactively first": you simply  mean, I started an interactive shell?
> (So that sees SHELLOPTS in the env because I put it there, then
> the interactive shell options get set, which conflict with POSIX.)

Yes - the fact that you ran bash interactively, and from that shell
started the non-interactive scripts, explains why the non-interactive
scripts inherited the SHELLOPTS set with interactive options.

>>  
>>  If you use /bin/sh as your login shell, then fewer options will be set in
>>  SHELLOPTS automatically.
> 
> Do you mean, change /etc/passwd so it's /bin/sh, and then change .profile
> to exec bash?

Or even change cygwin.bat to invoke sh instead of bash, if you use the
default cygwin.bat created when you installed cygwin.

> 
> Anyway, I think I now have a few workarounds, thanks to your patient
> explanations.

I hope that the BASH_ENV option works out for you.  I personally don't use
CRLF line endings, so I don't have to worry about igncr in my daily use.

- --
Don't work too hard, make some time for fun as well!

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

iD8DBQFFrZVy84KuGfSFAYARAlDXAJ40BcktrqqE9cy+/h3evOpIPcYnWQCgtETx
U9HyPHcoWCC/3orb9KCPdaU=
=zx7J
-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: Changed handling of "!" in /bin/sh?

[Luke Kendall]

On 16 Jan, Eric Blake wrote:
>  -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>  
>  According to Luke Kendall on 1/16/2007 6:53 PM:
> > Do you mean, like adding set +o history into /etc/profile?  Er, but
> > that would turn it off for interactive use.  And if I set igncr so that
> > everything can see it then it has a side effect of exporting the
> > SHELLOPTS, so then the automatically set options are of course in the
> > env so they affect every sub shell.
> > 
> > Ouch!
> > 
> > It seems like I'm in a catch 22 situation.
>  
>  Yes, unless I can come up with a patch that makes bash smarter about which
>  SHELLOPTS options it will pay attention to when started non-interactively.

Okay, then I understand.

But you've also given us two or three other solutions, too!

> > I have "\\samba\x" mounted as "X:", a textmode mount.  But (to avoid
> > having "x:/cygnus" in my ":"-separated PATH), I have "//samba/x/cygnus"
> > in my PATH.
>  
>  Why not put /cygdrive/x/cygnus in your path, then?

Good question! :-)  It's mainly because we might use other Unix
environments too (Uwin or MKS or MS SFU ), and we'd like
everything as far as possible to use common names.  

> > Sorry, let me see if I understand.  We want igncr enabled, not disabled
> > (or the text mount idea above).  By developer tools do you mean all the
> > scripts?  I just read up on BASH_ENV: so I could have its script say:
> > 
> > if expr "$-" : ".*i" > /dev/null
> > then
> > :
> > else
> > set +o history
> > fi
>  
>  Or, more efficiently (fewer processes, and fewer lines):
>  
>  case $- in *i*) ;; *) set +o history ; esac

Neat!

> > Or, copy /bin/ash.exe to replace /bin/sh.exe.
>  
>  Not recommended.  The reason cygwin moved to bash as /bin/sh was to avoid
>  ash bugs.

Okay, so that's out.

> > Please let me restate, to check I understand what you mean by "you ran
> > bash interactively first": you simply  mean, I started an interactive shell?
> > (So that sees SHELLOPTS in the env because I put it there, then
> > the interactive shell options get set, which conflict with POSIX.)
>  
>  Yes - the fact that you ran bash interactively, and from that shell
>  started the non-interactive scripts, explains why the non-interactive
>  scripts inherited the SHELLOPTS set with interactive options.
>  
>  >>  
>  >>  If you use /bin/sh as your login shell, then fewer options will be set in
>  >>  SHELLOPTS automatically.
> > 
> > Do you mean, change /etc/passwd so it's /bin/sh, and then change .profile
> > to exec bash?
>  
>  Or even change cygwin.bat to invoke sh instead of bash, if you use the
>  default cygwin.bat created when you installed cygwin.
>  
> > 
> > Anyway, I think I now have a few workarounds, thanks to your patient
> > explanations.
>  
>  I hope that the BASH_ENV option works out for you.  I personally don't use
>  CRLF line endings, so I don't have to worry about igncr in my daily use.

I'm actually planning to make sure all the PATH elements are mounted
text mode, since it seems more efficient (since there'd be a little
less overhead in forking shells).

Thanks again,

luke


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