Re: [PATCH 64bit] automake 1.13.1-1: Fix config.guess result

[Yaakov (Cygwin/X)]

On 2013-04-12 00:38, Christian Franke wrote:

Recent config.guess still detects 64bit Cygwin as x86_64-unknown-cygwin.
This should probably be changed (upstream) to be consistent with
i686-pc-cygwin.


This was discussed a short while ago on cygwin-developers.  Bottom line: 
while we could do so, it would take forever for the change to 
"trickle-down" to ordinary packages.  It's really no different from 
Fedora's use of x86_64-redhat-linux for their toolchain while 
config.guess still returns x86_64-unknown-linux-gnu.  cygport handles 
this transparently, so it shouldn't cause any problems.



Yaakov


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

Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0

[Angelo Graziosi]

Ciao Steve,

Il 12/04/2013 1.59, Steve Kargl ha scritto:

On Fri, Apr 12, 2013 at 01:17:07AM +0200, Angelo Graziosi wrote:

Steve Kargl wrote


My
disagreemnet is predicated on the stupidity of using a 10 line
example subroutine without actually inspecting what it does on
whatever OS that one chooses to use.


It is just because one has tested that code that these problems came to
light... :-)



When testing, it would help if the results were properly
represented as your initial subject line was "Random seed
initialization".  It seems clear to at least me your testing


I DID that:

http://gcc.gnu.org/ml/fortran/2013-04/msg00033.html


It is only at the end of it that was opened the new on Cygwin:

http://cygwin.com/ml/cygwin/2013-04/msg00184.html


BTW, it contains also the link to the first... :)


Ciao,
  Angelo.




did not include actually inspecting what these two lines do:

CALL SYSTEM_CLOCK(COUNT=clock)
seed = clock + 37 * (/ (i-1), 1=1, n) /)

because your subject would have been "SYSTEM_CLOCK is broken
on cygwin".

If you want to see an actual issue with "Random seed initialization"
go read PR 52879.




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

Re: fstab mounting fails for some cygwin users

[Corinna Vinschen]

Hi Jeff,

On Apr 11 17:16, Jeff Avila wrote:
> 18891   59336 [main] ls 3892 symlink_info::check: 0xC022 =
> NtCreateFile (\??\UNC\boltzmann\sw)

Here's the problem.  Status code 0xC022 means "Access denied".  I
tried to reproduce your scenario, but for some reason it always works
fine in my environment, even if the user has no permissions at all on
the /sw NFS share.

This is the OS refusing to return a valid handle to the share, it's not
Cygwin.  You should try to find out why the user isn't allowed access to
this share in the first place.


Corinna

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

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

Re: UDP/DTLS sockets communication pattern is broken in Cygwin

[Corinna Vinschen]

Please don't http://cygwin.com/acronyms/#TOFU.

Thank you.

On Apr 11 18:14, Oleg Moskalenko wrote:
> I am sending the test case in the attachment. 
> 
> In the attachment, you will find source code for two programs -
> udpbugserver and udpbugclient. "make" will build them both. They work
> perfectly together in Linux, FreeBSD and Solaris. But they fail in
> Cygwin.

Thanks for the testcase.

Honestly, I have no idea how to fix this issue.  Keep in mind that the
underlying socket functions are still WinSock functions.  The fact that
the wrong socket receives the information is not determined by Cygwin
but by the underlying WinSock behaviour.

Here's an excerpt from MSDN(*):

  "Once the second socket has successfully bound, the behavior for all
   sockets bound to that port is indeterminate. For example, if all of
   the sockets on the same port provide TCP service, any incoming TCP
   connection requests over the port cannot be guaranteed to be handled
   by the correct socket — the behavior is non-deterministic."

(*) 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621%28v=vs.85%29.aspx

I don't see anywhere a description about different, more deterministic
behaviour in case of UDP sockets,  neither connected, nor unconnected.
I see an openssl bug report concerning this behaviour on the openssl
developer's list, though:
http://www.mail-archive.com/openssl-dev@openssl.org/msg29500.html
There's also a matching description in a bug report on the WSK
forum, but unfortunately nobody replied:
http://social.msdn.microsoft.com/Forums/en-US/wsk/thread/caccfb5e-46ed-4d52-8a95-2d5da22dfbb0

However, I think I found a workaround on the application level.
Apparently all packets sent to a specific address are sent to the first
socket which has been bound to the address.  If that socket has been
closed, the next in line gets the packets (unless it has been connected
and the sender is not the connected address).  So what I did was this:

