Re: socket : MSG_WAITALL isn't defined

[Corinna Vinschen]

On Nov 28 08:31, patrick ficheux wrote:
> Hi,
>
> I want to use recv() with MSG_WAITALL flag. But this constant isn't defined 
> in cygwin.
> I find a old message about this issue here => 
> http://www.cygwin.com/ml/cygwin/2000-06/msg01229.html
>
> Why MSG_WAITALL is not present in cygwin ?
> It's a posix compliance problem ?

No, it's a Winsock compliance problem.  Actually the MSG_WAITALL flag
showed up for the first time in Windows 2003 Server.  So, if you rely on
this flag, your application might break when running on any earlier
Windows version up to and including Windows XP.

There are also no considerations in Cygwin's recv implementation to
emulate the MSG_WAITALL behaviour.  I put that on my TODO list for a
later Cygwin version, though.  For now you're better off with a recv
loop in your application which ensures that the right number of bytes
are read.


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/

uw-imap package

[Neil Lunn]

Good to be back.

Am I right that the current uw-imap package is built to all the defaults of
the std src distr including mailsubdir as the user account home?
If this is so I don't really see the point of distributing a binary build
that is going to look at the entire contents of a users homedir.

There seems to be some record of discussion on this but unless I am not
looking in the right place this seems to be the case, without allowing for
any external config outside of rebuilding from modified source.

Please anyone tell me I am wrong.

Neil


--
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: whois-4.7.24-1

[Lapo Luchini]

Version 4.7.24-1 of whois has been uploaded.

Whois is a client for the whois directory service.
It allows you to retrieve information on domains name,
IP addresses, and more.


If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** 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.


--
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: upx-3.01-1 (and ucl-1.03-1)

[Lapo Luchini]

Version 3.01-1 of UPX monotone has been uploaded.
(as well as version 1.03-1 of the UCL library, needed by UPX at
build-time but not at run-time)

UPX is a free, portable, extendable, high-performance executable
packer for several different executable formats. It achieves an
excellent compression ratio and offers very fast decompression. Your
executables suffer no memory overhead or other drawbacks.
UPX is copyrighted software distributed under the terms of the GNU
General Public License, with special exceptions granting the free usage
for commercial programs as stated in the UPX License Agreement.
UPX aims to be Commercial Quality Freeware.


If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** 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.


--
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 session "Closed by remote host"

[Tony Benham]

I have cygwin with ssh using public key installed on a windows machine, and I've
been able to login from another machine fine until recently. If I connect via
ssh, the client is authenticated, but then  the remote host closes the
connection. It does this if I run ssh localhost on the ssh server or from the
remote client.

The sshd daemon is running fine.

I've renamed /etc/hosts.allow and /etc/hosts.deny in case these were causing a
problem. I've checked /etc/passwd contains a valid shell for the users I'm 
connecting as, so I have :/bin/bash at the end of each user line.

The authorized_keys file does not contain any commands/restrictions as to no-pty
etc.

I've rerun mkpasswd/mkgroup to make sure the passwd/group file are ok.

The sshd log shows authentication is fine. I've included log output from
authentication ok line.
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: monitor_child_preauth: admin has
been authenticated by privileged process
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: Entering interactive session for SS
H2.
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: server_init_dispatch_20
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: server_input_channel_open: ctype se
ssion rchan 0 win 1048576 max 16384
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: input_session_request
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: channel 0: new [server-session]
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_new: init
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_new: session 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_open: channel 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_open: session 0: link with
channel 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: server_input_channel_open: confirm
session
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: server_input_channel_req: channel 0
 request pty-req reply 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_by_channel: session 0 chann
el 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_input_channel_req: session
0 req pty-req
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: Allocating pty.
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_pty_req: session 0 alloc /d
ev/tty1
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: server_input_channel_req: channel 0
 request shell reply 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_by_channel: session 0 chann
