clang++ cannot locate string header, or bits/c++config.h

I’ve uploaded cygcheck.out at https://gist.github.com/tkelman/8892631 This only applies to x86 Cygwin, as the clang package is not (yet?) available in 64-bit Cygwin. Simple testcase: echo "#include " > hello.cpp echo "int main () {};" >> hello.cpp clang++ -v hello.cpp This outputs: clang ver

Re: Unpacking 7z archives on Cygwin64

No. The Cygwin utility for 7z archives is p7zip, but that's one of the packages that hasn't been ported to 64-bit Cygwin yet. What's the best way to contribute to help this along? I just downloaded the p7zip source package and figured out what needs to change to get the cygport file to build cl

Re: Unpacking 7z archives on Cygwin64

> There is an x86_64 assembly version of the same > file included in the source tarball which could be used instead, Which is? May you clarify this point? Sure. There's an Asm directory in the source tree, under which there are x86 and x64 subfolders. They both contain versions of the file 7zCr

Re: Unpacking 7z archives on Cygwin64

Now I have just discovered how! Installing the bsdtar and friends packages. I was sure that there was an alternative to p7zip but don't remember which... It is bsdtar... Thanks, that is useful. I'm trying to work with a build system that assumes p7zip, and is using it to extract from an msi fil

Compiled executables requiring admin rights - different results between MinGW host type

Hi, I'm looking at a very simple 32-line c file, source is available here https://github.com/JuliaLang/julia/blob/master/contrib/stringpatch.c I'm seeing unpredictable results w.r.t. the compiled executable requiring admin rights to run, depending which host compiler is used. Under 32 bit Cyg

Re: Compiled executables requiring admin rights - different results between MinGW host type

You won't believe it, but yes! Welcome to the wonderful world of UAC installer detection!!!1!11 I get the impression you've been frustrated by this one before... See http://msdn.microsoft.com/en-us/library/bb530410.aspx and scroll down to the section called "Installer Detection". I'll wait w

[ANNOUNCEMENT] New in 64-bit: p7zip-9.20.1-1

assembly to compile in 64 bit - New maintainer, minor Cygwin-packaging changes Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from

Re: package update for cygwin CMake

today we are in the situation that 32 bit has cmake-2.8.9-2 64 bit has cmake-2.8.11.2-1 that was not uploaded by Bill if I remember right and the 64bit version surely need at least one patch, that I am aware of. Bill, I would appreciate to see both version at 2.8.12.2. Could you take care or we s

Re: package update for cygwin CMake

When you do so, please be sure to include the patchset: http://sf.net/p/cygwin-ports/cmake These patches are required for a usable cmake on Cygwin. FYI, I updated Yaakov's patches for 3.0.2 here https://github.com/tkelman/cygwin-cmake Although I never got an answer on cygwin-apps for exactly w

[ANNOUNCEMENT] New package: python-docutils-0.12-1

language. See http://docutils.sourceforge.net for more information. Cygwin packaging is identical to what had been available in ports, bumped to the latest upstream version. Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot

[ANNOUNCEMENT] New package: python-jinja2-2.7.3-1

identical to what had been available in ports, bumped to the latest upstream version. Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe

[ANNOUNCEMENT] New package: python-sphinx-1.2.3-1

documents can be written with it too. See http://sphinx-doc.org for more information. Cygwin packaging is identical to what had been available in ports, bumped to the latest upstream version. Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at

Re: Running a program in Cygwin that was compiled in Linux

Thank you for responding. I was thinking my idea was a long-shot. Can you suggest a forum to post the question abt g77 having a cross-compile option? It looks like Cygwin 1.5 comes with the g77 compiler, but I've already built my environment on the 1.7 Cygwin. I'm open to all suggestions. Y

Re: gfortran and lapack problem

I compile it as gfortran MyTest.f90 -o MyTest -llapack -lblas. I don't get any errors (it says "compilation finished"), but the output file doesn't print anything (neither the strings, or the variable info). If I comment the "CALL DGESV" line, it does print everything (with info=0, of course). 3

Re: Tester for openblas needed

before making an official cygwin package for OpenBlas (fast Blas) http://www.openblas.net/ I would like some test from potential users. The dynamic library is multicore, so it should work on "all" processors, but unfortunately I can only test on my dual Core i5-3320M. Neat, I'll give it a try.

