Re: no output from GNUTLS package

[Csaba Raduly]

Hi Vasily,

On Wed, Jul 10, 2013 at 4:27 PM, Vasiliy  wrote:
> Hello,
>
> I could not get any output from 'gnutls' Cygwin64 package. Could
> somebody invoke it as follows:
>
> gnutls-cli - GnuTLS client

Try running it under the debugger:

gdb --args gnutls-cli - GnuTLS client

and at the gdb prompt, type:run

If any silent errors are happening, gdb is likely to show them.

Don't forget
> Problem reports:   http://cygwin.com/problems.html

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

libargp: argp_program_version does not work

[Fedin Pavel]

 Hello!

 I have found a problem: argp_program_version string is ignored by libargp.
 I guess the problem happens because of DLL's nature. DLLs cannot contain
unresolved symbols, so the DLL has own version of argp_program_version which
is always initialized to NULL. There's no way to override it.
 Is it possible to fix this somehow ? I guess it can be done if we move this
variable to libargp.dll.a stub library. In this case, a static definition of
this variable will be picked up from there if there's no definition in the
program.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: TEMP_FAILURE_RETRY macro missing

[Corinna Vinschen]

On Jul 10 14:45, Fedin Pavel wrote:
>  Hello!
> 
>  My cross-compiling activity has discovered that TEMP_FAILURE_RETRY() macro
> is often used, but missing in our includes. GNU code of this macro is below:
> --- cut ---
> # define TEMP_FAILURE_RETRY(expression) \
>   (__extension__
> \
> ({ long int __result;
> \
>do __result = (long int) (expression);
> \
>while (__result == -1L && errno == EINTR);
> \
>__result; }))
> --- cut ---
>  This is used in elf-utils and Prelink. What about adding it ?

That's defined in unistd.h, which is newlib territory.  Care to send a
patch to the newlib mailing list?


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

[ANNOUNCEMENT] Updated: mksh-46-1

[Chris Sutcliffe]

Version 46-1 of "mksh" has been uploaded.

MirBSD Korn Shell (mksh) is an actively developed free implementation
of the Korn Shell programming language and a successor to the Public
Domain Korn Shell (pdksh).

For a detailed list of changes, please see:

https://www.mirbsd.org/mksh.htm#r46

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

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

http://sourceware.org/lists.html#unsubscribe-simple

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

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Fwd: no output from GNUTLS package

[Vasiliy]

Thank you, Csaba,

I was able to track down a stranded library which shouldn't be there,
and now it works!

I've also tracked down that problem with 'test-driver'. Look at that:

$ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-cygwin".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sh...Reading symbols from
/usr/lib/debug/usr/bin/sh.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
[New Thread 9900.0xc10]
[New Thread 9900.0x1bec]
[New Thread 9900.0xe38]
/usr/share/automake-1.14/test-driver: line 95: $log_file: ambiguous redirect
FAIL:
/usr/share/automake-1.14/test-driver: line 114: $trs_file: ambiguous redirect
/usr/share/automake-1.14/test-driver: line 115: $trs_file: ambiguous redirect
/usr/share/automake-1.14/test-driver: line 116: $trs_file: ambiguous redirect
/usr/share/automake-1.14/test-driver: line 117: $trs_file: ambiguous redirect
[Inferior 1 (process 9900) exited with code 01]
(gdb) quit

$ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver --log-file=/tmp
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-cygwin".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sh...Reading symbols from
/usr/lib/debug/usr/bin/sh.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
--log-file=/tmp
[New Thread 2164.0x164c]
[New Thread 2164.0x24a4]
[New Thread 2164.0x2550]
/usr/share/automake-1.14/test-driver: invalid option: '--log-file=/tmp'
[New Thread 2164.0x19d4]
Usage:
  test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
  [--expect-failure={yes|no}] [--color-tests={yes|no}]
  [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
The '--test-name', '--log-file' and '--trs-file' options are mandatory.

So, there is a problem with 'test-driver' either because a testsuite
does not provide --test-name=NAME or because --log-file=/tmp or
--log-file=/tmp/delme is wrongly considered an invalid option. It
applies to automake 1.13 as well.

Could a Cygwin Team suggest if we could change that behavior,
particularly, make omitting --test-name not so critical?

--
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: emacs problem

[J. David Boyd]

Ken Brown  writes:

> On 7/10/2013 5:10 PM, Christopher Faylor wrote:
>
> Thanks.  It's also possible that this isn't a Cygwin problem.  There
> are known race conditions between emacs-24.3 and glib, which have been
> fixed in the newer version of emacs that I asked Dave to test.
>
> Dave, instead of trying the new emacs right away, would you be willing
> to install the cygwin snapshot and see if that fixes the problem?  If
> not, could you report the error message and then try the new emacs?
>
> Thanks.
>
> Ken

THanks, sure, no problem.  Where do I get the latest snapshot from?  Setup and
all updates, or the EXP setting?

Dave


--
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: emacs problem

[Corinna Vinschen]

On Jul 11 09:34, J. David Boyd wrote:
> Ken Brown  writes:
> 
> > On 7/10/2013 5:10 PM, Christopher Faylor wrote:
> >
> > Thanks.  It's also possible that this isn't a Cygwin problem.  There
> > are known race conditions between emacs-24.3 and glib, which have been
> > fixed in the newer version of emacs that I asked Dave to test.
> >
> > Dave, instead of trying the new emacs right away, would you be willing
> > to install the cygwin snapshot and see if that fixes the problem?  If
> > not, could you report the error message and then try the new emacs?
> >
> > Thanks.
> >
> > Ken
> 
> THanks, sure, no problem.  Where do I get the latest snapshot from?  Setup and
> all updates, or the EXP setting?

http://cygwin.com/snapshots/


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: libargp: argp_program_version does not work

[Andrew Schulman]

>  Hello!
> 
>  I have found a problem: argp_program_version string is ignored by libargp.

Hi Pavel.  Thanks for reporting this.  I confirm your observation.  For
example, when I compile argp's example #2
(http://www.gnu.org/software/libc/manual/html_node/Argp-Example-2.html#Argp-Example-2),
the --version option doesn't work.

>  I guess the problem happens because of DLL's nature. DLLs cannot contain
> unresolved symbols, so the DLL has own version of argp_program_version which
> is always initialized to NULL. There's no way to override it.

Also confirmed.  argp.h declares argp_program_version as

extern const char *argp_program_version;

But gllib/argp-pv.c initializes it as

const char *argp_program_version = (const char *) 0

Whether there's a way to override that value by one declared in the user's
code, I don't know.  Maybe a linker switch?

The same problem also applies to argp_program_bug_address, which is also
extern const char *.

>  Is it possible to fix this somehow ? I guess it can be done if we move this
> variable to libargp.dll.a stub library. In this case, a static definition of
> this variable will be picked up from there if there's no definition in the
> program.

This is getting outside of my knowledge.  A patch would be welcome.

Could someone with more C or Gnulib knowledge than me comment?

Andrew


--
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: Regression with 1.7.20-1

[Patrick Jane]

On Jun 10 03:28, Steven Penny wrote:
> ...To add more information, running the pipe
> 
>   ffmpeg -codecs | grep mov
> 
> with 1.7.20-1 just hangs forever, even will ignore Ctrl-C


Corinna Vinschen  cygwin.com> writes:
> There's no ffmpeg in the Cygwin distro.  Is that a Cygwin or a native
> tool?  I guess the latter, in which case you may want to try the
> latest developer snapshot 2013-06-08 from http://cygwin.com/snapshots/


I am pretty sure that I am seeing the same bug with 1.7.20-1 that Steven
reports.

In my case, I have 4 bash scripts that run in parallel processes.  2 of
those scripts launch Java programs.  The bug that I see is that Ctrl-C fails
to kill the Java processes, when it used to work.  The Java command, of
course, is not built into cygwin but is the Windows program (which you can
call from cygwin).  I am running Win 7 pro 64 bit.

Being nervous about installing snapshots, I followed Steven's workaround and
just reran setup.exe, selecting for Base --> cygwin the suggested previous
version, 1.7.18-1, and installed that.  That old version works perfectly:
Ctrl-C behaves exactly as expected.

Corinna, do you know when the next prd worthy release of cygwin is likely to
come out?  Or do I need to monitor http://cygwin.com/ml/cygwin-announce/
every day to find out?

I note that Ctrl-C bugs seem to occur semi-regularly with cygwin:
http://cygwin.com/ml/cygwin/2012-03/msg00654.html
http://cygwin.com/ml/cygwin/2013-04/msg1.html
http://cygwin.com/ml/cygwin/2012-04/msg00365.html

I wonder why?  Complex mismatch between unix and Windows signal handling
that cygwin must bridge?


--
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: Re: mingw/math.h not found while compiling R packages

[Enrico Ferrero]

Hi Larry,

Thank you for your reply and advice.

> If you are using the R from Cygwin Ports, it must be an old package since
> R is no longer offered there.  I suggest you install the R package from the
> Cygwin distribution instead and retry.  Since this list supports the Cygwin
> distribution only, this would put your issue firmly on-topic for this list
> if you can still reproduce it.  For Cygwin Ports packages, they are
> supported through the Ports site:
> 
> If you have a package from that site and have questions, problems, or
> comments, it's best to consult the mailing list there.
> --
> Larry

I got confused in my first email for some reason, but I'm definitely
using R (version 2.15.1) from the Cygwin distribution, not the ports.
I just made a clean R installation just to make sure and I still get
the same error message:

>In file included from IntervalTree.c:3:0:
>common.h:59:24: fatal error: mingw/math.h: No such file or directory
>compilation terminated.
>/usr/lib/R/etc/Makeconf:121: recipe for target `IntervalTree.o' failed
>make: *** [IntervalTree.o] Error 1
>ERROR: compilation failed for package ‘IRanges’
>* removing ‘/usr/lib/R/site-library/IRanges’

I've read there are some other problems with MinGW these days, maybe
this one is related?
In any case, is there anything I can do to try to solve the issue?
Bioconductor is vital to me and using R from within Windows is causing
me a lot of headaches.

Thanks!
Best,

Enrico

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

hyper keys running the w32 mode emacs

[J. David Boyd]

I can get hyper and super working with hyper on capslock, and super on left
and right win, works great.

If I use this code,

( if opsys-cygwin
(setq w32-pass-lwindow-to-system nil
  w32-pass-rwindow-to-system nil
  w32-pass-apps-to-system nil
  w32-lwindow-modifier 'super ; Left Windows key
  w32-rwindow-modifier 'super ; Right Windows key
  w32-apps-modifier 'hyper) ; Menu key
)

it works as it says.  But I want hyper on the capslock key, and can't find
code anywhere to do that.

Is it even possible, any ideas?

I would like to standardize what my fingers do when I change platforms, if
possible,

Thanks,

Dave


--
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: Regression with 1.7.20-1

[Christopher Faylor]

On Thu, Jul 11, 2013 at 03:09:11PM +, Patrick Jane wrote:
>On Jun 10 03:28, Steven Penny wrote:
>> ...To add more information, running the pipe
>> 
>>   ffmpeg -codecs | grep mov
>> 
>> with 1.7.20-1 just hangs forever, even will ignore Ctrl-C
>
>
>Corinna Vinschen  cygwin.com> writes:
>> There's no ffmpeg in the Cygwin distro.  Is that a Cygwin or a native
>> tool?  I guess the latter, in which case you may want to try the
>> latest developer snapshot 2013-06-08 from http://cygwin.com/snapshots/
>
>
>I am pretty sure that I am seeing the same bug with 1.7.20-1 that Steven
>reports.
>
>In my case, I have 4 bash scripts that run in parallel processes.  2 of
>those scripts launch Java programs.  The bug that I see is that Ctrl-C fails
>to kill the Java processes, when it used to work.  The Java command, of
>course, is not built into cygwin but is the Windows program (which you can
>call from cygwin).  I am running Win 7 pro 64 bit.
>
>Being nervous about installing snapshots, I followed Steven's workaround and
>just reran setup.exe, selecting for Base --> cygwin the suggested previous
>version, 1.7.18-1, and installed that.  That old version works perfectly:
>Ctrl-C behaves exactly as expected.
>
>Corinna, do you know when the next prd worthy release of cygwin is likely to
>come out?  Or do I need to monitor http://cygwin.com/ml/cygwin-announce/
>every day to find out?

There is no reason to be nervous about installing snapshots if you think
a new release will solve a problem.  A snapshot potentially always
equals a new release.  Snapshots never break things so severely that you
can't recover by just reinstalling cygwin.

And, yes, you should follow cygwin or cygwin-announce for update
announcements.

>I note that Ctrl-C bugs seem to occur semi-regularly with cygwin:
>http://cygwin.com/ml/cygwin/2012-03/msg00654.html
>http://cygwin.com/ml/cygwin/2013-04/msg1.html
>http://cygwin.com/ml/cygwin/2012-04/msg00365.html

Those are likely all the same issue.

>I wonder why?  Complex mismatch between unix and Windows signal handling
>that cygwin must bridge?

http://cygwin.com/acronyms#WJM

cgf

--
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: mingw/math.h not found while compiling R packages

[marco atzeri]

Il 7/11/2013 6:35 PM, Enrico Ferrero ha scritto:

Hi Larry,

Thank you for your reply and advice.


If you are using the R from Cygwin Ports, it must be an old package since
R is no longer offered there.  I suggest you install the R package from the
Cygwin distribution instead and retry.  Since this list supports the Cygwin
distribution only, this would put your issue firmly on-topic for this list
if you can still reproduce it.  For Cygwin Ports packages, they are
supported through the Ports site:

If you have a package from that site and have questions, problems, or
comments, it's best to consult the mailing list there.
--
Larry


I got confused in my first email for some reason, but I'm definitely
using R (version 2.15.1) from the Cygwin distribution, not the ports.
I just made a clean R installation just to make sure and I still get
the same error message:


In file included from IntervalTree.c:3:0:
common.h:59:24: fatal error: mingw/math.h: No such file or directory
compilation terminated.
/usr/lib/R/etc/Makeconf:121: recipe for target `IntervalTree.o' failed
make: *** [IntervalTree.o] Error 1
ERROR: compilation failed for package ‘IRanges’
* removing ‘/usr/lib/R/site-library/IRanges’


I've read there are some other problems with MinGW these days, maybe
this one is related?
In any case, is there anything I can do to try to solve the issue?
Bioconductor is vital to me and using R from within Windows is causing
me a lot of headaches.

Thanks!
Best,

Enrico




Hi Enrico,
could you clarify your issue with the R cygwin package ?
Are you trying to compile some addon ? How ?



Regards
Marco



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

IPV6 on 2003 R2

[L. V. Lammert]

Trying to get sshd running under Cygwin, .. it appears that Windows is
presenting an IPV6 ONLY configuration - sshd refuses to start with
"Address Family inet", and with the default "Address Family any", I can
get a *local* connection, but NOT a connection from a remote server!

Cygwin current (CYGWIN_NT-5.2) on 2003 R2. IPV6 is installed, .. and IPV4
is configured correctly. Unsure if removing IPV6 would break the 2003
configuration, so that is probably not realistic.

Any ideas would be greatly appreciated!

Lee

--
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: libargp: argp_program_version does not work

[Andrew Schulman]

> >  Hello!
> > 
> >  I have found a problem: argp_program_version string is ignored by libargp.
> 
> Hi Pavel.  Thanks for reporting this.  I confirm your observation.  For
> example, when I compile argp's example #2
> (http://www.gnu.org/software/libc/manual/html_node/Argp-Example-2.html#Argp-Example-2),
> the --version option doesn't work.
> 
> >  I guess the problem happens because of DLL's nature. DLLs cannot contain
> > unresolved symbols, so the DLL has own version of argp_program_version which
> > is always initialized to NULL. There's no way to override it.
> 
> Also confirmed.  argp.h declares argp_program_version as
> 
> extern const char *argp_program_version;
> 
> But gllib/argp-pv.c initializes it as
> 
> const char *argp_program_version = (const char *) 0
> 
> Whether there's a way to override that value by one declared in the user's
> code, I don't know.  Maybe a linker switch?

OK, I remembered how this works.  To override the initial values in your
program, you just have to reassign them at run time.

Here's how it's done with argp's example #2.  Note the first two lines of
main(), which aren't present in the upstream example.

/*** Begin modified argp example #2 ***/

#include 

const char version[] = "argp-ex2 1.0";
const char bug_address[] = "";

/* Program documentation. */
static char doc[] = "Argp example #2 -- a pretty minimal program using
argp";
static struct argp argp = { 0, 0, 0, doc };

int main (int argc, char **argv)
{
  argp_program_version = version;
  argp_program_bug_address = bug_address;

  argp_parse (&argp, argc, argv, 0, 0, 0);
}

/*** End modified argp example #2 ***/

If you compile the above version, you'll see that the --version option and
bug tracker text are available.

I'm sure this problem is familiar to developers and users of shared
libraries, but I had forgotten it.  I'll add a note to the Cygwin README
file, to help all of us remember it next time.

Andrew


--
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: mingw/math.h not found while compiling R packages

[Enrico Ferrero]

Hi,

Thanks for your help, I'll try to make things clearer.

I have a full installation of Cygwin, including R version 2.15.1,
running on my Windows XP box at work.
Bioconductor [1] is a a collection of packages for computational
biologists that is installed by compiling its packages within the R
environment.
To install the base packages (and reproduce what I believe is a bug),
one just has to type at the R prompt:

>source("http://bioconductor.org/biocLite.R";)
>biocLite()

During the compilation of the IRanges package [2], I get the following error:

> In file included from IntervalTree.c:3:0:
> common.h:59:24: fatal error: mingw/math.h: No such file or directory
> compilation terminated.
> /usr/lib/R/etc/Makeconf:121: recipe for target `IntervalTree.o' failed
> make: *** [IntervalTree.o] Error 1
> ERROR: compilation failed for package =91IRanges=92

So, apparently, R needs the math.h library to compile IRanges but
can't find it for some reason.
As far as I understand, in Cygwin, math.h is provided by the
mingw-runtime package, part of the MinGW suite [3].
According to this page [4] on the Cygwin website, math.h is indeed
installed by the mingw-runtime package, so I'm trying to figure out
why R can't access it. Maybe it's a path or symbolic links-related
problem? Maybe it has to do with the recently mentioned issues
affecting MinGW packages in Cygwin [5]?

Any help is very appreciated, thank you.

[1] http://www.bioconductor.org
[2] http://www.bioconductor.org/packages/2.12/bioc/html/IRanges.html
[3] http://www.mingw.org/
[4] 
http://cygwin.com/cgi-bin2/package-cat.cgi?file=mingw-runtime%2Fmingw-runtime-3.18-3&grep=math.h
[5] http://cygwin.com/ml/cygwin/2013-07/msg00196.html

On 11 July 2013 18:28, marco atzeri  wrote:
> Il 7/11/2013 6:35 PM, Enrico Ferrero ha scritto:
>
>> Hi Larry,
>>
>> Thank you for your reply and advice.
>>
>>> If you are using the R from Cygwin Ports, it must be an old package since
>>> R is no longer offered there.  I suggest you install the R package from
>>> the
>>> Cygwin distribution instead and retry.  Since this list supports the
>>> Cygwin
>>> distribution only, this would put your issue firmly on-topic for this
>>> list
>>> if you can still reproduce it.  For Cygwin Ports packages, they are
>>> supported through the Ports site:
>>> 
>>> If you have a package from that site and have questions, problems, or
>>> comments, it's best to consult the mailing list there.
>>> --
>>> Larry
>>
>>
>> I got confused in my first email for some reason, but I'm definitely
>> using R (version 2.15.1) from the Cygwin distribution, not the ports.
>> I just made a clean R installation just to make sure and I still get
>> the same error message:
>>
>>> In file included from IntervalTree.c:3:0:
>>> common.h:59:24: fatal error: mingw/math.h: No such file or directory
>>> compilation terminated.
>>> /usr/lib/R/etc/Makeconf:121: recipe for target `IntervalTree.o' failed
>>> make: *** [IntervalTree.o] Error 1
>>> ERROR: compilation failed for package ‘IRanges’
>>> * removing ‘/usr/lib/R/site-library/IRanges’
>>
>>
>> I've read there are some other problems with MinGW these days, maybe
>> this one is related?
>> In any case, is there anything I can do to try to solve the issue?
>> Bioconductor is vital to me and using R from within Windows is causing
>> me a lot of headaches.
>>
>> Thanks!
>> Best,
>>
>> Enrico
>>
>
>
> Hi Enrico,
> could you clarify your issue with the R cygwin package ?
> Are you trying to compile some addon ? How ?
>
>
>
> Regards
> Marco
>
>
>
> --
> 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
>



--
Enrico

--
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: mingw/math.h not found while compiling R packages

[marco atzeri]

Il 7/11/2013 10:51 PM, Enrico Ferrero ha scritto:

Hi,

Thanks for your help, I'll try to make things clearer.

I have a full installation of Cygwin, including R version 2.15.1,
running on my Windows XP box at work.
Bioconductor [1] is a a collection of packages for computational
biologists that is installed by compiling its packages within the R
environment.
To install the base packages (and reproduce what I believe is a bug),
one just has to type at the R prompt:


source("http://bioconductor.org/biocLite.R";)
biocLite()


as you are not using R-3.x the last should be

  biocLite(NULL)



During the compilation of the IRanges package [2], I get the following error:


In file included from IntervalTree.c:3:0:
common.h:59:24: fatal error: mingw/math.h: No such file or directory
compilation terminated.
/usr/lib/R/etc/Makeconf:121: recipe for target `IntervalTree.o' failed
make: *** [IntervalTree.o] Error 1
ERROR: compilation failed for package =91IRanges=92


So, apparently, R needs the math.h library to compile IRanges but
can't find it for some reason.


likely the package is broken and incorrectly identify cygwin for mingw.


As far as I understand, in Cygwin, math.h is provided by the
mingw-runtime package, part of the MinGW suite [3].
According to this page [4] on the Cygwin website, math.h is indeed
installed by the mingw-runtime package, so I'm trying to figure out
why R can't access it. Maybe it's a path or symbolic links-related
problem? Maybe it has to do with the recently mentioned issues
affecting MinGW packages in Cygwin [5]?


wrong, cygwin have its own math.h

$ cygcheck -f /usr/include/math.h
cygwin-1.7.20-1




Any help is very appreciated, thank you.


I am building biocLite, it will take some time...



[1] http://www.bioconductor.org
[2] http://www.bioconductor.org/packages/2.12/bioc/html/IRanges.html
[3] http://www.mingw.org/
[4] 
http://cygwin.com/cgi-bin2/package-cat.cgi?file=mingw-runtime%2Fmingw-runtime-3.18-3&grep=math.h
[5] http://cygwin.com/ml/cygwin/2013-07/msg00196.html



Marco


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

Troubleshooting AutoSSH

[L. V. Lammert]

Trying to debug a session, .. neither AUTOSSH_DEBUG nor AUTOSSH_LOGLEVEL:

$ env | grep AUTO
AUTOSSH_DEBUG=1
AUTOSSH_LOGLEVEL=7

nor -vv:

cygrunsrv -I AutoSSH -f "remote_link" -p /usr/bin/autossh -a " -vv \

change the logging info always ("Host key verification filed"); what is
the correct way to increase the log level?

TIA!

Lee

--
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: bzr problem

[Ken Brown]

On 7/11/2013 12:32 AM, Katsumi Yamaoka wrote:

Hi,

Recently /usr/bin/bzr doesn't work well.  For the Emacs trunk,
those two commands achieve the purpose even if issuing a warning:

$ bzr update
$ bzr commit -m "Bla bla"

Usually a warning is like:
0 [main] python2.7 1264 child_info_fork::abort: address space needed by 
'math.dll' (0x80) is already occupied

But it is sometimes:
1 [main] python2.7 5784 child_info_fork::abort: unable to remap _ARC4.dll to 
same address as parent (0xBE) - try running rebaseall

Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.


Did you run rebaseall *after* reinstalling bzr and python?  Reinstalling 
undoes the rebasing.  If that still doesn't help, try looking at the 
output of 'rebase -is' to see if it shows DLL collisions (marked with an 
asterisk).  You might also try moving /etc/rebase.db.i386 out of the way 
and the running rebaseall again, so that it can start with a clean slate.


Ken


--
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: bzr problem

[Katsumi Yamaoka]

binC_jMOtKUez.bin
Description: application/emacs-lisp
--
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: bzr problem

[Katsumi Yamaoka]

Please ignore my last reply (there's something wrong in MIME encoding).

Ken Brown wrote:
> On 7/11/2013 12:32 AM, Katsumi Yamaoka wrote:
>> Hi,
>>
>> Recently /usr/bin/bzr doesn't work well.  For the Emacs trunk,
>> those two commands achieve the purpose even if issuing a warning:
>>
>> $ bzr update
>> $ bzr commit -m "Bla bla"
>>
>> Usually a warning is like:
>> 0 [main] python2.7 1264 child_info_fork::abort: address space needed
>> by 'math.dll' (0x80) is already occupied
>>
>> But it is sometimes:
>> 1 [main] python2.7 5784 child_info_fork::abort: unable to remap
>> _ARC4.dll to same address as parent (0xBE) - try running
>> rebaseall
>>
>> Rebaseall doesn't help.  Reinstalling bzr+python doesn't, either.

> Did you run rebaseall *after* reinstalling bzr and python?

Yes, I did.

> Reinstalling undoes the rebasing.  If that still doesn't help, try
> looking at the output of 'rebase -is' to see if it shows DLL
> collisions (marked with an asterisk).

No asterisk appears.  This is a superfluity, though:

$ rebase -is| awk '{print $3}'| wc -l
2695
% rebase -is| awk '{print $3}'| sort -u| wc -l
2695

I also ran a small program[1] in the output to verify there is
no overlap in the addresses.

> You might also try moving /etc/rebase.db.i386 out of the way and the
> running rebaseall again, so that it can start with a clean slate.

I tried it but nothing changed.  Thanks anyway.

[1]

(let (base size next)
  (goto-char (point-min))
  (while (not (eobp))
(when (looking-at
   ".* base \\(0x\\([0-9a-f]+\\)\\) size \\(0x\\([0-9a-f]+\\)\\)")
  (setq base (string-to-number (match-string 2) 16)
size (string-to-number (match-string 4) 16)
next (+ base size))
  (end-of-line)
  (insert "next " (number-to-string next))
  (delete-region (goto-char (match-beginning 3)) (match-end 3))
  (insert (number-to-string size))
  (delete-region (goto-char (match-beginning 1)) (match-end 1))
  (insert (number-to-string base)))
(forward-line 1))
  (sort-numeric-fields 3 (point-min) (point-max))
  (goto-char (point-min))
  (while (re-search-forward "next \\([.0-9]+\\)" nil t)
(setq next (string-to-number (match-string 1)))
(forward-line 1)
(when (looking-at ".* base \\([.0-9]+\\)")
  (setq base (string-to-number (match-string 1)))
  (when (> next base)
(error "Overlap!")


--
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: An issue with Matlab for a mex file compiled with GNU CYGWIN g++

[Emad Gad]

I do really appreciate your help.
At least it put me on the right path.

So I decided just to test the basic idea: I used the compiler
i686-w64-mingw32-g++ to compile a simple C file with mexFunction, and see to
it being run, or called, from the Matlab command line and return the
expected value without errors. Of course I put a small mexopt.bat file to
guide the compilation process, etc.

And it happened! 
And that led me to conclude that the i686-w64-mingw32-g++ is the way to go
when it comes to Matlab, and that it is one of those approved compilers that
the Windows-based Matlab can invoke to compile a mex-based C function, and
will not complain of any missing library etc.

Now I shifted my strategy, where I decided to port my LINUX project to
Windows. The goal was to compile this project using i686-w64-mingw32-g++ so
that I can link it with the Matlab interface. As I said before, I succeeded
in doing just that, but with the cygwin g++ compiler. Now, having been
enlightened to the differences between cygwin and MinGW, I tried to restart
compiling everything with mingw species.
I am still using the cygwin shell to accomplish my scheme.

The troubles I am having now is how to build the cmake-based project with
i686-w64-mingw32-g++ compiler, through the cygwin shell? Somehow, I feel
that this may be a contradiction in terms, but let me first report my
observations.

The main issue here is that the cmake that comes with cygwin will not accept
the compiler i686-w64-mingw32-g++. It will complain that that compiler
"cannot compile a simple file" which is a lie, because I know that it does.
I actually tested, and Matlab used successfully. So how come cmake found out
that it fails to compile?

I found out the reason by invoking cmake with the option --debug-trycompile,
and there I saw what cmake is trying to do and how it failed.

cmake tests the compiler by requesting it to compile a very small file,
called textCCompile.c, that it creates on the fly. However, its uses the
absolute path of this file. To be more precise, here is the literal command
that the /cygwinish/ cmake issues 

/cygdrive/c/MinGW64/mingw64/i686-w64-mingw32-g++ -o
cmTry/testCCompile.c.o -c
/home/usrername/path/to/the/file/build/CMakeFiles/CMakeTmp/testCCompile.c.

The main problem here is that i686-w64-mingw32-g++ will not take the
absolute path of the C file /home/usrername/path/to/the/file/testCCompile.c.
Instead, it returns a "file not found" kind of error. If I invoke the same
command that cmake did invoke, it returns the same error. However, if I use
the relative path, say like the following

/cygdrive/c/MinGW64/mingw64/i686-w64-mingw32-g++ -o
cmTry/testCCompile.c.o -c ../CMakeFiles/CMakeTmp/testCCompile.c.

then the command is executed without any troubles.
So I feel now that the main problem is that mingw compiler, which worked
with Matlab, the i686-w64-mingw32-g++, does not like UNIX-style absolute
paths, and will not be able to grab any file specified using this mode.

So my question is am I in the right place? Is it normal to use a
cygwin-based cmake to compile a project with i686-w64-mingw32-g++? 

Your help is indeed appreciated.

Thanks 
 

 



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/An-issue-with-Matlab-for-a-mex-file-compiled-with-GNU-CYGWIN-g-tp100307p100686.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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: mingw/math.h not found while compiling R packages

[marco atzeri]

Il 7/12/2013 12:02 AM, marco atzeri ha scritto:

Il 7/11/2013 10:51 PM, Enrico Ferrero ha scritto:

Hi,



I am building biocLite, it will take some time...



Enrico,
As I was thinking the package is broken.
I don't know why they put a wrong and useless #include directive

If you download the package and patch the source as

---
--- orig/IRanges/src/common.h   2013-02-22 04:36:50.0 +0100
+++ IRanges/src/common.h2013-07-12 00:19:05.922405200 +0200
@@ -55,10 +55,6 @@
 #endif
 #endif

-#ifdef __CYGWIN32__
-#include 
-#endif
-
 #ifndef NAN
 #define NAN (0.0 / 0.0)
 #endif
-

after repacking
you can then install the local file with something like
 install.packages("/tmp/IRanges_1.16.6.tar.gz")

I put the already patched file here if you are interested:
http://matzeri.altervista.org/works/R/

Regards
Marco


--
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: Troubleshooting AutoSSH

[Andrew Schulman]

> Trying to debug a session, .. neither AUTOSSH_DEBUG nor AUTOSSH_LOGLEVEL:
> 
> $ env | grep AUTO
> AUTOSSH_DEBUG=1
> AUTOSSH_LOGLEVEL=7
> 
> nor -vv:
> 
> cygrunsrv -I AutoSSH -f "remote_link" -p /usr/bin/autossh -a " -vv \
> 
> change the logging info always ("Host key verification filed"); what is
> the correct way to increase the log level?

Your command line looks wrong.  Did it get cut off? It's missing some
required information in the -a argument to cygrunsrv.  That argument will
have to include all of the arguments you need to pass to autossh:  at least
the name of the host that you're connecting to, plus any other autossh or
ssh options.  For example, you might also need to include -i keyfile so ssh
will know what key file to load.

For installing autossh as a service, please read
/usr/share/doc/autossh/README.Cygwin.  It recommends using something like:

cygrunsrv \
  --install autossh \
  --path /usr/bin/autossh \
  --dep tcpip \
  --env "AUTOSSH_NTSERVICE=yes" \
  --args "-F /etc/autossh/ssh_config " \
  <... other autossh args or environment settings ...>

In particular, setting AUTOSSH_NTSERVICE=yes redirects error messages to
stdout.  From there cygrunsrv will put them into the service log file, e.g.
/var/log/autossh.log, where you can inspect them.  Otherwise I think they
go into the Windows service logs, where you might still find them but
they'll be all split up and hard to find (the interface for that is
horrible).

In general, if autossh isn't working as you expect, there are three steps
to follow, in order:

(1) Get the ssh command working.
(2) Get the autossh command working.
(3) Get the service working.

Each of these steps depends on the previous ones, so if they fail, the
later ones will too.

Good luck,
Andrew


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