el 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_input_channel_req: session
0 req shell
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: Received SIGCHLD.
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_by_pid: pid 6044
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_exit_message: session 0 cha
nnel 0 pid 6044
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_exit_message: release chann
el 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_pty_cleanup: session 0 rele
ase /dev/tty1
Nov 28 13:50:41 ORAC sshd: PID 5712: syslogin_perform_logout: logout() returned
an error
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_by_channel: session 0 chann
el 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_close_by_channel: channel 0
 child 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: session_close: session 0 pid 0
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: channel 0: free: server-session, nc
hannels 1
Nov 28 13:50:41 ORAC sshd: PID 5712: Connection closed by 192.168.1.6
Nov 28 13:50:41 ORAC sshd: PID 5712: debug1: do_cleanup
Nov 28 13:50:41 ORAC sshd: PID 5712: Closing connection to 192.168.1.6


Can anyone suggest something I've screwed up in the setup or suggest some debug
I could try ?





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

socket : MSG_WAITALL isn't defined

[patrick ficheux]

Hi,

I want to use recv() with MSG_WAITALL flag. But this constant isn't
defined in cygwin.
I find a old message about this issue here =>
http://www.cygwin.com/ml/cygwin/2000-06/msg01229.html

Why MSG_WAITALL is not present in cygwin ?
It's a posix compliance problem ?

It seems that
# define MSG_WAITALL0x08
works well on Windows

Regards,



--
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: socket : MSG_WAITALL isn't defined

[Corinna Vinschen]

On Nov 28 15:24, patrick ficheux wrote:
> Hi,
>
> I want to use recv() with MSG_WAITALL [...]

Don't you read earlier replies on the list?


Corinna

--
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: socket : MSG_WAITALL isn't defined

[patrick ficheux]

Phil Betts a écrit :

Corinna Vinschen wrote on Wednesday, November 28, 2007 2:57 PM::

  

On Nov 28 15:24, patrick ficheux wrote:


Hi,

I want to use recv() with MSG_WAITALL [...]
  

Don't you read earlier replies on the list?


oups, ...


--
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: socket : MSG_WAITALL isn't defined

[Phil Betts]

Corinna Vinschen wrote on Wednesday, November 28, 2007 2:57 PM::

> On Nov 28 15:24, patrick ficheux wrote:
>> Hi,
>> 
>> I want to use recv() with MSG_WAITALL [...]
> 
> Don't you read earlier replies on the list?
> 
> 
> Corinna

It seems he's running an old version of Brain which had a problem 
with recv()!


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

Perl is installed in /lib, but Config.pm indicates it is in /usr/local/lib

[Etienne]

I have been trying to build rrdtool and as I watched it run I noticed a 
problem with Perl and TCL./TK.  Both indicated that they were installed in 
/usr/local/lib.  I tried a clean install of cygwin, but it still installed 
them into /lib.  I checked Config.pm and it still indicates that it is in 
/usr/local/lib.  Why is there a discrepancy?


I am running the latest version of cygwin

Thanks
Etienne 



--
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: Mounting tar files

[Ignazio Di Napoli]

joekrahn wrote:

An ISO-9660 image is sort of like a tar file, but with some extra overhead.
It sounds like you are trying to do something like Knoppix. They use a
compressed read-only filesystem for the base image, combined with a special
read/write filesystem (based on symlinks, I think) that holds actual file
data only for changed files.


It's what I would like.


Doing this in Windows would not be easy. There are some programs around that
mount ISO images as a virtual filesystem. But, if you have to install extra
support software, what is the point of installing Cygwin on an SD card? If
you want a portable Cygwin, why not put most of it onto a CD?


Because a SD card is smaller and read/write. Mounting a CD ISO copied on 
the SD would also be possible, but as you said it would require the 
installation of software. I though it could be possible to manage the 
whole thing in a simpler way (maybe with a port of some software that 
many live distribution like Knoppix use).


Thank you
Ignazio

--
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: Perl is installed in /lib, but Config.pm indicates it is in /usr/local/lib

[Larry Hall (Cygwin)]

