On 06/21/2013 02:11 PM, Larry Hall (Cygwin) wrote:
On 6/21/2013 3:47 PM, Nellis, Kenneth wrote:
From: Larry Hall (Cygwin)
On 6/21/2013 2:38 PM, Nellis, Kenneth wrote:
I have a BAT file that calls a bash script that generates the
following (edited):
cygwin warning:
MS-DOS style path detec
Le Fri, 21 Jun 2013 22:10:15 +, Jean-Pierre Flori a écrit :
> Now there is also a x86_64w dir for windows assembly but yasm does not
> like its syntax.
> I'll be looking into that.
In fact its not yasm which is used I guess.
We should indeed use the *w directories and basically do quite everyth
Le Fri, 21 Jun 2013 18:07:00 +, Jean-Pierre Flori a écrit :
> Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit :
>
>> Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit :
>>
I'll also check without assembly optimizations, or lowering gcc
optimization level,
On 6/21/2013 3:47 PM, Nellis, Kenneth wrote:
From: Larry Hall (Cygwin)
On 6/21/2013 2:38 PM, Nellis, Kenneth wrote:
I have a BAT file that calls a bash script that generates the
following (edited):
cygwin warning:
MS-DOS style path detected: XXX
Preferred POSIX equivalent is: XXX
On 6/21/2013 9:19 AM, Arjen Markus wrote:
Hi Corinna,
you seem to have hit the right spot. The parent directories had the
permission --
according to Cygwin, but I could still enter them via cd. Things go
wrong if under Cygwin
a file gets _copied_ via cp or something similar that takes the fi
On Fri, Jun 21, 2013 at 04:03:46PM -0400, Andrew Schulman wrote:
>>On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>>>On Jun 20 22:38, Andrew Schulman wrote:
>If every maintainer would use cygport, it would allow us to change the
>build method to one along the lines of mos
> On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
> >On Jun 20 22:38, Andrew Schulman wrote:
> >> > If every maintainer would use cygport, it would allow us to change
> >> > the build method to one along the lines of most Linux distros.
> >> > In Linux distros, the maintaine
From: Larry Hall (Cygwin)
>
> On 6/21/2013 2:38 PM, Nellis, Kenneth wrote:
> > I have a BAT file that calls a bash script that generates the
> > following (edited):
> >
> > cygwin warning:
> >MS-DOS style path detected: XXX
> >Preferred POSIX equivalent is: XXX
> >CYGWIN environment va
On 6/21/2013 2:38 PM, Nellis, Kenneth wrote:
I have a BAT file that calls a bash script that generates the
following (edited):
cygwin warning:
MS-DOS style path detected: XXX
Preferred POSIX equivalent is: XXX
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
On 2013-06-21 13:10, Warren Young wrote:
On 6/21/2013 12:05, Warren Young wrote:
With cygport, you wouldn't even need to provide sources. We could email
in the new cygport file instead of an RFU.
...and patches.
...and customized .hint files, if needed.
Yeah, I guess sending the .src.tar.bz
I have a BAT file that calls a bash script that generates the
following (edited):
cygwin warning:
MS-DOS style path detected: XXX
Preferred POSIX equivalent is: XXX
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details abou
On 6/21/2013 12:05, Warren Young wrote:
On 6/20/2013 12:10, Corinna Vinschen wrote:
If every maintainer would use cygport, it would allow us to change
the build method to one along the lines of most Linux distros.
In Linux distros, the maintainer provides only the spec file and
the s
Le Fri, 21 Jun 2013 17:27:22 +, Jean-Pierre Flori a écrit :
> Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit :
>
>>> I'll also check without assembly optimizations, or lowering gcc
>>> optimization level, etc.
>> So I'm going to try that now.
> If i disable ASM routines by pass
On 6/20/2013 12:10, Corinna Vinschen wrote:
If every maintainer would use cygport, it would allow us to change
the build method to one along the lines of most Linux distros.
In Linux distros, the maintainer provides only the spec file and
the source archive. The actual build for all
On 2013-06-21 06:33, Corinna Vinschen wrote:
as our resident autotools/libtool experts, could you please have a
look here?
The problem is, as a fork of GMP, it too tries to be too clever with
libtool in an attempt to shorten configure times by avoiding the CXX/F77
checks. Those hacks are not
I've had Cygwin installed on this computer for over two years
without any problems but recently I've started seeing a few problems
and my installation seems corrupted.
1. Starting several weeks ago, whenever I run setup.exe I get this
pop-up message part way through the process.
Cygw
On 6/21/2013 10:07 AM, Corinna Vinschen wrote:
>> To the best of my knowledge the Heimdal developers have not been
>> contacted by the Cygwin Heimdal package maintainer.
>
> Well, if it builds...
We are discussing security software that must integrate with the native
environment. When MIT or Hei
Le Fri, 21 Jun 2013 17:06:03 +, Jean-Pierre Flori a écrit :
>> I'll also check without assembly optimizations, or lowering gcc
>> optimization level, etc.
> So I'm going to try that now.
If i disable ASM routines by passing MPN_PATH=generic to configure, then
(in the static setting at least)
Le Fri, 21 Jun 2013 16:56:23 +, Jean-Pierre Flori a écrit :
> And the bad news is: tests still segfault.
>
> I'll also check with the static library now.
>
With the same changes but trying a static lib I get to the same point as
for the shared one:
* ld doesn't segfault anymore, so tests exe
Thank you. I took the time to make certain that I couldn't find any
other lingering problems.
The update to 2.7.1 corrects the test case I submitted previously.
Thanks! :)
On 6/21/2013 8:11 AM, Corinna Vinschen wrote:
On Jun 20 09:46, Corinna Vinschen wrote:
On Jun 19 23:31, Matt D. wrote:
Hi all,
Here is my experience with a shared version of the library after taking
Corinna's message into account, starting from a clean MPIR tarball (except
for updating the FSF config.sub/guess) without autoreconfing, and using
the Cygwin shipped yasm rather than the one included in MPIR (in cas
On 6/14/2013 5:39 PM, Nogin, Aleksey wrote:
> I am experiencing the same error that Corinna Vinschen have reported on
> cygwin-apps mailing list about a year ago without any obvious resolution(*),
> and I was wondering whether somebody was able to resolve it since.
>
> I am running Heimdal's kin
On Fri, Jun 21, 2013 at 09:49:34AM +0200, Corinna Vinschen wrote:
>On Jun 20 22:38, Andrew Schulman wrote:
>> > If every maintainer would use cygport, it would allow us to change
>> > the build method to one along the lines of most Linux distros.
>> > In Linux distros, the maintainer provides
The following package has been updated in the 32-bit Cygwin
distribution, and a 64-bit update will follow shortly:
*** emacs-auctex-11.87-2
AUCTeX is an extensible package for writing and formatting TeX files in
GNU Emacs and XEmacs. It supports many different TeX macro packages,
including A
On Jun 21 09:39, Jeffrey Altman wrote:
> On 6/21/2013 3:43 AM, Corinna Vinschen wrote:
> > Guys, whatever the problem here is, it needs to be investigated and
> > potentially implemented by somebody who knows this kerberos/gss-api
> > stuff. Openssh is built against these libraries and that's it f
On 6/21/2013 3:43 AM, Corinna Vinschen wrote:
> Guys, whatever the problem here is, it needs to be investigated and
> potentially implemented by somebody who knows this kerberos/gss-api
> stuff. Openssh is built against these libraries and that's it from my
> side. If something's missing in opens
Le Fri, 21 Jun 2013 11:43:44 +0200, Corinna Vinschen a écrit :
> On Jun 21 09:27, Jean-Pierre Flori wrote:
>> Hey,
>>
>> Thanks for the quick reply.
>>
>> Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
>>
>> >> /bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
Hi Corinna,
you seem to have hit the right spot. The parent directories had the
permission --
according to Cygwin, but I could still enter them via cd. Things go
wrong if under Cygwin
a file gets _copied_ via cp or something similar that takes the file
permissions according
to POSIX from the p
On Jun 21 14:38, Arjen Markus wrote:
> I noticed that if I use noacl, then I get the correct looking POSIX
> permissions,
> but the Windows permissions make it impossible to use the file.
I always use "acl" as mount option.
> Try: cat gnulliver.h
$ pwd
/home/corinna/tmp/cmake/work
$ cat s
I noticed that if I use noacl, then I get the correct looking POSIX permissions,
but the Windows permissions make it impossible to use the file.
Try: cat gnulliver.h
I have had the same problem with a package built via autotools, so it
is more general
than CMake. (I first reported this on the CMa
On Jun 21 14:18, Arjen Markus wrote:
> Oops, my mistake. The correct invocation of CMake is:
>
> cmake -G "Unix Makefiles" ../
>
> (These generators are part of CMake, not of the tar file)
Ok, thank you. I never used cmake before so I didn't notice.
Other than that, I have not the problem you'
Oops, my mistake. The correct invocation of CMake is:
cmake -G "Unix Makefiles" ../
(These generators are part of CMake, not of the tar file)
Regards,
Arjen
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cyg
On Jun 21 13:40, Arjen Markus wrote:
> Here it is.
>
> Regards,
>
> Arjen
Is the tar file broken?
$ tar xvzf problem-cygwin.tgz
src/
src/CMakeLists.txt
src/include/
src/include/CMakeLists.txt
src/include/gnulliver.h.in
CMakeLists.txt
tar: A lone zero block at 11
$ mkdir work
On Jun 20 09:46, Corinna Vinschen wrote:
> On Jun 19 23:31, Matt D. wrote:
> > I've been looking further into this and it appears as though the
> > problem is in 'patch' not 'quilt'. quilt is actually a collection of
> > bash scripts and calls patch to do the actual patching.
> >
> > Using the sam
Here it is.
Regards,
Arjen
problem-cygwin.tgz
Description: GNU Zip compressed data
--
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-
On Jun 21 13:18, Arjen Markus wrote:
> Trying again:
>
> - Unpack the tar file in a separate directory, say, and create a work
> directory in which
> to configure and build it, something like:
>
> src/ - contents of the tar-file
> work/ - directory to work in
> CMakeLists.txt -
Hi Chuck, Hi Yaakov,
as our resident autotools/libtool experts, could you please have a
look here?
On Jun 21 11:43, Corinna Vinschen wrote:
> On Jun 21 09:27, Jean-Pierre Flori wrote:
> > Hey,
> >
> > Thanks for the quick reply.
> >
> > Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écr
Trying again:
- Unpack the tar file in a separate directory, say, and create a work
directory in which
to configure and build it, something like:
src/ - contents of the tar-file
work/ - directory to work in
CMakeLists.txt - the main CMake file
- Run CMake in the work directory
Well, I got a message back about using too many keywords that made it look like
an off-topic reply. But without an indication (of course) of what
these keywords are.
Regards,
Arjen
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentati
On Jun 21 13:00, Arjen Markus wrote:
> I have a small testcase, but my replies are consistently refused.
> How do I solve that?
The reason should be given in the reply you get. Basically, don't
use raw email addresses in your body, don't use html.
Corinna
--
Corinna Vinschen
I have a small testcase, but my replies are consistently refused.
How do I solve that?
Regards,
Arjen
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.co
Cygwin's TeX Live packages have been updated to the latest upstream
release, TeX Live 2013.
TeX Live provides a comprehensive, cross-platform TeX system. It
includes all the major TeX-related programs, macro packages, and fonts
that are free software, including support for many languages arou
On Jun 21 09:27, Jean-Pierre Flori wrote:
> Hey,
>
> Thanks for the quick reply.
>
> Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
>
> >> /bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
> >> -march=corei7-avx -mtune=corei7-avx-o t-bswap.exe t-bswap.o
> >
Hey,
Thanks for the quick reply.
Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
>> /bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
>> -march=corei7-avx -mtune=corei7-avx-o t-bswap.exe t-bswap.o
>
> Uhm, are you sure this arch and tune options aren't the p
On Jun 21 10:30, Corinna Vinschen wrote:
> On Jun 21 00:39, Jean-Pierre Flori wrote:
> > [...]
> > /bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
> > -march=corei7-avx -mtune=corei7-avx-o t-bswap.exe t-bswap.o
>
> Uhm, are you sure this arch and tune options aren't the pro
On Jun 21 10:05, Arjen Markus wrote:
> Hello,
>
> I have been experiencing problems with building several unrelated
> projects on Cygwin/Windows 7. One of them is GCC 4.8.1, another is a
> project that uses CMake to create the Makefiles. The problems occur
> either during the configuration
> (the
On Jun 21 00:39, Jean-Pierre Flori wrote:
> Dear all,
>
> First thanks a lot for your hard work on the Cygwin project and the
> Cygwin64 project.
>
>
> I've begun to try to build Sage (http://www.sagemath.org) on Cygwin64
> to provide some Windows support without the need of a virtual machine
>
On Jun 21 03:26, Charles Wilson wrote:
> The following statement:
>
> char * tmp_path =
>(char *) cygwin_create_path (CCP_POSIX_TO_WIN_A, newargz[0]);
>
> Results in this error popup (and a coredump), when newargz[0] is
> NULL. Sure, it's a bug in my program to do that...but shouldn't it
> be
Hello,
I have been experiencing problems with building several unrelated
projects on Cygwin/Windows 7. One of them is GCC 4.8.1, another is a
project that uses CMake to create the Makefiles. The problems occur
either during the configuration
(the CMake-based project) or during the make itself (GCC
On Jun 20 22:38, Andrew Schulman wrote:
> > If every maintainer would use cygport, it would allow us to change
> > the build method to one along the lines of most Linux distros.
> > In Linux distros, the maintainer provides only the spec file and
> > the source archive. The actual build fo
On Jun 20 18:56, Jeffrey Altman wrote:
> On 6/20/2013 6:31 PM, Nogin, Aleksey wrote:
> > Jeffrey Altman wrote:
> >
> >>> debug1: SSH2_MSG_SERVICE_REQUEST sent
> >>> debug1: SSH2_MSG_SERVICE_ACCEPT received
> >>> debug1: Authentications that can continue:
> >>> publickey,gssapi-with-mic,password
>
The following statement:
char * tmp_path =
(char *) cygwin_create_path (CCP_POSIX_TO_WIN_A, newargz[0]);
Results in this error popup (and a coredump), when newargz[0] is NULL.
Sure, it's a bug in my program to do that...but shouldn't it be handled
more gracefully? Like...return a NULL, rat
52 matches
Mail list logo