Before starting step 14, I created a third socket, which then replaced
the server socket:

printf("Step 11 end\n");

int server_fd_2 = open_socket(); /* SOCKET A */
addr_bind(server_fd_2, &server_addr);
close (server_fd);
server_fd = server_fd_2;

set_socket_nonblocking(client_fd);
set_socket_nonblocking(server_fd);

printf("Step 14 start\n");

It's ugly, but I don't see another potential solution, given how the
underlying WinSock functions work.  I'm also not sure other clients
will still be able to connect to the listening 

Having said that, if anybody knows a way around this which can be
applied on the library level, please keep me informed.  I'd be glad to
change Cygwin to adhere to the expectations on POSIX systems.


Corinna

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

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

/dev/tcp support in bash shell

[Cary Lewis]

Are there any plans to add /dev/tcp/... support in Cygwin?

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

docbook2pdf errors

[Frank Fesevur]

Hi,

I want convert some documention I wrote to DocBook, but first I want
to have my environment setup correctly. So I installed all the docbook
packages and created a book.xml from the sample at
http://www.docbook.org/tdg/en/html/book.html and did some minor
changes.

This document validates properly with these commands:

$ export SGML_CATALOG_FILES=/etc/xml/catalog
$ xmllint --valid --noout --catalogs book.xml
$

But when I try to convert it to a pdf I get a lot of errors:

$ docbook2pdf book.xml
Using catalogs: /etc/sgml/xml-docbook-4.5.cat
Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#print
Working on: /cygdrive/c/Users/Frank/Dropbox/DocBook/book.xml
jade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:42:30:E:
"1D6C2" is not a character number in the document character set
jade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:43:30:E:
"1D6C3" is not a character number in the document character set
jade:/usr/share/sgml/docbook/xml-dtd-4.5/ent/isogrk4.ent:44:30:E:
"1D6D8" is not a character number in the document character set

Those "not a character number in the document character set" lines are
shown 40 times with different 1D6xx characters.

Did I do something wrong in this very basic setup, or is there
something wrong with a docbook related package?

Regards,
Frank


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";>


	Example Book
	Example
	
		
			http://creativecommons.org/licenses/by-nc-sa/3.0/";>CC-BY-NC-SA
		
		
			FrankFesevur
		
	
	
		
			This book is dedicated to you.
		
	
	
		Foreword
		
			Some content is always required.
		
	
	
		A Chapter
		
			Content is required in chapters too.
		
	
	
		Optional Appendix
		
			Appendixes are optional.
		
	
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: docbook2pdf errors

[Markus Hoenicka]

Frank Fesevur was heard to say:


Using catalogs: /etc/sgml/xml-docbook-4.5.cat
Using stylesheet: 
/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#print


I have never used the docbook2pdf tool, but these messages indicate 
that it attempts to transform an XML document using Jade and the DocBook 
DSSSL stylesheets. While you may be able to get this to work with a 
little effort, I'd recommend to use an XSLT-based toolchain (e.g. xslt 
and fop) and the DocBook XSL stylesheets for XML documents.


regards,
Markus
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

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

Re: docbook2pdf errors

[Paul Allen]

> "1D6C2" is not a character number in the document character set

I'd put money on that being unicode character "mathematical bold small
alpha".  What windoze code page are you using?  One that can handle
utf-8 or not.

--
Paul

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

Re: [64bit] type conflict for INT32

[Charles Wilson]

On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote:

It does mean that Win32API (or X11, for that matter) headers must be
#include'd before .  Before I spin a new release, could you
test if this works with emacs?


Would this problem go away if we switched to jpeg-turbo?

--
Chuck



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

Re: docbook2pdf errors

[Markus Hoenicka]

Markus Hoenicka was heard to say:

(e.g. xslt and fop) and the DocBook XSL stylesheets for XML documents.


s/xslt/xsltproc/

Markus

--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

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

Re: [64bit] type conflict for INT32

[Charles Wilson]

On 4/12/2013 10:01 AM, Charles Wilson wrote:

On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote:

It does mean that Win32API (or X11, for that matter) headers must be
#include'd before .  Before I spin a new release, could you
test if this works with emacs?


Would this problem go away if we switched to jpeg-turbo?


Sorry, wrong list. Please ignore.

--
Chuck



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

Re: docbook2pdf errors

[Frank Fesevur]

2013/4/12 Paul Allen:
>> "1D6C2" is not a character number in the document character set
>
> I'd put money on that being unicode character "mathematical bold small
> alpha".  What windoze code page are you using?  One that can handle
> utf-8 or not.

