On 2013-07-22 19:52, Kenneth Wolcott wrote:
Postinstall errors:
Thanks for the feedback; remarks inline.
Package: bash
bash.sh exit code 1
I think the problem is that virtual /dev is a read-only filesystem, but
if you make a real /dev directory; then you can write to it. Could you
r
Kris Thielemans writes:
> I'm using gdb-7.6.50-2 on cygwin 1.7.22-1. All freshly updated today.
>
> Further investigation shows that
> - this file exists in cygwin as /usr/include/tcl8.5/generic/tclInt.h
> - /usr/lib/tclConfig.sh sets TCL_INCLUDE_SPEC='-I/usr/include'
> - there is no /usr/includ
Hi;
I think 64bit Cygwin is awesome :-)
FYI: trivial postinstall errors:
Downloaded setup-x86_64.exe from cygwin.com
Selected c:\cygwin64 as install point
Selected c:\cygwin64\download as download location
Requested Install from Internet
Postinstall errors:
Package: bash
bash.sh exit code
Ryan Johnson writes:
>
> On 09/01/2013 1:57 AM, Jose Munoz wrote:
> > I tried to build the original gdb sources, which I
> > downloaded using setup.exe and selecting them.
> >
> > Without modifying any source code of gdb, I run ./configure from my
> > source folder:
> >
> > C:\cygwin\usr\src\gd
I'm trying to compile the following basic program on cygwin64:
int main() {
;
return 0;
}
But I get the following errors:
$ gcc test.c
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-c
No, it's STATUS_ACCESS_DENIED, a permission problem. This could
happen, for instance, if the executable or one of the required DLLs
is not executable.
Corinna
Ah, yes, there is a zlib dll shipped with the source that didn't have
executable perms.
I'll let the TCL people know.
Thanks!
Jon
On Mon, Jul 22, 2013 at 3:04 PM, Larry Hall (Cygwin) wrote:
> Are you sure you don't need to reboot? If cygwin1.dll was in use while
> you were installing and you didn't free it up, a reboot will be necessary
> before you see the new cygwin1.dll.
Yes, the reboot fixed it. I've updated my Cygwin
On 7/22/2013 6:00 PM, Balaji Venkataraman wrote:
I downloaded the latest version of setup-x86.exe (and
setup-x86_64.exe) and updated both my Cygwin installs. The 64bit
version seems to be okay but on 32b Cygwin, I notice a discrepancy in
the dll version number between uname and cygcheck.
$ uname
I downloaded the latest version of setup-x86.exe (and
setup-x86_64.exe) and updated both my Cygwin installs. The 64bit
version seems to be okay but on 32b Cygwin, I notice a discrepancy in
the dll version number between uname and cygcheck.
$ uname -a
CYGWIN_NT-6.1-WOW64 [EDITED] 1.7.21(0.267/5/3)
On 07/22/2013 05:38 PM, Yaakov (Cygwin/X) wrote:
On 2013-07-23 16:26, Ryan Johnson wrote:
If I select the gcc-4.8.1-1 package from setup-64, it downloads and
installs the gcc-4.8.1-src package
gcc is only a source-only meta-package; you want to install gcc-core,
gcc-g++, etc.
Oh, that's a lit
On 2013-07-23 14:53, Ryan Johnson wrote:
Hi mercurial manager,
That would be Jari, who hasn't been around recently and hence hasn't
started on x86_64 packages yet.
Is an official 64-bit mercurial coming soon? Meanwhile, is there any
reason I shouldn't expect a wget/configure/make cycle to "
On 2013-07-23 16:26, Ryan Johnson wrote:
If I select the gcc-4.8.1-1 package from setup-64, it downloads and
installs the gcc-4.8.1-src package
gcc is only a source-only meta-package; you want to install gcc-core,
gcc-g++, etc.
Yaakov
--
Problem reports: http://cygwin.com/problems.
Hi all,
If I select the gcc-4.8.1-1 package from setup-64, it downloads and
installs the gcc-4.8.1-src package, which AFAICT includes a tarball of
the gcc sources, a patch, and a cygport file:
$ for f in $(find /usr -name '*gcc*'); do echo "$f: $(cygcheck -f $f)"; done
/usr/src/4.8-libgcc-cy
Are you still looking for job? Email back at ...alicia.rooney1...@gmail.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
On Jul 22 11:17, Eric Blake wrote:
> On 07/22/2013 02:12 AM, Corinna Vinschen wrote:
>
> >>> However, please note that this behaviour, while being provided by glibc
> >>> and now by Cygwin, is *not* standards-compliant. In the narrow sense
> >>> the characters beyond 0x7f are still invalid ASCII
Hi mercurial manager,
Is an official 64-bit mercurial coming soon? Meanwhile, is there any
reason I shouldn't expect a wget/configure/make cycle to "just work" ?
Thanks!
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation
On 07/22/2013 03:27 PM, Christopher Faylor wrote:
On Tue, Jul 23, 2013 at 03:10:51PM -0400, Ryan Johnson wrote:
I tried to install 64-bit cygwin today, but I keep encountering the
error message "setup-x86_64.exe is not a valid Win32 application."
Sorry about that. This problem is fixed.
Works
On Mon, Jul 22, 2013 at 12:19:18PM -0700, Darik Horn wrote:
>On Tue, Jul 23, 2013 at 12:10 PM, Ryan Johnson
> wrote:
>>
>> I tried to install 64-bit cygwin today, but I keep encountering the error
>> message "setup-x86_64.exe is not a valid Win32 application."
>
>I had the same problem today on Win
On Tue, Jul 23, 2013 at 03:10:51PM -0400, Ryan Johnson wrote:
>I tried to install 64-bit cygwin today, but I keep encountering the
>error message "setup-x86_64.exe is not a valid Win32 application."
Sorry about that. This problem is fixed.
--
Problem reports: http://cygwin.com/problems.ht
On Tue, Jul 23, 2013 at 12:10 PM, Ryan Johnson
wrote:
>
> I tried to install 64-bit cygwin today, but I keep encountering the error
> message "setup-x86_64.exe is not a valid Win32 application."
I had the same problem today on Windows 8. The solution was to
download the 64-bit setup program from
Hi all,
I tried to install 64-bit cygwin today, but I keep encountering the
error message "setup-x86_64.exe is not a valid Win32 application." I
found another message that said to clear IE's file cache and try again,
but that didn't help. Plus, downloading the executable with the wget
from 32
On 07/22/2013 02:12 AM, Corinna Vinschen wrote:
>>> However, please note that this behaviour, while being provided by glibc
>>> and now by Cygwin, is *not* standards-compliant. In the narrow sense
>>> the characters beyond 0x7f are still invalid ASCII chars, and other
>>> functions working with w
I wanted to have roughly the same packages available in my 64-bit
version of Cygwin as for my 32-bit version so, this is what I did:
1) Decide that the root of the 64-bit version would be c:\cygwin64.
2) mkdir -p /cygdrive/c/cygwin64/etc
3) sed 's/-[0-9][0-9.a-z]*-[0-9]*.tar.bz2/-0.0.0-0.tar.bz2
Hi Cygwin friends and users,
I just released Cygwin 1.7.22.
===
INTRODUCING A 64 BIT RELEASE
===
This is the first official Cygwin release whic
We have updated the setup.exe executables on cygwin.com in preparation
for the upcoming release of Cygwin 1.7.22.
There are now two versions of setup. setup-x86.exe will install and
update the 32-bit version of Cygwin. setup-x86_64.exe will install and
update the 64-bit version of Cygwin.
Altho
On Jul 22 09:19, Charles Wilson wrote:
> On 7/21/2013 1:08 AM, Jonathan Kelly wrote:
> >>On Jul 20 08:08, Jonathan Kelly wrote:
> >>>Not. Comes up with error "The application was unable to start
> >>>correctly (0xc022).
>
> >No, it's not - it compiles and runs as it should when I use the Mingw
On 7/21/2013 1:08 AM, Jonathan Kelly wrote:
On Jul 20 08:08, Jonathan Kelly wrote:
Not. Comes up with error "The application was unable to start
correctly (0xc022).
No, it's not - it compiles and runs as it should when I use the Mingw
directly. It's what I'm using now. I was just trying t
Version 3.0b_svn5935-2 of "mingw64-i686-runtime" and
"mingw64-x86_64-runtime" has been uploaded.
The only change from the -1 release is the addition of the -headers
package as dependency that was accidentally omitted in the last release.
mingw64-* gcc should install correctly again for fresh inst
Hello!
I have successfully tested it on i386. Really, just remove PREFIX
completely and it's okay. GetProcAddress() appears to be "clever" and adds
the leading underscope by itself on i386. I don't know what you did wrong
and why you could not reproduce the solution.
However, i have one idea. Af
Snapshot tried successfully.. Magic!
--
View this message in context:
http://cygwin.1069669.n5.nabble.com/gcc-Is-the-C-function-select-thread-safe-tp100994p101050.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Jul 21 22:59, Mark Levedahl wrote:
> On 07/21/2013 03:39 PM, Corinna Vinschen wrote:
>
> >So, what I did now was this: I added a workaround to Cygwin's regcomp.
> >If the current codeset is ASCII, the characters in the pattern are
> >converted to wchar_t by simply using their unsigned value ve
On Jul 20 19:30, Daniel Brown wrote:
> Hi,
>
> So I have some code I am trying to port to Cygwin but I am getting the
> error:
>
> fatal error in forked process - failed to create new win32 semaphore,
> Win32 error 87
>
> when calling fork() in a C program when openmp code has been used
> before
Hello!
> So at this point your patch doesn't work in x86 for me. I'd appreciate
> it if someone else could test it, or suggest a modification to make it
> work.
Ok, i'll test it myself.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
Problem reports:
33 matches
Mail list logo