Etienne wrote:
I have been trying to build rrdtool and as I watched it run I noticed a 
problem with Perl and TCL./TK.  Both indicated that they were installed 
in /usr/local/lib.  I tried a clean install of cygwin, but it still 
installed them into /lib.  I checked Config.pm and it still indicates 
that it is in /usr/local/lib.  Why is there a discrepancy?


I am running the latest version of cygwin


Neither the Cygwin TCL/TK nor the Cygwin Perl package install anything in
/usr/local.  See:




Perhaps looking at the output of 'cygcheck -s -r -v' would help you
find the errant installations?

--
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 1.5.24-2 gcc 3.4.4 stdio.h

[Paul Edwards]

Hi Robert.  Thanks for your reply.

> On Sun, 11 Nov 2007 03:50:28 -0500 (EST), Robert Kiesling wrote

>> I just downloaded cygwin 1.5.24-2 (just a couple of hours ago) and
>> compiled the following program with "gcc -ansi fred.c"
>> (NOTE the "-ansi" keyword):

> I have only the C99 standard in front of me, but its syntax should
> be the same as ANSI, which is:

> typedef-name:
> identifier

> and not,

> typedef-name:
> identifier1 identifier2... identifiern

> The compiler is looking for a semicolon after, "fred," and your 
> example is lacking a semicolon after, "here," anyway.

The compiler should never have been exposed to that typedef.
It is not part of the C89 standard.

> This is not the compiler's job - to demangle a possibly inconistent
> type statement. 

It is the compiler header's job (Cygwin in this case) to not expose
programs to non-C89 types when in ANSI mode.  If you go and
compile my code on some other C89 compiler, you should find that
it works, unless it has the same bug, anyway.

> It's the job of the parser and is potentially expensive 
> and invalid.

By the way, this mailing list is exposing email addresses over at:

http://www.omgili.com/mailinglist/cygwin/cygwin/com/0ce101c8240c3a5dea606501a8c0paul.html

I'll ask them to stop doing that.  I just got spammed.  :-(  Still, at least now
I know where to find replies.  :-)

BFN.  Paul.


- Original Message - 
From: "Paul Edwards" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, November 11, 2007 1:40 PM
Subject: cygwin 1.5.24-2 gcc 3.4.4 stdio.h


> I just downloaded cygwin 1.5.24-2 (just a couple of hours ago) and
> compiled the following program with "gcc -ansi fred.c"
> (NOTE the "-ansi" keyword):
> 
> #define pid_t fred was here
> 
> #include 
> 
> int main(void)
> {
> printf("hello, world\n");
> return (0);
> }
> 
> And got the following result:
> 
> In file included from /usr/include/stdio.h:46,
>  from fred.c:3:
> /usr/include/sys/types.h:180: error: parse error before "was"
> In file included from /usr/include/sys/types.h:373,
>  from /usr/include/stdio.h:46,
>  from fred.c:3:
> /usr/include/cygwin/types.h:146: error: parse error before "fred"
> 
> 
> ie it is hitting a typedef for pid_t
> 
> 
> This is the compiler version:
> 
> gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Is "-ansi" not the correct thing to do to get pure ANSI C89 headers?
> 
> BFN.  Paul.
> 

--
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: Perl is installed in /lib, but Config.pm indicates it is in /usr/local/lib

[Robert Kiesling]

[ Charset UTF-8 unsupported, converting... ]
> Etienne wrote:
> > I have been trying to build rrdtool and as I watched it run I noticed a 
> > problem with Perl and TCL./TK.  Both indicated that they were installed 
> > in /usr/local/lib.  I tried a clean install of cygwin, but it still 
> > installed them into /lib.  I checked Config.pm and it still indicates 
> > that it is in /usr/local/lib.  Why is there a discrepancy?
> > 
> > I am running the latest version of cygwin
> 
> Neither the Cygwin TCL/TK nor the Cygwin Perl package install anything in
> /usr/local.  See:
> 
> 
> 
> 
> Perhaps looking at the output of 'cygcheck -s -r -v' would help you
> find the errant installations?

What is the output of Config?

Here is a (long) one-liner to print the configuration lib paths 
(and everything else).

perl -e 'use Config; foreach (keys Config) {print "$_\t$Config{$_}";}'