I created my book.xml with a simple copy-paste. I never set any code
page. vim opens it correctly, notepad++ says it is "ANSI". There isn't
any need to set any code page, because only ascii characters are used.

The file "isogrk4.ent" contains 40 lines (so all lines in the file
give the error) like this:
 

Regards,
Frank

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

Re: docbook2pdf errors

[Frank Fesevur]

2013/4/12 Markus Hoenicka:
> I have never used the docbook2pdf tool, but these messages indicate that it
> attempts to transform an XML document using Jade and the DocBook DSSSL
> stylesheets. While you may be able to get this to work with a little effort,
> I'd recommend to use an XSLT-based toolchain (e.g. xslt and fop) and the
> DocBook XSL stylesheets for XML documents.

I am a docbook newbie so I just wanted to try docbook2pdf to see what
the generated pdf looks like.

Regards,
Frank

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

Re: docbook2pdf errors

[Markus Hoenicka]

Frank Fesevur was heard to say:

2013/4/12 Markus Hoenicka:
I have never used the docbook2pdf tool, but these messages indicate 
that it
attempts to transform an XML document using Jade and the DocBook 
DSSSL
stylesheets. While you may be able to get this to work with a little 
effort,
I'd recommend to use an XSLT-based toolchain (e.g. xslt and fop) and 
the

DocBook XSL stylesheets for XML documents.


I am a docbook newbie so I just wanted to try docbook2pdf to see what
the generated pdf looks like.



You should understand that the entity stuff that you bumped into was a 
necessity of SGML documents in the days of yore as there was no such 
thing as UTF-8. XML documents can use the non-ASCII characters directly 
instead of using character entities if they use UTF-8. This is usually 
declared in the header like this:




In order to set up your XML toolchain, please peruse the excellent 
instructions here:


http://www.sagehill.net/docbookxsl/

regards,
Markus

--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

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

Re: docbook2pdf errors

[Frank Fesevur]

2013/4/12 Markus Hoenicka:
> In order to set up your XML toolchain, please peruse the excellent
> instructions here:
>
> http://www.sagehill.net/docbookxsl/

I will leave docbook2pdf for what it is and dig into the XSL stuff.
Many new stuff to learn ;-)

Still a bit surprised though that docbook2pdf (and docbook2html as
well) give those error out of the box.

Regards,
Frank

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

Re: docbook2pdf errors

[Markus Hoenicka]

Frank Fesevur was heard to say:

2013/4/12 Markus Hoenicka:

In order to set up your XML toolchain, please peruse the excellent
instructions here:

http://www.sagehill.net/docbookxsl/


I will leave docbook2pdf for what it is and dig into the XSL stuff.
Many new stuff to learn ;-)



Certainly the better choice.


Still a bit surprised though that docbook2pdf (and docbook2html as
well) give those error out of the box.



The reason is probably that hardly anyone except me uses SGML documents 
and an appropriate toolchain these days, so these errors may go 
unnoticed for years. As mentioned previously, I don't use docbook2pdf 
but a handcrafted toolchain using openjade and the DSSSL stylesheets for 
those few cases that require SGML documents. Once properly set up, 
things work flawlessly, but XML documents deserve different tools these 
days.


regards,
Markus
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

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

RE: UDP/DTLS sockets communication pattern is broken in Cygwin

[Oleg Moskalenko]

> 
> However, I think I found a workaround on the application level.
> Apparently all packets sent to a specific address are sent to the first socket
> which has been bound to the address.  If that socket has been closed, the 
> next in
> line gets the packets (unless it has been connected and the sender is not the
> connected address).  So what I did was this:
> 
> Before starting step 14, I created a third socket, which then replaced the 
> server
> socket:

Thank you, Corinna, for the reply and for the idea.

Unfortunately, the workaround will work well only in the case of a single 
client. 
In the multiple clients scenario, it will create a sort of race condition: 

1) some packets already scheduled by OS to the "original" packet will be lost;
2) some packets delivered in between the sockets destruction/creation will be 
wrongly rejected.

But this is better than nothing. I'll think whether we can live with it.

Regards,
Oleg

Re: UDP/DTLS sockets communication pattern is broken in Cygwin

[Corinna Vinschen]