Re: Tester for openblas needed

look in the source package http://matzeri.altervista.org/x86_64/openblas/ Thanks. I'm a little surprised the cygblas-0.dll (x86_64, 0.2.12-1) does not appear to be linked to libgfortran. Were you seeing your test executables using multiple cores? I think you may have to build with USE_THREAD=1 t

Re: Tester for openblas needed

openblas is written in C More assembly than C according to github's count. I'm used to building the full version of openblas including their optimized implementations of lapack routines, which bring in libgfortran. So nevermind. USE_THREAD=1 and USE_OPENMP=1, can be used dynamically ; if I am

Re: Tester for openblas needed

I avoided to include lapack as for compatibility I will need to split exactly as netlib in cygblas-0.dll cyglapack-0.dll something for the future. That makes sense, it gets packaged that way in debian and fedora too. I think there's an open issue on openblas' tracker to add a build option to s

Re: Tester for openblas needed

It should determine the number of cores at runtime as well as the level of SSE/AVX support: i686 starts with the PentiumPro, which didn't have SSE. Fixing this at compile time is nice for local builds, but no good for packages. As long as you set DYNAMIC_ARCH=1 (which Marco did), openblas does

Re: Problem with accents

If you are running cygwin in the default mintty console, check the setting of the locale and character set in the mintty settings. On the settings text page, set the Character set to UTF-8 (it may display as UTF-8 (Unicode) in the drop-down. Also set the Locale to the right language and region. Yo

Re: package update for cygwin CMake

The same number of CMake unit tests passed with an unpatched bootstrap straight from the upstream sources, so I didn't get the entire rationale. -Tony PathCygwinToWin32 was using a deprecated cygwin_conv_to_win32 that is not present in x86_64 version of cygwin. I've updated this set of patche

Re: gah! ksp beta died!

These guys are shipping a ~40-month-old version of Cygwin? Humans are such curious creatures… You can never imagine, what would they do next. To make this clearer for Theodore, you should report this back to Squad, the developers of KSP (fun game btw), and tell them they need to update their

Re: Cygwin gcc mingw python development environment configuration

- how to include gcc/mingw options when needed for python setup.py situations The Cygwin-hosted MinGW compilers are set up in a very similar way to cross- compilation from Linux. Python and most of its infrastructure for building C extensions do not support MinGW very well, from any host environ

[ANNOUNCEMENT] Updated: cmake-3.1.2-1

nt of your choice. HOMEPAGE http://www.cmake.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing

mintty needs a patch

I was trying to build mintty from its src package today. As a heads-up for whoever next tries to build the package, I get the following error on either 32 or 64 bit: gcc -c -MMD -MP -DTARGET=x86_64-pc-cygwin -DNDEBUG -std=gnu99 -include std.h -Wall -Wextra -Wundef -Werror -mtune=atom -fomit-fram

Re: rar multipart decompression tool?

7-zip https://cygwin.com/packages/x86/p7zip/ Note that Rar support is under a non-OSI-approved restrictive license, so the Cygwin package for p7zip removes it with a patch. You should be able to use the native Windows command-line 7z.exe for that though. -Tony -- Problem reports: http:

Re: git fails to push

For a long time, I have been suffering from git problems when I push to our server. I have been hoping that it should just magically go away with some update or something, but I guess not. Basically, I have to push several times for it to "take". No idea whether or not this is related to your is

Re: From Microsoft: Windows 10 Console and Cygwin

Public service reminder: "msysgit" is not a MSYS-git. The git program that they ship is, in fact, a full-fledged port of git to W32 (i.e. mingw-git), which is achieved by applying lots of patches (~300KB last time i checked) on top of git. It is, however, bundled with MSYS1, as parts of git are

Re: mintty project

Personally I feel that a platform like sourceforge provides a more professional project environment which would provide more confidence in stable project development. What do you think? Sourceforge is awful. It's incredibly unreliable, on a project I contribute to where we deal with dozens of

Re: mintty project

• Yaakov could turn github/cygwinports into an "organisation account" and give me admin rights for the mintty repository. • I could create a dedicated account and repository. • I could host mintty somewhere else. There is also an inactive "mintty" user on github, you could contact github about n

[ANNOUNCEMENT] Updated: p7zip 9.38.1-1

archives. HOMEPAGE https://sourceforge.net/projects/p7zip and http://www.7-zip.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe

mingw-w64 --enable-fully-dynamic-string

I noticed this from openSUSE just changing this configure option in their mingw-w64 cross-compiler package (https://build.opensuse.org/package/rdiff/windows:mingw:win64/mingw64-gcc?linkrev=base&rev=73). Checking cygwin's `x86_64-w64-mingw-g++ -v` (package version 4.9.2-1) gives me: Using bui

Re: mingw-w64 --enable-fully-dynamic-string

Cygwin's copy contains the mistake. Thanks for the ack. Sorry my mailer is stupid and mis-formatted the very end of my message. I found the opensuse change caused an ABI breakage, C++ executables compiled with cygwin's mingw-w64 started segfaulting when the latest libstdc++-6.dll from opens

Re: mingw-w64 --enable-fully-dynamic-string

If a cygwin package rebuild can make the ABI's compatible again that would be awesome and fix the breakage I've been seeing Thanks JonY for the 4.9.2-2 rebuild. Everything looks to be playing well together again on my end. (I should still investigate some future-proofing of my setup but it's n

Re: [ANNOUNCEMENT] Update: mintty 2.0.3

Changes in mintty 2.0.3: Did this also get uploaded for 32 bit, or are the mirrors just being slow? Thanks, Tony -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: ht

Re: Please upgrade cygwin cmake to 3.3.0

Could you please upgrade cygwin cmake to 3.3.0. Sure, will do (3.3.1 is available so will build that), give me a few days. Just out of curiosity, any specific features introduced since 3.1.2 that you're really wanting to use? -Tony -- Problem reports: http://cygwin.com/problems.html

Re: Please upgrade cygwin cmake to 3.3.0

Sorry for sending the first copy of my earlier message off-list accidentally (I keep doing that). Hi Tony, cmake 3.3.0 has the visual studio generator which is very handy on Windows system. I have tried the separated version on Windows with visual studio 14 generator, and it works well.

[ANNOUNCEMENT] Updated: cmake-3.3.1-1

makefiles and workspaces that can be used in the compiler environment of your choice. HOMEPAGE http://www.cmake.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE

[ANNOUNCEMENT] Updated: cmake-3.3.1-2

makefile generation system, used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. HOMEPAGE http://www.cmake.org Best, Tony Kelman

Re: cmake fails to run/build under Cygwin

It looks as though there is a problem with `execute_process` (and the deprecated `exec_program`). I haven't tried uninstalling the Win32 version of CMake, but it's definitely the CygWin version that is running. Could you try at least taking the win32 cmake off your path? Or as an experiment, run

[ANNOUNCEMENT] Re: Updated: cmake-3.3.2-1

makefile generation system, used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. HOMEPAGE http://www.cmake.org Best, Tony

[ANNOUNCEMENT] Updated: p7zip 15.09-1

p and http://www.7-zip.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the

Re: Octave 4.0.0-3 x86_64 segfault (suspect openblas)

To test without openblas , you can renable netlib blas $ mv /usr/bin/cygblas-0.dll /usr/bin/cygblas-0.dll_bk Yep, works fine with netlib blas. Pure C repro case is attached, gcc -g 5728.c -o 5728 -llapack && gdb ./5728 I can submit upstream, unless you'd like to. -Tony #include #include #i

Re: Octave 4.0.0-3 x86_64 segfault (suspect openblas)

I can submit upstream, unless you'd like to. Reported at https://github.com/xianyi/OpenBLAS/issues/697 if you'd like to follow along (or post anything you may have learned from fixing the debuginfo?). -Tony -- Problem reports: http://cygwin.com/problems.html FAQ: http:

Re: libuv

Lots of project such as node.js or neovim are using libuv (https://github.com/libuv/libuv) which is incompatible with Cygwin. I've spent some time trying to build it, but I get issues with pthread. The first compilation error you'll get will look like "unknown type name 'pthread_barrier_t'" but

Re: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

Yaakov Selkowitz cygwin.com> writes: > These packages provide libraries and tools for cross-compiling a wide > variety of projects for native Windows with the MinGW-w64 toolchains. Ooh. I will totally be using these, this is great to see. So does this mean it's open season for ITP's on mingw-w6

RE: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

> Not MinGW applications, unless they are Cygwin-hosted tools used for > cross-compiling (which I think we have pretty well covered). Not even things like rustc, node.js, or julia which cannot be compiled as cygwin-linked applications (rust might be possible but I don't think anyone has tried rece

RE: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

> Not MinGW applications, unless they are Cygwin-hosted tools used for > cross-compiling (which I think we have pretty well covered). Not even things like rustc, node.js, or julia which cannot be compiled as cygwin-linked applications (rust might be possible but I don't think anyone has tried rece

[ANNOUNCEMENT] [SECURITY] Updated: p7zip 15.09-2

. HOMEPAGE https://sourceforge.net/projects/p7zip and http://www.7-zip.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin

Re: Last Version of Cygwin for XP

Erik Soderquist gmail.com> writes: > currently I'm studying programming myself now with a direct goal of > being able to write a Linux compatible replacement so I can dump my > own amber-coated XP Have you tried running the Windows binaries under Wine? It's worth a shot. Wine has some hefty depe

RE: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

>> LLVM/Clang version bumps are time-consuming to get right. I actually >> looked at 3.6, but MCJIT did not work OOTB with PE/COFF targets. I'll >> have to see what the story is with 3.7. > > Understandable. 3.8 is in RC right now so maybe try building the > release_38 branch if you get to it soon,

Re: [ANNOUNCEMENT] llvm 3.7.1-1

Yaakov Selkowitz cygwin.com> writes: > This is an update to the latest upstream release. This release switches > to the CMake build, which results in many small shared libraries instead > of the single monolothic one from previous releases. Clang is also built > as a separate source package a

RE: Can't link .res file (from windres) using i686-pc-mingw32-g++

> Jim Reisert AD1C wrote: >> I have a 64-bit Cygwin environment. I'm trying to compile a 32-bit >> (target) Windows program using i686-pc-mingw32-g++ >> >> # i686-pc-mingw32-g++ -g -Wall -Iinclude -I../../library/include -c >> -o NPOTAdlg.o NPOTAdlg.cpp >> # windres -Iinclude res/NPOTAdlg.rc -O cof

RE: [ANNOUNCEMENT] Updated: mingw64-*-{headers,runtime,winpthreads}-4.0.5-1 (x86/x86_64)

> I have just updated the mingw-w64 headers, runtime, and winpthreads to > 4.0.5-1. > > mingw64-*-headers-4.0.5-1 > mingw64-*-runtime-4.0.5-1 > mingw64-*-winpthreads-4.0.5-1 Question, since I just had issues building some of LLVM's unit tests and tracked the root cause back to here - is it intenti

RE: [attention p7zip maintainer] p7zip 15.14 is out

> This version syncs code with 7zip 15.14 and adds the fix for CVE-2015-1038. > > Regards, > ismail Updated the version, rebased patches and rebuilt, but cygport isn't letting me upload. I'm getting *** ERROR: Package file p7zip/setup.hint doesn't exist. Run "cygport p7zip-15.14-1.cygport pkg" t

Re: faster opening Cygwin from Explorer window

Nellis, Kenneth xerox.com> writes: > My ideal scenario is to right-click in the Explorer window, select the > new Cygwin option that I'd like to appear, and this would open a > mintty/bash window with PWD set to that Windows folder. > > Long shot, I know, but if anyone has done this and is wil

Re: mingw64-*-{headers,runtime,winpthreads}-4.0.5-1(x86/x86_64)

Tony Kelman kelman.net> writes: > > > I have just updated the mingw-w64 headers, runtime, and winpthreads to > > 4.0.5-1. > > > > mingw64-*-headers-4.0.5-1 > > mingw64-*-runtime-4.0.5-1 > > mingw64-*-winpthreads-4.0.5-1 > > Question, since I ju

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.3.0-1 (x86/x86_64)(Test)

JonY <10walls gmail.com> writes: > I have just updated the mingw-w64 cross compilers Cygwin 32bit and > 64bit to mingw64-*-gcc-5.3.0-1. This is a test version, all the caveats > for gcc-5.3.0 apply. Do you have your cygport packaging in public version control somewhere? Otherwise I'll have to re

Re: [attention p7zip maintainer] p7zip 15.14 is out

Achim Gratz nexgo.de> writes: > You could have renamed the p7zip-15.09-2.cygwin.patch file or you could > remove it and add these three lines to the cygport file: Whoops, thanks, of course I forgot something dumb like that. Will give it another go next time I'm using Windows. Thanks, Tony --

RE: [attention p7zip maintainer] p7zip 15.14 is out

>> Yes but only for development installs. Strictly as a user of the binary >> install I wouldn't want the dependency here. > > We were talking about the cygport file and whether to include a > build-time dependency in there. I also thought the naming for REQUIRES vs DEPEND was a bit confusing unti

[ANNOUNCEMENT] Updated: p7zip 15.14.1-1

://www.7-zip.org Best, Tony Kelman -- 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: native Linux userland in Windows 10

> 2016-04-12 14:50 GMT+02:00 Andrew Schulman is curious: >> >> Has anyone had a chance to try this new feature? Does it work as well as is >> claimed? >> > > I will try ;) > > Here is how to: > > http://blog.dustinkirkland.com/2016/04/howto-ubuntu-on-windows.html > > Gerrit I've been giving it a s

RE: [ANNOUNCEMENT] mingw64-*-fftw3 3.3.4-1

> The following packages have been uploaded to the Cygwin distribution: > > * mingw64-i686-fftw3-3.3.4-1 > * mingw64-x86_64-fftw3-3.3.4-1 Does mingw64-*-pkg-config need to be a runtime dependency of these? -Tony -- Problem reports: http://cygwin.c

make-4.2-1; seeing new "No rule to make target" errors with parallel builds

Marco and anybody else, Has anyone been seeing issues with the latest make version on big parallel compiles? I'm having trouble with LLVM for example, which I've been building every few days or so on older versions of make with no trouble. e.g. curl -LO http://llvm.org/releases/3.7.1/llvm-3.7.1.s

Re: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

Frank Brill samsung.com> writes: > > I am having trouble building an open source project using cmake under Cygwin64 with the latest tools > (setup-x86_64.exe version 2.874). > > I was able to successfully build the project with 32-bit Cygwin with the latest tools: gcc 5.4.0, gnu make > 4.2.1

Re: Problem with git on cygwin64 on Windows 10 (2.8.3-1)

Thomas Nilsson junovagen.se> writes: > Mostly I get 'fatal: unpack-objects failed', but also 'index-pack > failed'. And sometimes just nothing, like an abort without any output, e.g. > > > Thomas thoni64 ~ > > $ git clone https://github.com/thoni56/cgreen.git > > Klonar till "cgreen"... >

Re: Parallelization

Thomas Koenig netcologne.de> writes: > > I am working on a non-linear, boring system of ODEs, boring being > defined as non-stiff and without other numerical surprises. > So, CV_ADAMS works well. > > The only interesting part is that there are very many of the ODEs, > around 3 at the moment

Re: Parallelization

Eliot Moss cs.umass.edu> writes: > True ... it also made me think of Python, which is designed to use > parallelized numpy (etc.) libraries, optimized for your platform. > Can use all the hardware threads on your machine, as well as make > good use of vector extensions such as AVX. A 64-bit (x86

Re: problem building with cmake under cygwin (need clang)

LMH molconn.com> writes: > It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am not sure how > to do that. I don't know if the problem is with the CMakeLists.txt file, the way I am > calling cmake, or with my local cygwin configuration. Are you setting -DCMAKE_CXX_COMPILER=c

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-1 (x86/x86_64) (Testing)

Have you backported the patch for GCC bug 66655 here? I was expecting this to miscompile LLVM and cause test failures when building the Julia language, as I've seen for all other GCC 5.x versions on mingw targets. The fix was https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/winnt.c?r1=232828&

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-1 (x86/x86_64) (Testing)

> Does Julia depend on C++11 features? I'm not familiar with it. How big > is it compared to say, QT? Yes, it does depend on C++11, but mostly by way of linking to LLVM. Julia by itself is not huge, but it depends on a bunch of external library dependencies that are. The most time-consuming of tho

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

> I have just updated the mingw-w64 cross compilers Cygwin 32bit and > 64bit to mingw64-*-gcc-5.4.0-2. I'm regretting only testing on 64 bit in my earlier message. I do see a segfault now when I build Julia with i686-w64-mingw32-gcc 5.4.0-2, that did not occur with 4.9.2-2. Could 4.9.2-2 be reinst

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

> Normally, new versions will first show up for cygwin native gcc before > being handed down to the cross compilers. I'll see about doing a test > version. How long does building the cross-compiler from your cygport take, usually? I could try that and let you know if just applying the patch from h

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

>> How long does building the cross-compiler from your cygport take, usually? >> I could try that and let you know if just applying the patch from >> >> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/winnt.c?r1=232828&r2=232827&pathrev=232828 >> would fix matters. Not sure how many other p

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

> Sadly I seem to get similar-looking access violations even after rebuilding > 5.4.0-2 from the -src cygport with the patch for GCC bug 66655 added. So > maybe some other change is also needed to get this working, hopefully one > that is included in GCC 6. I'll have to test a cross-compilation fro

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

> The -2 build already includes the patch on the 66655 link. Whoops, sorry I missed that, I accidentally downloaded the 5.4.0-1 src package and build from that. Another Julia developer also hit this and we're tracking it at https://github.com/JuliaLang/julia/issues/18123 with a bit more informati

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

>> Now that I got this to happen from an opensuse cross-compile this >> looks like it's a GCC problem rather than specific to what version >> cygwin has packaged, so I'll wait until we find out more. Will you >> see any mingw-labeled bugs on the GCC tracker, or should we >> specifically cc you? >>

[ANNOUNCEMENT] Updated: cmake-3.6.2-1

efile generation system, used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. HOMEPAGE http://www.cmake.org Best, Tony Kelman I

Advice for debugging heap mismatches? (Win10 Insider build 14926)

I've tried manually rebasing, setting rebase-trigger, rerunning latest setup, rebooting, etc. During big parallel makes none of the above helped with getting rid of intermittent heap mismatch errors during fork after I upgraded to Windows 10 Insider build 14926. I had been on the Insider fast ring

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

> I've tried manually rebasing, setting rebase-trigger, rerunning latest > setup, rebooting, etc. During big parallel makes none of the above helped > with getting rid of intermittent heap mismatch errors during fork after I > upgraded to Windows 10 Insider build 14926. I had been on the Insider fa

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

> You're absolutely sure your rebasing operations are being done without > any Cygwin processes running, even background cygserver, sshd, etc? Pretty sure. I don't have any cygwin processes set up to start at login, and I was rebooting several times here. > Could you paste a complete sample of th

Re: CMake "command not found" on Windows Server 2012 R2

> Using the following AppVeyor script, attempting to run cmake returns > “command not found”. If I run “which cmake”, I get “/usr/bin/cmake”, > so it’s there. If I compile cmake manually it works fine (using the > same 3.6.2). As a not, CMake seems to work fine on Windows 10. Can you reproduce th

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

> You've got two different cygwin1.dll somewhere on your PATH. As your builds > proceed, they likely start out using the correct cygwin1.dll but sometimes > load > the wrong cygwin1.dll along the way. The error message tells you how to solve > the problem. But I usually use this method: >

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

> You've got two different cygwin1.dll somewhere on your PATH. For more information, I have one cygwin64 installation on C:, one cygwin32 installation on E:, and they're never both on my path at the same time. I'm not sure where that orphan registry entry that was showing up in cygcheck.out came f

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

>> Still a problem in 14936. Folks, this could be very bad. Anyone at all >> testing the insider builds, or are we going to be blindsided when an >> update goes out to everyone that breaks cygwin? > > How about you start with a sane PATH that doesn#t contain all the > Windows stuff?  Set a system v

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

> No, that looks like I'd expect it to. You need to look at the process > map when you have fork problems, since the problem seems to be > intermittent. How so? Something like for i in `seq 1000`; do cat /proc/self/maps > procselfmaps_`date +%s.%N`.txt; done & before running the problematic c

Re: Random "child_info_fork::abort:"

>  2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error - > cygheap base mismatch detected - 0x1802FC408/0x110C408. As far as I can tell, build 14946 fixed whatever the problem was. Crisis averted, for now. -Tony -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: [ANNOUNCEMENT] Updated: mingw64-{i686,x86_64}-gcc-5.4.0-3 (x86/x86_64)

> I have just updated the mingw-w64 cross compilers Cygwin 32bit and > 64bit to mingw64-{i686,x86_64}-gcc-5.4.0-3. Hi Jon, What will be left as prev? 5.4.0-2, or the last 4.9 build? Can you help raise https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333? The interprocedural analysis that was added

Re: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

> Do you have a small test case for this instead of running the entire > test suite? I'm not sure how much time the full test suite takes. Don't have a small test case, but I do have a big one. I've been verifying that the patch helps in cross-compiles from opensuse where it's a lot faster to buil

Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

> The big question remains, where this speed boost coming from? > Is this a startup time? Or some internal slowness? > Because in latter case, given your STC, this is a bash issue and should be > reported upstream. Dunno what you meant by STC, but upstream is well aware: $ man bash | tail -n 21 |

tar 1.29 regression, duplicating files with -T and --no-recursion

Test case: Tony@LAPTOP-O230JCFF ~ $ tar --version tar (GNU tar) 1.29 Packaged by Cygwin (1.29-1) Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. Ther

Re: tar 1.29 regression, duplicating files with -T and --no-recursion

> $ tar -czf test.tar.gz -T tartest/filelist.txt --no-recursion Looks like this was an intentional change: http://lists.gnu.org/archive/html/bug-tar/2016-05/msg8.html --no-recursion is apparently positional, so the fact that this worked before http://git.savannah.gnu.org/cgit/tar.git/commit/?

Re: [ANNOUNCEMENT] Updated: setup (2.895)

> - Drag setup into the 1990s, by replacing the custom-drawn package > chooser with a ListView common control. > > -- Use standard UI elements to choose an action to take on a package or > category, rather than the weird UX of clicking to cycle around a list of > options of undisclosed length. > >

Re: How to build a DLL without cygwin DLL dependencies

> I am trying to build the latest sqlite windows DLL, and I am > succeeding, but I am getting an error that cygwin1.dll is missing, > when I am trying to use the DLL from outside cygwin in the Windows > environment.  I am using, > > gcc -shared sqlite3.c -o sqlite3.dll > > to build it, but this com

Re: How to build a DLL without cygwin DLL dependencies

> So, I downloaded "i686-w64-mingw32-gcc" from the setup packages and ran, > i686-w64-mingw32-gcc -shared sqlite3.c -o sqlite3.dll, > but it still wants me to add other DLLs.  I just want to drop the > sqlite3.dll just created in another spot and run a tool using that > without need of any other DL

Re: [ANNOUNCEMENT] Test: cmake-3.13.1-1

lures but that would surprise me a little. Running the executables manually or outside of cygwin/ctest can sometimes give more useful output on problems like that (from windows popups, etc). From: Marco Atzeri Sent: Thursday, January 10, 2019 5:49 AM To: Tony Kelman; Ivan Shynkarenka Subject: Re: refresh

Re: GitForWindows vs. Cygwin

>> Can anyone enlighten me about the relationship of "Git for Windows" to >> Cygwin? > > They are not related. Yes, they are. >> But now I hear of this GitForWindows thing.  Which seems to have replaced >> MSysGit, with a GUI thrown in.  But is it _still_ a stale fork of Cygwin, or >> a >> fork

Re: GitForWindows vs. Cygwin

>> Can anyone enlighten me about the relationship of "Git for Windows" to >> Cygwin? > They are not related. Yes, they are. >>> No they're not. >> Tony explained well how they are related; Git for Windows is compiled in and >> packaged with MSYS2 which is forked from Cygwin. > >

Re: GitForWindows vs. Cygwin

>> No, Tony explained how it's related to MSYS2. This isn't a MSYS2 mailing >> list. > > Don't think they have one. Whoops, yes they do https://sourceforge.net/p/msys2/mailman/msys2-users/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Doc