Regards

-- 
Ctalk Home Page: http://ctalk-lang.sourceforge.net


--
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: Perl is installed in /lib, but Config.pm indicates it is in /usr/local/lib

[Etienne]

It looks like I misspoke slightly.  I reviewed the "Config.pm" again and it 
thinks it is installed in "/usr/lib". I don't even have a "lib" directory 
under "usr" on a clean install of cygwin.


One of the lines in "Config.pm" is "archlibexp => 
'/usr/lib/perl5/5.8/cygwin'"
Also "tclConfig.sh" has the line 
"TCL_STUB_LIB_PATH='/usr/lib/libtclstub84.a'"


Just for clarification.  I have a clean install of cygwin with the packages 
necessary to attempt a build of rrdtool.  "rrdtool" is the only software I 
have that did not come from the cygwin setup.  "Perl" and "TCL" can't find 
several functions from the following packages: libartlgpl2, libpng12-devel & 
libfreetype2-devel.  If I only disable "TCL", I get the same "undefined 
reference" errors from "PERL".  The configure script finds the libraries 
with no dificulty and if I attempt a build by disabling "TCL" and "PERL" it 
works.  The only way I can get "PERL" to be included is by using the option 
"LINKTYPE=static", but I'm not sure of the consequences of that action.


Some of the errors are "undefined reference to `_art_vpath_add_point'", 
"undefined reference to `_FT_Done_Glyph'" & "undefined reference to 
`_png_create_write_struct'"


I tried copying the contents of the "/lib" directory to "/usr/lib" and 
"/usr/local/lib" as an attempted workaround.  This however did not solve the 
problem.  Even if this is a problem with "rrdtool", it doesn't explain the 
"Config.pm" and "tclConfig.sh" files.


If I am wrong and this is a problem with "rrdtool", please let me know and I 
will address it with them instead.  I did try this with the latest version 
1.2.26 and an older version 1.2.15 with the same results.


Attached is the output of the perl command line Robert sent.

I wish cygwin would use forums instead of a mailing list.

Thanks,
Etienne

- Original Message - 
From: "Robert Kiesling" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, November 28, 2007 7:15 PM
Subject: Re: Perl is installed in /lib, but Config.pm indicates it is in 
/usr/local/lib




[ Charset UTF-8 unsupported, converting... ]

Etienne wrote:
> I have been trying to build rrdtool and as I watched it run I noticed a
> problem with Perl and TCL./TK.  Both indicated that they were installed
> in /usr/local/lib.  I tried a clean install of cygwin, but it still
> installed them into /lib.  I checked Config.pm and it still indicates
> that it is in /usr/local/lib.  Why is there a discrepancy?
>
> I am running the latest version of cygwin

Neither the Cygwin TCL/TK nor the Cygwin Perl package install anything in
/usr/local.  See:




Perhaps looking at the output of 'cygcheck -s -r -v' would help you
find the errant installations?


What is the output of Config?

Here is a (long) one-liner to print the configuration lib paths
(and everything else).

perl -e 'use Config; foreach (keys Config) {print "$_\t$Config{$_}";}'

Regards

--
Ctalk Home Page: http://ctalk-lang.sourceforge.net


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




perlconfig.tsv
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: Perl is installed in /lib, but Config.pm indicates it is in /usr/local/lib

[Etienne]

I believe that answers my questions and solves my problem.  I probably don't 
need "TCL" anyway.


Thanks,
Etienne.

- Original Message - 
From: "Robert Kiesling" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 28, 2007 8:26 PM
Subject: Re: Perl is installed in /lib, but Config.pm indicates it is in 
/usr/local/lib




[ Charset ISO-8859-1 unsupported, converting... ]
It looks like I misspoke slightly.  I reviewed the "Config.pm" again and 
it

thinks it is installed in "/usr/lib". I don't even have a "lib" directory
under "usr" on a clean install of cygwin.

One of the lines in "Config.pm" is "archlibexp =>
'/usr/lib/perl5/5.8/cygwin'"
Also "tclConfig.sh" has the line
"TCL_STUB_LIB_PATH='/usr/lib/libtclstub84.a'"

Just for clarification.  I have a clean install of cygwin with the 
packages
necessary to attempt a build of rrdtool.  "rrdtool" is the only software 
I
have that did not come from the cygwin setup.  "Perl" and "TCL" can't 
find
several functions from the following packages: libartlgpl2, 
libpng12-devel &

libfreetype2-devel.  If I only disable "TCL", I get the same "undefined
reference" errors from "PERL".  The configure script finds the libraries
with no dificulty and if I attempt a build by disabling "TCL" and "PERL" 
it
works.  The only way I can get "PERL" to be included is by using the 
option

"LINKTYPE=static", but I'm not sure of the consequences of that action.

Some of the errors are "undefined reference to `_art_vpath_add_point'",
"undefined reference to `_FT_Done_Glyph'" & "undefined reference to
`_png_create_write_struct'"

I tried copying the contents of the "/lib" directory to "/usr/lib" and
"/usr/local/lib" as an attempted workaround.  This however did not solve 
the
problem.  Even if this is a problem with "rrdtool", it doesn't explain 
the

"Config.pm" and "tclConfig.sh" files.

If I am wrong and this is a problem with "rrdtool", please let me know 
and I
will address it with them instead.  I did try this with the latest 
version

1.2.26 and an older version 1.2.15 with the same results.

Attached is the output of the perl command line Robert sent.

I wish cygwin would use forums instead of a mailing list.

Thanks,
Etienne

- Original Message - 
From: "Robert Kiesling" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, November 28, 2007 7:15 PM
Subject: Re: Perl is installed in /lib, but Config.pm indicates it is in
/usr/local/lib


>[ Charset UTF-8 unsupported, converting... ]
>> Etienne wrote:
>> > I have been trying to build rrdtool and as I watched it run I 
>> > noticed a
>> > problem with Perl and TCL./TK.  Both indicated that they were 
>> > installed

>> > in /usr/local/lib.  I tried a clean install of cygwin, but it still
>> > installed them into /lib.  I checked Config.pm and it still 
>> > indicates

>> > that it is in /usr/local/lib.  Why is there a discrepancy?
>> >
>> > I am running the latest version of cygwin
>>
>> Neither the Cygwin TCL/TK nor the Cygwin Perl package install anything 
>> in

>> /usr/local.  See:
>>
>> 
>> 
>>
>> Perhaps looking at the output of 'cygcheck -s -r -v' would help you
>> find the errant installations?
>
> What is the output of Config?
>
> Here is a (long) one-liner to print the configuration lib paths
> (and everything else).
>
> perl -e 'use Config; foreach (keys Config) {print "$_\t$Config{$_}";}'
>
> Regards
>
> -- 
> Ctalk Home Page: http://ctalk-lang.sourceforge.net

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


Cygwin only allows statically linked libraries, so the, "static," option 
is
necessary.  It is possible to build Perl with the modules (including 
PERL!)

into the binary, but the procedure escapes me at the moment.

The alternative if you need to use dynamic loading is to build Perl for
Windows; that is, with DLLs, but it's a procedure I've never attempted.

Robert



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

--
Ctalk Home Page: http://ctalk-lang.sourceforge.net





--
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 1.5.24-2 gcc 3.4.4 stdio.h

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paul Edwards on 11/28/2007 5:55 PM:

Please avoid http://cygwin.com/acronyms/#TOFU - reformatting your mail.

>
> I'll ask them to stop doing that.  I just got spammed.  :-(  Still, at
least now
> I know where to find replies.  :-)
>
> BFN.  Paul.
>
>
> - Original Message -
> From: "Paul Edwards" 
  ^

How awkward - here you are complaining about spam, then you post
plain-text email in your reply.  http://cygwin.com/acronyms/#PCYMTNQREAIYR

> 
> The compiler should never have been exposed to that typedef.
> It is not part of the C89 standard.
> 
>> This is not the compiler's job - to demangle a possibly inconistent
>> type statement. 
> 
> It is the compiler header's job (Cygwin in this case)

Actually, as I explained in this post:
http://cygwin.com/ml/cygwin/2007-11/msg00201.html

it is not Cygwin's job, but newlib's job, and:
http://cygwin.com/acronyms/#SHTDI
http://cygwin.com/acronyms/#PTC

Basically, cygwin does not promise you a C89 environment, and won't unless
someone writes the patches to do so.

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

iD8DBQFHTjZm84KuGfSFAYARAmryAKCzM3Y6PDkG6Y2Lx6dC2LokTQiQvgCfQu/I
d0KryiTNFtobYs7Bl8KKyus=
=hVQd
-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: cygwin 1.5.24-2 gcc 3.4.4 stdio.h

[Paul Edwards]

Eric Blake wrote...

> 1) the newlib headers pollute the namespace in strict ANSI mode (or in
> other words, gcc -ansi _still has bugs_ in newlib) because no one has
> submitted patches to the newlib project to clean them up.  Patches are
> welcome, but should be directed to the newlib list rather than the cygwin
> list.

Ok.

> 2) why are you trying to use -ansi in the first place?  A strict ANSI C99

First of all, I'm after strict ANSI C89, not C99.  And quite frankly, I'll
be pretty happy when C89 is universally available.

> compilation environment is very restrictive in what you can code:
> theoritically, it implies portability to other strict ANSI C99 systems,
> but in reality, how many strict C99 compliant environments are there,

Most platforms have extensions of C89.  But C89 is the common
denominator.

> really?  I think you are better off with POSIX for portability than strict
> C99, 

No, C89 is far more portable than Posix.  Posix is not part of normal
MVS, and while the USS environment exists as an option in some
systems, it is just an overhead.  Any system that supports Posix should
support C89 programs.  The reverse is not true.  It is C89 that is
portable, not Posix.

> because there are more systems trying for POSIX compliance rather
> than just C99, and because POSIX adds so many more portable interfaces
> above and beyond C99 (at the expense of some namespace clashes, as your
> example proves).  But even then, be aware that there are very few strictly
> compliant POSIX systems (cygwin certainly fails to be one of them).

There's basically no system that only runs strictly conforming programs.
All systems will allow someone to code something that assumes the
size or endianness of integers, for example.  It is the C programmers
job to not make such assumptions.  And it is the C compiler's job to
provide one of many possible C89-compliant environments.

> 3) just because strict C99 requires that you be allowed to compile code
> that #defines pid_t prior to inclusion of , what does it buy you?

It allows me to write my own Posix-replacement functions that work
on MVS etc.  Or at least a subset of them.  Which was working fine,
on multiple environments, until I ran across this C compiler that
doesn't even manage to conform to a spec that has been available for
around 20 years.

> It is more pragmatic to write code that is portable to a wide variety of
> not-quite-standard compliant systems (of which, newlib is one - it is not
> quite C99 compliant), than to expect every system to obey every standard.

They only need to obey one standard - C89.  If it doesn't do that, then you
don't have a C compiler.  Which list do I need to go to to consult someone
about modifying newlib?  I can probably make the changes to get it at least
closer to C89 compliance if I have someone to give patches to.

> Which means you are better off not #defining pid_t before including
> .

No, that stops my application from working.  I want a C89 compiler, and
Cygwin doesn't appear to provide one.  Even TC++ 1.01 for DOS managed
to provide that, and I was using that in a different project just a few months
ago.  Speaking of which, DOS is another environment that isn't Posix and
if you code for Posix, your code is in no way portable.

> How awkward - here you are complaining about spam, then you post
> plain-text email in your reply.  

Damn.  I didn't realise that.  I took care to remove Robert's email address
from the reply, not realising that my original was still there.

BFN.  Paul.


--
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: Perl is installed in /lib, but Config.pm indicates it is in /usr/local/lib

[Brian Dessent]

Etienne wrote:

> It looks like I misspoke slightly.  I reviewed the "Config.pm" again and it
> thinks it is installed in "/usr/lib". I don't even have a "lib" directory
> under "usr" on a clean install of cygwin.

You must be looking with a Windows application like Explorer.  Don't. 
/lib and /usr/lib are the same due to the mount table.  The same is true
of /bin and /usr/bin.  "ls -l /usr/lib" should show many things.  See
also:
.

> "Perl" and "TCL" can't find
> several functions from the following packages: libartlgpl2, libpng12-devel &
> libfreetype2-devel.  If I only disable "TCL", I get the same "undefined
> reference" errors from "PERL".  The configure script finds the libraries
> with no dificulty and if I attempt a build by disabling "TCL" and "PERL" it
> works.  The only way I can get "PERL" to be included is by using the option
> "LINKTYPE=static", but I'm not sure of the consequences of that action.
> 
> Some of the errors are "undefined reference to `_art_vpath_add_point'",
> "undefined reference to `_FT_Done_Glyph'" & "undefined reference to
> `_png_create_write_struct'"

Whenever reporting link failures you should include the exact cut and
paste output of the commands that were run and the resulting errors. 
It's very hard to guess what's going wrong without seeing the context of
the errors and the commands that caused them.

> I tried copying the contents of the "/lib" directory to "/usr/lib" and
> "/usr/local/lib" as an attempted workaround.  This however did not solve the
> problem.  Even if this is a problem with "rrdtool", it doesn't explain the
> "Config.pm" and "tclConfig.sh" files.

That's a very bad idea, but it should be a no-op.  Again /usr/lib and
/lib are the same thing.

> I wish cygwin would use forums instead of a mailing list.

Well, a lot of us vastly prefer mailing lists to forums.  However, there
are gateways.  You might like to try
 or
.

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: Ad: [app porting to cygwin] Invoking DLL exported routine problem - resolution(?)

[Brian Dessent]

Peter Novak wrote:

> What I forgot to mention in my previous e-mail and what turned out to be
> crucial, is that my DLL uses std::cout for writing output to the
> console. I found, that whenever I have a print to cout in a routine, the
> subprocess crashes even *before* entering the routine(!). Struggling
> with gdb and multi-threaded application showed that the crash occurred
> in an esoteric place of:

The reason it crashes before your routine is called is that (assuming
PR26123 is in fact the cause) the problem has to do with the order of
static constructors.  This happens at program startup (for objects in
the .exe) or at DLL load time (for objects in the .dll).

> The code there lists a remark about supposedly an issue of GLIBC (???):
> 59   template
> 60 basic_ostream<_CharT, _Traits>&
> 61 basic_ostream<_CharT, _Traits>::
> 62 operator<<(__ostream_type& (*__pf)(__ostream_type&))
> 63 {
> 64   // _GLIBCXX_RESOLVE_LIB_DEFECTS
> 65   // DR 60. What is a formatted input function?
> 66   // The inserters for manipulators are *not* formatted output 
> functions.
> 67   return __pf(*this);
> 68 }

The symbol/namespace _GLIBCXX in this context refers to gcc's libstdc++,
not glibc, so that's kind of a red herring.  I don't think the above
comment has anything to do with your problem per se, as DR 60 is about
formatted input:
.

> Can somebody explain me why this worked the way it did? My guess is that
> it has something to do with Linux loading a shared library into the
> memory space of the running process, while on Win32 the DLL has it's own
> memory space (?)...

On both Win32 and Linux, shared libraries are in the same memory address
space as the executable; there's no difference in that respect.

> Anyway, it does not explain why loading DLL from the
> main thread was OK, while loading it from a subprocess wasn't (all
> components, i.e. main process, subprocess and DLL use cout to print
> stuff to console).

Well again, if the bug is in fact related to the order that static
constructors are run, then the difference in behavior could simply be
due to the fact that under the hood PE and ELF use different methods of
dispatching static ctors, so it follows that the order (which is
unspecified) could be volatile.  By explicitly adding a
std::ios_base::Init static object I suppose you are somehow affecting
this order to cause it to be correct.  I can't say for sure why this is,
but it's in general a very tricky aspect of C++, see also:
.

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/