On Apr 12 08:44, Oleg Moskalenko wrote:
> 
> > 
> > However, I think I found a workaround on the application level.
> > Apparently all packets sent to a specific address are sent to the first 
> > socket
> > which has been bound to the address.  If that socket has been closed, the 
> > next in
> > line gets the packets (unless it has been connected and the sender is not 
> > the
> > connected address).  So what I did was this:
> > 
> > Before starting step 14, I created a third socket, which then replaced the 
> > server
> > socket:
> 
> Thank you, Corinna, for the reply and for the idea.
> 
> Unfortunately, the workaround will work well only in the case of a single 
> client. 
> In the multiple clients scenario, it will create a sort of race condition: 
> 
> 1) some packets already scheduled by OS to the "original" packet will be lost;
> 2) some packets delivered in between the sockets destruction/creation will be 
> wrongly rejected.
> 
> But this is better than nothing. I'll think whether we can live with it.

Too bad.  I don't know the DTLS protocol, but isn't it possible to do
the server part with a single UDP socket?  If you keep track of the
already connected clients, you know if the just incoming packet is a
connected or connecting client, and then you can use different threads
to handle the packet further.


Corinna

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

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

RE: UDP/DTLS sockets communication pattern is broken in Cygwin

[Oleg Moskalenko]

> 
> Too bad.  I don't know the DTLS protocol, but isn't it possible to do the 
> server
> part with a single UDP socket?  If you keep track of the already connected
> clients, you know if the just incoming packet is a connected or connecting 
> client,
> and then you can use different threads to handle the packet further.
> 
> 
> Corinna
> 

Corinna, I suppose that it would be possible with a different API. The API
that OpenSSL provides makes it rather difficult. A DTLS session is "served" by 
a BIO 
object that has a dedicated socket underneath it. I am not aware whether a 
workaround 
is possible. May be application can replace that BIO with something 
"artificial" but 
I am not sure that that's possible.

The same problem happens even with "plain" UDP when many clients (thousands)
are talking to the same single UDP port (for example, a TURN server). The 
workaround would be
to create an extra application layer on top of sockets layer to differentiate 
packet "streams"
by their remote address. With POSIX behavior, such a layer is not necessary.

Oleg

Re: [PATCH 64bit] automake 1.13.1-1: Fix config.guess result

[Christian Franke]

Yaakov (Cygwin/X) wrote:

On 2013-04-12 00:38, Christian Franke wrote:

Recent config.guess still detects 64bit Cygwin as x86_64-unknown-cygwin.
This should probably be changed (upstream) to be consistent with
i686-pc-cygwin.


This was discussed a short while ago on cygwin-developers.


Sorry for the noise - apparently "Cygwin 64bit triplet" was not part of 
my Brain-RegEx used for scanning ML subjects :-)



Bottom line: while we could do so, it would take forever for the 
change to "trickle-down" to ordinary packages.  It's really no 
different from Fedora's use of x86_64-redhat-linux for their toolchain 
while config.guess still returns x86_64-unknown-linux-gnu.  cygport 
handles this transparently, so it shouldn't cause any problems.




I agree. This change would have no effect or only a cosmetic effect for 
most use cases.


Christian


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

Re: possible libtool bug blocking builds of Cygwin setup.exe

[Peter Rosin]

On 2013-04-12 16:34, Shaddy Baddah wrote:
> Hi,
> 
> I am having trouble building Cygwin setup.exe (regular 32bit on
> 32bit). I am finding that the build is hanging at the linking stage of
> libgetopt++:
> 
> make[2]: Entering directory 
> `/cygdrive/c/Users/shaddy/cygwin-home/workarea/cygwin-setup-build/libgetopt++'
>   CXXLDlibgetopt++.la
> 
> Building with options I have deduced give me some debug:
> 
> $ make AM_DEFAULT_VERBOSITY=1 am__v_lt_1=--debug 2>&1 | tee -a build.log
> 
> I find (with confirmation from pstree), the build is hung in libtool:
> 
> make[2]: Entering directory 
> `/cygdrive/c/Users/shaddy/cygwin-home/workarea/cygwin-setup-build/libgetopt++'
> /bin/sh ./libtool --debug --tag=CXX--mode=link g++  -Wall -Werror 
> -Wno-uninitialized -g -O2 -version-info 1:1:0   -o libgetopt++.la -rpath 
> /cygdrive/c/Users/shaddy/cygwin-home/workarea/cygwin-setup-build/inst/lib 
> src/GetOption.lo src/Option.lo  src/BoolOption.lo src/OptionSet.lo 
> src/StringArrayOption.lo  src/StringOption.lo
> libtool: enabling shell trace mode
> ...
> + func_convert_core_msys_to_w32 .libs/
> + set -x
> ++ /usr/bin/sed -e 's/[ ]*$//' -e 's|*|\\|g;s|/|\\|g;s|\\||g'
> 
> 
> The code that it is stuck on is:
> 
>   func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null |
> $SED -e 's/[ ]*$//' -e "$lt_sed_naive_backslashify"`
> 
> And I found the double-slash on the cmd to be problematic. If I
> manually edit it out, the build continues (but only to a real build
> failure, which I'll leave out for the moment).
> 
> I've attached the cygcheck.out from that build host, a Windows 8
> computer. However, I also encountered exactly the same problem on a
> Windows 7 computer.
> 
> Have I stumbled on a real problem?

This all sounds suspiciously like libtool bug 14022, where the reporter
had confused --build and --host. How did you run configure?

Cheers,
Peter (who will be away for the weekend)


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

Re: /dev/tcp support in bash shell

[Andrey Repin]

Greetings, Cary Lewis!

> Are there any plans to add /dev/tcp/... support in Cygwin?

Any use cases for that?


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 13.04.2013, <03:48>

Sorry for my terrible english...


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

Re: possible libtool bug blocking builds of Cygwin setup.exe

[Shaddy Baddah]

Hi Peter,

On 13/04/13 09:15, Peter Rosin wrote:


Have I stumbled on a real problem?


This all sounds suspiciously like libtool bug 14022, where the reporter
had confused --build and --host. How did you run configure?




I'm emulating what is in setup/bootstrap.sh:

$ ../cygwin-setup/configure --build="i686-pc-mingw32" 
--host="i686-pc-mingw32" -C


Earlier to that, I did the following on a fresh cvs checkout:

$ env NOCONFIGURE=1 ./bootstrap.sh
$ mkdir -p ../cygwin-setup-build/
$ cd ../cygwin-setup-build/

--
Thanks,
Shaddy

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

Re: /dev/tcp support in bash shell

[Larry Hall (Cygwin)]

On 4/12/2013 7:49 PM, Andrey Repin wrote:

Greetings, Cary Lewis!


Are there any plans to add /dev/tcp/... support in Cygwin?


Any use cases for that?


Here's one:



Bye, bye Chrome. ;-)


--
Larry

_

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

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

Re: /dev/tcp support in bash shell

[Erik Falor]

On Fri, Apr 12, 2013 at 09:12:01PM -0400, Larry Hall (Cygwin) wrote:
> On 4/12/2013 7:49 PM, Andrey Repin wrote:
> >Greetings, Cary Lewis!
> >
> >>Are there any plans to add /dev/tcp/... support in Cygwin?
> >
> >Any use cases for that?
> 
> Here's one:
> 
> 
> 
> Bye, bye Chrome. ;-)

I have really mixed feelings about this feature of Bash.  It can be a
real lifesaver on systems where tools like wget, curl or even netcat
are missing.  On the other hand, it could be a big security risk:

http://www.gnucitizen.org/blog/reverse-shell-with-bash/

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Despite the ease of allowing a reverse shell or some other exploit to
occur, I think there are far more powerful and exploitable holes in a
system than Bash.  But maybe I'm just not paranoid enough...

-- 
Erik Falor   http://unnovative.net
Registered Linux User #445632  http://linuxcounter.net


signature.asc
Description: Digital signature

Re: possible libtool bug blocking builds of Cygwin setup.exe

[Peter Rosin]

On 2013-04-13 02:31, Shaddy Baddah wrote:
> Hi Peter,
> 
> On 13/04/13 09:15, Peter Rosin wrote:
> 
>>> Have I stumbled on a real problem?
>>
>> This all sounds suspiciously like libtool bug 14022, where the reporter
>> had confused --build and --host. How did you run configure?
>>
> 
> 
> I'm emulating what is in setup/bootstrap.sh:
> 
> $ ../cygwin-setup/configure --build="i686-pc-mingw32" 
> --host="i686-pc-mingw32" -C

Since you had POSIX paths with a distinct Cygwin touch, I guess we can
stop blaming Libtool. You are apparently cross-compiling from Cygwin to
MinGW and should drop your --build argument and thus let config.guess
do its thing. I.e. stop lying to configure.

Or build with MSYS where the above --build and --host are true.

I guess the bootstrap script also needs some love if you have read it
right. I haven't read it at all.

> Earlier to that, I did the following on a fresh cvs checkout:
> 
> $ env NOCONFIGURE=1 ./bootstrap.sh
> $ mkdir -p ../cygwin-setup-build/
> $ cd ../cygwin-setup-build/
> 

Cheers,
Peter


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