Re: [ANNOUNCEMENT] Updated: setup (2.895)

[Tony Kelman]

> - 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.
>
> -- Behaviour change: previously, a category action only affected 
> packages which matched any name search filter applied.  Now all packages 
> contained by the category are affected.

I noticed a behavior change that felt like a regression to me, could you
clarify whether or not it falls under the intended new behavior?

With previous versions of setup you could use the category view and select
"Install" for the "All" category and get a (slightly crazy, not-recommended)
conflict-free package resolution to install.

With 2.895, now the selection for the "All" package applies even to the
default-hidden "_obsolete" category, resulting in over 100 conflicts
between obsolete packages and their successors. Should selections on the
"All" category follow the setting of the "Hide obsolete packages" checkbox?

I'm not sure if this is how older setup versions worked, but it might make
sense to not propagate selections from "All" to the "_obsolete" category
when that checkbox is enabled.

Thanks,
Tony

--
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: How to build a DLL without cygwin DLL dependencies

[Tony Kelman]

> 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 command creates a dependency for cygwin1.dll.
> Is there any way to build the dll as a standalone DLL with no
> dependency?  Thanks.

Yep, you want the mingw-w64 cross compiler, x86_64-w64-mingw32-gcc
(or i686-w64-mingw32-gcc for 32 bit). There's a cross-compiled sqlite
package already available under mingw64-x86_64-sqlite3 in setup - or
http://mirrors.kernel.org/sourceware/cygwin/noarch/release/mingw64-x86_64-sqlite3/mingw64-x86_64-sqlite3-3.19.3-1.tar.xz
if you're okay with that particular release.

--
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: How to build a DLL without cygwin DLL dependencies

[Tony Kelman]

> 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 DLL. I know I can do it with MinGW, but I
> don't want to install two systems on my computer.  I know I am missing
> something because I know other folks have done it before.
> I duckduckgo'ed some answers, but have not found anything but
> "use MinGW".  Is this even possible with cygwin and its packages?

You just did "use MinGW with cygwin and its packages." MinGW is the
compiler triple you just used via a cross compiler. The end user
system won't need cygwin, and it won't need a compiler. Would be good
if you were more specific about what "it" you're referring to and which
"other DLLs" you mean. I just tried what you described:

curl -L https://www.sqlite.org/2019/sqlite-autoconf-328.tar.gz | tar -xz
cd sqlite-autoconf-328
i686-w64-mingw32-gcc -shared sqlite3.c -o sqlite3.dll

and dependency walker is telling me there are a few dependencies on
libgcc_s_sjlj-1.dll for __divdi3 etc. That's a compiler runtime dll
and you can avoid the issue by building a 64 bit dll, or in 32 bit via

i686-w64-mingw32-gcc -shared -static-libgcc sqlite3.c -o sqlite3.dll

--
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: [ANNOUNCEMENT] Test: cmake-3.13.1-1

[Tony Kelman]

See below what I said in both January and November the last times we had any 
conversation on this. cmake_minimum_required, project_injected, and CommandLine 
test failures are new and I'd personally come to a definitive thoroughly 
researched conclusion on what's causing them before making a release. But I 
don't intend on making any releases of cygwin packages any time soon, so you 
can do whatever you want here.


 top-posting because these conversations were off list:


Right, if the logs aren't super useful for debugging, then the next step I'd do 
is what I said in November:

> What happens if you run the steps those tests are trying to execute on their 
> own, not under ctest? Or try to run the unit tests with an existing older 
> separate copy of ctest instead of the just-built copy?

The Qt*Autogen failures were pre-existing and I've identified the cause in past 
versions, I should have made a note of it in writing somewhere more permanent 
though. The build system there isn't handling dll dependencies of the test 
executables quite correctly for cygwin. That's definitely a bug in how the test 
is written and could eventually be resolved with a cygwin-specific patch to 
those cmake tests by whoever ever has the time to work through it. The new ones 
are what I was referring to and could be indicative of real problems. It's 
possible some of them are due to missing dll issues like the Qt*Autogen 
failures 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: refreshing cmake
 
Am 1/9/2019 um 7:28 AM schrieb Tony Kelman:
> I still think the test failures should be looked into and debugged, 
> personally.

Tony,
to me it seems a case of best is enemy of good.

I look at the test log and I do not see what is the problem
so I am not able to debug.
Do you have some guidance ?

-

 Start 359: RunCMake.cmake_minimum_required
359/561 Test #359: RunCMake.cmake_minimum_required 
..***Failed


$ find . -name CMakeOutput.log -exec cat {} \;
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64

there is nothing more.

---

 Start 391: RunCMake.project_injected
391/561 Test #391: RunCMake.project_injected 
***Failed

the single log is very long but I do not see a single error.



 Start 422: RunCMake.CommandLine
422/561 Test #422: RunCMake.CommandLine 
.***Failed

the single log is very long but I do not see a single error.



 Start 454: Qt5Autogen.Complex
454/561 Test #454: Qt5Autogen.Complex 
...***Failed

the single log shows no error.
There is just an isolated warning

all the targets seem built

$ find . -name "*.a" -or -name "*.dll" -or -name "*.exe"
./Adir/cyglibA.dll
./Adir/liblibA.dll.a
./Bdir/cyglibB.dll
./Bdir/liblibB.dll.a
./CMakeFiles/3.13.1/CompilerIdC/a.exe
./CMakeFiles/3.13.1/CompilerIdCXX/a.exe
./cyglibC.dll
./libcodeeditorLib.a
./liblibC.dll.a
./QtAutogen.exe
./targetObjectsTest.exe

$ PATH=$(PWD)/Adir:$(PWD)/Bdir:$PATH ./QtAutogen
Hello automoc: 12
Blub blub 13 !
Hello bar !
abc
I am private abc !
This is xyz !
I am yet another file !

just ./targetObjectsTest.exe produces no output at all
so I have no clue of what is supposed to do.

--

 Start 487: Qt4Autogen.Complex
487/561 Test #487: Qt4Autogen.Complex 
...***Failed

same a QT5


--
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] New in 64-bit: p7zip-9.20.1-1

[Tony Kelman]

Version 9.20.1-1 of p7zip has been uploaded to the 64-bit distribution.
This is the first release of p7zip for x86_64.

p7zip is the Unix port of 7-Zip, a file archiver that archives with
very high compression ratios.  It supports packing/unpacking 7z, zip, gzip
bzip2, xz, tar, and wim archives.  It supports unpacking of arj, cab, chm,
cpio, dmg, hfs, lzh, lzma, wim, xar, z, nsis, deb, rpm, msi, udf, iso, ntfs,
fat, vhd, and mbr archives.  This version does NOT support rar archives.

Changes relative to the existing 32-bit package:
- Using a C version of a CRC checksum routine instead of 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 the cygwin-announce mailing list, look
at 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@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.

--
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: package update for cygwin CMake

[Tony Kelman]

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 should consider the package orphan ?


Bump. Any update from the cmake maintainer? Upstream is at 3.0.2 now.

I'm looking at the cygport and its patches for the 64 bit package.
I think that package was NMU'd by Yaakov last year? One of the patches
is ruby-related, another perl-related, and the last has to do with
case-sensitivity and path handling. If I don't hear anything I'll
have a look at whether they still apply cleanly to latest upstream
sources and see how building goes.

-Tony


--
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: package update for cygwin CMake

[Tony Kelman]

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 why they were
needed, especially the case-sensitivity and path handling *-cygwin.patch
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



--
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] New package: python-docutils-0.12-1

[Tony Kelman]

Version 0.12-1 of python-docutils has been uploaded.

Docutils is an open-source text processing system for processing
plaintext documentation into useful formats, such as HTML or
LaTeX. It includes reStructuredText, the easy to read, easy to
use, what-you-see-is-what-you-get plaintext markup 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) com .

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at 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@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.

--
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] New package: python-jinja2-2.7.3-1

[Tony Kelman]

Version 2.7.3-1 of python-jinja2 has been uploaded.

Jinja2 is a template engine written in pure Python.
It provides a Django inspired non-XML syntax but supports
inline expressions and an optional sandboxed environment.

See http://jinja.pocoo.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) cygwin (dot) com .

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at 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@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.

--
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] New package: python-sphinx-1.2.3-1

[Tony Kelman]

Version 1.2.3-1 of python-sphinx has been uploaded.

Sphinx is a tool that makes it easy to create intelligent and beautiful
documentation. It was originally created to translate the new Python
documentation, and it has excellent support for the documentation of
Python projects, but other 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) cygwin (dot) com .

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at 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@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.

--
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: Running a program in Cygwin that was compiled in Linux

[Tony Kelman]

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.


You may want to have a look into MinGW.org's legacy version of g77.
http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version3/Current%20Release_%20gcc-3.4.5-20060117-3/

You could also look at http://netlib.org/f2c/ but I would try MinGW first.

-Tony


--
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: gfortran and lapack problem

[Tony Kelman]

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


32 bit or 64 bit Cygwin? Works for me, I get

$ gfortran MyTest.f90 -o MyTest -llapack -lblas

$ ./MyTest
Printing the results
  0
End printing

So no "compilation finished" message. Might you have some other
version of gfortran on your path? I believe cygcheck.out would
list some of this information. Other things to check:

which -a gfortran
which -a cygblas-0.dll


--
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: Tester for openblas needed

[Tony Kelman]

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. Do you have a cygport file you're working on
that I could look at? I build OpenBLAS quite regularly, though almost
always as a MinGW cross-compile, for use with Julia (www.julialang.org
if you're not familiar).

-Tony


--
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: Tester for openblas needed

[Tony Kelman]

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 to enable threading (or USE_OPENMP=1 for openmp)?

I may be doing this wrong, but I'm getting errors from your openblas
build, but not the reference blas package, when I run the following:

$ curl -O 
https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.f

$ gfortran -o sblat2 sblat2.f -lblas
$ rm -f SBLAT2.SUMM
$ curl 
https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.dat | 
./sblat2


This outputs messages like:
** On entry to SGEMV  parameter number  1 had an illegal value
and so on for the other single-precision level 2 functions in that test.

This does seem to work okay on Linux or an existing i686-w64-mingw32 build.

-Tony


--
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: Tester for openblas needed

[Tony Kelman]

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 not wrong.


What does your Makefile.conf say for NUM_CORES? I can't seem to get a
test program with your build to use more than 2 cores (I have 4 + HT)
by setting the OPENBLAS_NUM_THREADS environment variable.

-Tony


--
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: Tester for openblas needed

[Tony Kelman]

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 split up the shared library that way, make packagers' lives easier.

Even netlib lapack will run faster with a better blas plugged in, so the
way you're doing it now with just the blas parts makes sense to start with.


So how many THREADS would you like to see ?


I think 8 would cover the majority of users, 16 at the most. I've seen
cases where openblas can try to use threads on small problems where it
shouldn't need to, so it would be good to check whether it's smart about
avoiding oversubscription if you run it without setting 
OPENBLAS_NUM_THREADS.

Of course users who really want more threads can compile it themselves,
but it'll be convenient to have a fast blas easily hooked into Cygwin's
packages for numpy, R, octave, etc.

-Tony


--
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: Tester for openblas needed

[Tony Kelman]

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
exactly this when it comes to SIMD instruction sets (and more details
like tuning for different cache sizes, etc). They have optimized routines
for this list of processor families:
https://github.com/xianyi/OpenBLAS/blob/ac5a7e1c1bb75d1accfb83c394e1535b5ff170d2/driver/others/dynamic.c#L296-L318
the right implementation gets used based on runtime detection, which is
why the compiled dll is much larger than reference netlib blas.

Hopefully the number of threads you set at build time is just a maximum.
The library is explicitly designed so you can control the number of
threads used at runtime. What we're not sure about is what happens in
the default case when you don't manually set the number of threads.

-Tony


--
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: Problem with accents

[Tony Kelman]

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. You will have at least C in the drop-down, plus
any others from your windows regional configuration.


You may also want/need to change the display font in mintty. I've found
DejaVu Sans Mono has better Unicode support than the default font.

-Tony


--
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: package update for cygwin CMake

[Tony Kelman]

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 patches for cmake 3.1.0-rc2 (I can post the builds
if anyone would like to test them) at 
https://github.com/tkelman/cygwin-cmake

As with 3.0.2, there is no difference in the number of CMake's self-tests
that fail with unpatched sources from upstream vs applying Yaakov's set of
patches (with my updates so they apply to the latest version). I don't
see anything using cygwin_conv_to_win32 in 3.x, there are some uses of
cygwin_conv_path which are disabled by Yaakov's patches however.

I'm still willing to adopt the package, it appears Bill has been too busy
to upload a more recent version over the past 6 weeks.

Yaakov (or anyone else), is there any way you can provide test cases
that would fail without applying each of these patches? I can pursue
adding such cases to CMake's test suite and working to get the patches
incorporated upstream.

Thanks,
Tony


--
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: gah! ksp beta died!

[Tony Kelman]

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 patcher to use a newer version of Cygwin.

-Tony


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

Re: Cygwin gcc mingw python development environment configuration

[Tony Kelman]

- 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 environment.
They generally don't even support Posix-to-Posix cross-compilation very
well either.

For example, if compiling Cython, which uses python setup.py, which in 
turn
calls gcc using a select build environment - how can I configure this to 
use
mingw, if this is required, instead of Cygwin gcc? How to configure paths 
or

select gcc parameters?


You can attempt to use the cross-compilers, either i686-w64-mingw32-gcc to
create 32 bit binaries, or x86_64-w64-mingw32-gcc for 64 bit binaries.
This might not work too well, depending how many ingrained assumptions are
buried in Cython and all of its supporting tools that treat build and host
as the same thing, expecting properties of the build-system's Python to be
the same as the host system's Python.


The choices are either an intrinsic Cygwin gcc build environment, or a
Cygwin mingw based one. This provides for Cygwin and Windows dependent
platform targets.


In terms of building Python C extensions, building in Cygwin should work
fairly well for the Cygwin-hosted, POSIX-style Python. The conventional
Win32 MSVC-built Python is a different beast, and the two don't always
play well together. MinGW, which is GCC for Win32, works great for
compiling a pretty wide array of libraries. But much of the Python
ecosystem tends to treat it as a marginal, unsupported platform.


I want to work from mintty, as opposed to using a separate C:\MingGW MSYS
build environment. (Especially because I use python and other tools 
directly

from Cygwin/mintty)


You might want to look at MSYS2. It is a relatively recent, up-to-date fork
of Cygwin, using mintty and an up-to-date MinGW-w64 toolchain, but set up
like the legacy MSYS1 so that most builds do not look like a conventional
cross-compilation. This is the Cygwin mailing list not the MSYS2 list, and
I believe there's still some disagreement over the need to fork Cygwin vs
contributing to and improving it. But they do have an experimental build of
Python using MinGW (heavily patched) that you may find useful to try out.

-Tony


--
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: cmake-3.1.2-1

[Tony Kelman]

Let's try this again...

Version 3.1.2-1 of packages
 cmake
 cmake-gui
 cmake-doc
 cmake-debuginfo
 emacs-cmake
are available in the Cygwin distribution.

CHANGES
This is the first update of the package in some time, upgrading from
2.8.9 in the 32 bit distribution and 2.8.11.2 in 64 bit. Some changes:

- The 3.0.0 release introduced new backwards-incompatible bracket
 syntax, see http://www.cmake.org/cmake/help/v3.1/release/3.0.0.html
 for details.
- The 3.1.0 release introduced support for lzma compressed archives with
 .tar.xz, .txz, and .7z extensions, and a number of other features, see
 http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html
- Bugfix releases 3.1.1, see http://www.kitware.com/blog/home/post/828,
 and 3.1.2, see http://www.kitware.com/blog/home/post/839
- CMake html documentation is now built by Sphinx and split into a
 separate cmake-doc package.
- New maintainer for Cygwin package.

DESCRIPTION
CMake is a cross-platform 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


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 "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@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.

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

mintty needs a patch

[Tony Kelman]

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-frame-pointer -O2 
wintext.c
windres --preprocessor 
'gcc -E -xc -DRC_INVOKED -MMD -MP -DTARGET=x86_64-pc-cygwin -DNDEBUG' res.rc 
res.o

wintext.c: In function ‘win_text’:
wintext.c:522:13: error: array subscript is above array bounds 
[-Werror=array-bounds]

  if (!fonts[nfont]) {
^
cc1: all warnings being treated as errors
Makefile:117: recipe for target 'wintext.o' failed
make: *** [wintext.o] Error 1


This can at least be made into a warning by taking off -Werror, but it looks
like it might be a real off-by-one. Our neighbors over at MSYS2 have a patch
https://github.com/Alexpux/MSYS2-packages/blob/master/mintty/01-array-bounds.patch
(the packaging repo there has a BSD 3-clause license) to change FONT_MAXNO
in wintext.c from 0x1F to 0x20.

-Tony


--
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: rar multipart decompression tool?

[Tony Kelman]

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://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git fails to push

[Tony Kelman]

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 issue, but I run into pretty 
frequent fork failures from cygwin git that can at least be worked around by 
setting


alias git="env PATH=/usr/bin git"

in my .bashrc.

-Tony


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

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

[Tony Kelman]

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 version 3.1 (branches/release_31)
Target: i386-pc-cygwin
Thread model: posix
"/usr/bin/clang" -cc1 -triple 
i386-pc-cygwin -S -disable-free -disable-llvm-verifier -main-file-name 
hello.cpp -mrelocation-model 
static -mdisable-fp-elim -mconstructor-aliases -target-cpu 
pentium4 -target-linker-version 
2.22.52.20120326 -momit-leaf-frame-pointer -v -resource-dir 
/usr/bin/../lib/clang/3.1 -fmodule-cache-path 
/var/tmp/clang-module-cache -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir 
/cygdrive/d/cygwin64/home/Tony/8875125 -ferror-limit 19 -fmessage-length 
100 -mstackrealign -fno-use-cxa-atexit -fgnu-runtime -fobjc-runtime-has-arc  
-fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option 
-fcolor-diagnostics -o /tmp/hello-108VBJ.s -x c++ hello.cpp

clang -cc1 version 3.1 based upon LLVM 3.1 default target i386-pc-cygwin
ignoring nonexistent directory 
"/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++"
ignoring nonexistent directory 
"/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin"
ignoring nonexistent directory 
"/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/backward"

ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.5.3/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/bin/../lib/clang/3.1/include
/usr/include
/usr/include/w32api
End of search list.
hello.cpp:1:10: fatal error: 'string' file not found
#include 
^
1 error generated.


Looks like clang was built with hardcoded GCC 4.5.3 header paths. I'm at GCC 
4.7.3 now.


A successful workaround is to add GCC 4.7.3 header paths to the compiler 
call:

clang++ -I/usr/lib/gcc/i686-pc-cygwin/4.7.3/include/c++ \
 -I/usr/lib/gcc/i686-pc-cygwin/4.7.3/include/c++/i686-pc-cygwin hello.cpp

Or by adding a symbolic link from /usr/lib/gcc/i686-pc-cygwin/4.5.3 to 
/usr/lib/gcc/i686-pc-cygwin/4.7.3.


I hope this inconvenience can be fixed with a future update to the clang 
package.


Thanks,
Tony


--
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: Unpacking 7z archives on Cygwin64

[Tony Kelman]

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 cleanly in 64-bit Cygwin:

1. One of the patches doesn't apply correctly because a man file,
man1/7zr.1, has the wrong line endings. Running dos2unix on that
man file and re-packing the source tarball fixed that.

2. In src_compile() in the cygport file, the line

   cp makefile.cygwin_asm makefile.machine

is resulting in an x86 assembly file getting pulled in, which fails to
link in 64-bit Cygwin. There is an x86_64 assembly version of the same
file included in the source tarball which could be used instead, but the
easier patch is to instead use a C version of the file. There may be some
performance penalty here, but it's a one-liner patch to the cygport file:

   [ `arch` = x86_64 ] && cp makefile.cygwin makefile.machine

added after the previous "cp" line.

Can anyone offer guidance for how to proceed in creating a 64-bit version
of this package now that I've pointed out what needs to be fixed?

Thanks,
Tony


--
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: Unpacking 7z archives on Cygwin64

[Tony Kelman]

> 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
7zCrcT8U.asm. I don't know assembly and I'm not familiar enough
with the details of p7zip to know for sure, but I'm guessing these
should do the same thing.

It should be possible to patch makefile.cygwin_asm to use the x64
assembly file instead, it would just be a bit more invasive of a patch.
The p7zip-9.20.1-1.src.patch file already has a section that touches
makefile.cygwin_asm that I could expand upon to do this.

I didn't understand the relationship between the numbered patches listed
in the PATCH_URI section of the .cygport file, and the .src.patch and
.cygwin.patch files, but I at least see the order in which they are
applied now.

Do 32-bit and 64-bit packages use the same build instructions, or would
the 64-bit package be separate? I can add in makefile conditionals to
make the same patch work for both, or use a simpler patch targeting
64-bit specifically.

-Tony


--
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: Unpacking 7z archives on Cygwin64

[Tony Kelman]

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 file. bsdtar is
not working as a drop-in replacement for this, and it would be nice to
remove p7zip from http://cygwin.com/cygwin-64bit-missing regardless.

I reported the inquiry about the 64 bit assembly upstream at
https://sourceforge.net/p/p7zip/support-requests/6/#2150 and found
some patches were required to get the 64 bit assembly to work.
We can either modify the .cygport file to use the C version as I
initially suggested, or modify the .src.patch file to get the 64 bit
assembly version working. This also requires running dos2unix on the
assembly file in order to get the patch to apply.

I'm still not clear, do 64 bit packages have their own independent
set of patches, or is it necessary to write patches that work for
both 32 bit and 64 bit?

-Tony


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

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

[Tony Kelman]

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 Cygwin:
gcc -o stringpatch-cyg stringpatch.c   # requires admin rights
i686-pc-mingw32-gcc -o stringpatch-pc-32 stringpatch.c   # requires admin 
rights
i686-w64-mingw32-gcc -o stringpatch-w64-32 stringpatch.c   # requires admin 
rights
x86_64-w64-mingw32-gcc -o stringpatch-w64-64 stringpatch.c   # does not 
require admin rights


Under 64 bit Cygwin:
gcc -o stringpatch-cyg stringpatch.c   # does not require admin rights
i686-pc-mingw32-gcc -o stringpatch-pc-32 stringpatch.c   # requires admin 
rights
i686-w64-mingw32-gcc -o stringpatch-w64-32 stringpatch.c   # requires admin 
rights
x86_64-w64-mingw32-gcc -o stringpatch-w64-64 stringpatch.c   # does not 
require admin rights


What is the explanation for this discrepancy? Is this expected behavior? Is 
there an easy way to prevent any of the compiled executables from requiring 
admin rights?


All the compilers are version 4.8.2, with the exception of 
i686-pc-mingw32-gcc which is version 4.7.3 in both 32 and 64 bit. Cygcheck 
contents for both installations are posted here 
https://gist.github.com/9492379. If providing any additional info would be 
useful, please let me know.


Thanks,
Tony


--
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: Compiled executables requiring admin rights - different results between MinGW host type

[Tony Kelman]

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 while you read...

[..."whistling while you work"...]

Finished?  Fine.  So, the only fault of your application is it's name.
It's called "something-with-patch-in-it".  As everybody knows, an
application which is called "something-with-patch-in-it" is an
installer and needs elevation.  But only if it's a 32 bit application.


Wow. Thank you tremendously for this explanation Corinna. How bizarre.


- Take one of the manifest files you find in Cygwin's /usr/bin dir,
  and copy it alongside your binary, for instance:

$ cp /usr/bin/patch.exe.manifest ./stringpatch.exe.manifest


That did the trick. In 64 bit Cygwin the only .manifest file I found in
/usr/bin was install-info.exe.manifest (apparently from texinfo package),
but that worked. Makes sense that 64 bit Cygwin wouldn't need as
many of these, but my primary use case where I'm running into this
issue is cross-compiling from 64 bit Cygwin to i686-w64-mingw32.


- Wait until the next binutils version is released (should be in the
  next couple of days), and link your executable with the new linker.
  This will give you a default manifest integrated in your executable
  by default, which doesn't only claim compatibility with all existing
  WIndows versions, but also sets the RequestedExecutionLevel to
  "asInvoker", which avoids the elevation for this executable entirely.


Don't the various MinGW cross compilers have their own binutils? I look
forward to this being the most convenient long-term solution, (renaming
could also work, but that pull request is going to result in some confused
looks and/or raised eyebrows) but will this need to come from upstream
(MinGW.org for i686-pc, or MinGW-w64 for i686-w64) to change the default
no-manifest-file behavior for any of the hosts besides 32 bit Cygwin?

-Tony


--
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: From Microsoft: Windows 10 Console and Cygwin

[Tony Kelman]

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 written in 
shell

language and thus need a POSIX shell. Also, last time i checked the MSYS1
version they shipped itself had a few patches applied on top of it[1].

[1] https://github.com/msysgit/msysgit/tree/msys/src/rt/patches


And for those who might not follow these things too closely, the
upcoming 2.x releases of git-for-windows will be based off of MSYS2
(see https://github.com/git-for-windows), so a much more modern Cygwin
dll under the hood of the bash/coreutils pieces. But yes, large parts
of that git distribution, aside from the shell, are compiled by MinGW
compilers (MinGW-w64 in the under-development git 2.x releases) rather
than Cygwin compilers.

-Tony


--
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: mintty project

[Tony Kelman]

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 commits and pull requests every day, we've
had to put in workarounds and caching servers into our continuous
integration system specifically for Sourceforge-hosted dependencies because
it goes down so often.

Open-source mindshare is entirely on GitHub today. Even Microsoft is aware
of this and adapting to the times. Opening up mintty's development so it's
literally a click of a button to suggest a patch is a good thing, especially
since it looks like that GitHub fork was done well, including migrating all
the open issues over. We should put in some unit tests too, and set up a
hosted continuous integration service like AppVeyor to build and run the
tests on every commit and suggested pull request.

-Tony


--
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: mintty project

[Tony Kelman]

• 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 name squatting there and try to turn that into an
organization account. Send nowox an email to let him know this
conversation is being had (he may not subscribe to the cygwin list?),
he might even be willing to transfer ownership of the migrated
repository that he's made, if that would save you any time.

My concerns against github are different; I have a strong impression that 
it encourages anarchic project handling,
and I feel the concept of everybody being allowed to create forks and 
submit "pull requests" may not be good for a core project.


Opinions?


What's wrong with encouraging more people to contribute more easily?
Someone qualified still needs to review the patches before merging them,
and there are free services that offer excellent integration with github
to simplify automated testing.

The single biggest argument that I've ever seen in favor of using github
is this plot: https://jakevdp.github.io/figures/author_count.png
of the cumulative contributor count to numpy, scipy, and matplotlib over
time, comparing trends before and after those projects moved to github.

Large projects like Node.js, Rust, Julia, manage just fine with hundreds
of contributors on github (and would probably not flourish anywhere near
as well if they were not using github). For a project with a smaller
number of contributors like mintty, really the only thing you have to do
to avoid your perceived "anarchy" problem is emphasize that your repo is
the canonical upstream. If you're taking over maintenance of the cygwin
package, that's not hard to do.

-Tony


--
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: p7zip 9.38.1-1

[Tony Kelman]

Version 9.38.1-1 of the package p7zip is now available in the Cygwin
distribution.

CHANGES
Primarily bugfixes, see changelogs at http://www.7-zip.org/history.txt and
https://sourceforge.net/projects/p7zip/files/p7zip/9.38.1

DESCRIPTION
p7zip is the Unix port of 7-Zip, a file archiver that archives with
very high compression ratios.  It supports packing/unpacking 7z, zip, gzip
bzip2, xz, tar, and wim archives.  It supports unpacking of arj, cab, chm,
cpio, dmg, hfs, lzh, lzma, wim, xar, z, nsis, deb, rpm, msi, udf, iso, ntfs,
fat, vhd, and mbr archives.  This version does NOT support rar 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 from the cygwin-announce mailing list, look
at 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@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.

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

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

[Tony Kelman]

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 built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: 
/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/configure 
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-4.9.2-1.x86_64/src/gcc-4.9.2 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/mingw64-x86_64-gcc --htmldir=/usr/share/doc/mingw64-x86_64-gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-w64-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,lto,objc,obj-c++ --enable-fully-dynamic-strings --enable-graphite --enable-libgomp --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-version-specific-runtime-libs --with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic --with-cloog-include=/usr/include/cloog-isl --with-system-zlib --libexecdir=/usr/libThread model: win32gcc version 4.9.2 (GCC)Looking at https://gcc.gnu.org/onlinedoc

s/libstdc++/manual/configure.html,should the --enable-fully-dynamic-strings in 
the Cygwin build of thispackage drop the trailing s, as opensuse just 
did?Thanks,Tony

--
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-w64 --enable-fully-dynamic-string

[Tony Kelman]

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 opensuse was earlier on the path. I probably shouldn't have expected 
mixing cygwin-built mingw-w64 executables with opensuse-built mingw-w64 
libraries to work for as long as it has. If a cygwin package rebuild can 
make the ABI's compatible again that would be awesome and fix the breakage 
I've been seeing, but I probably need to switch some of my cygwin buildbots 
over to opensuse to make absolutely sure things will be compatible.


Thanks,
Tony


--
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-w64 --enable-fully-dynamic-string

[Tony Kelman]

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 not so urgent for now.)


-Tony


--
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: [ANNOUNCEMENT] Update: mintty 2.0.3

[Tony Kelman]

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:  http://cygwin.com/ml/#unsubscribe-simple

Re: Please upgrade cygwin cmake to 3.3.0

[Tony Kelman]

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
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Please upgrade cygwin cmake to 3.3.0

[Tony Kelman]

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.


Thanks,
David


The build of 3.3.1 is going smoothly so far, just checking unit tests now 
and should be able to upload soon. But I don't think the cygwin build of 
cmake includes the Visual Studio generator. It may have done so some time in 
the past, but none of the 3.x or 2.8.x versions I've run any time recently 
have done so. Did you see something in the release notes that led you to 
believe otherwise? I think you need to use a native build, like from CMake's 
website, to get the Visual Studio generator working.


-Tony


--
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: cmake-3.3.1-1

[Tony Kelman]

Version 3.3.1-1 of packages
 cmake
 cmake-gui
 cmake-doc
 cmake-debuginfo
 emacs-cmake
are available in the Cygwin distribution.

CHANGES
- For 3.2 release notes, see 
http://www.cmake.org/cmake/help/v3.2/release/3.2.html
- For 3.3 release notes, see 
http://www.cmake.org/cmake/help/v3.3/release/3.3.html
- The cmake-gui package is now built using Qt5, cherry-picking a patch from 
ports


DESCRIPTION
CMake is a cross-platform 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


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 "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@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.

--
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: cmake-3.3.1-2

[Tony Kelman]

Version 3.3.1-2 of packages
 cmake
 cmake-gui
 cmake-doc
 cmake-debuginfo
 emacs-cmake
are available in the Cygwin distribution.

CHANGES
- Includes a dllexport patch from Yaakov Selkowitz, ref
 https://cygwin.com/ml/cygwin-apps/2015-08/msg00107.html

DESCRIPTION
CMake is a cross-platform 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


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 "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@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.

--
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: cmake fails to run/build under Cygwin

[Tony Kelman]

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, running `PATH=/usr/bin cmake .` ?

Problems with exec'ing external programs would otherwise lead me to
suspect BLODA or something trying to inject hooks into all processes
on startup. You aren't trying to run this in conemu by any chance?

-Tony


--
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] Re: Updated: cmake-3.3.2-1

[Tony Kelman]

Version 3.3.2-1 of packages
 cmake
 cmake-gui
 cmake-doc
 cmake-debuginfo
 emacs-cmake
have been uploaded to the Cygwin distribution.

CHANGES
- Latest upstream release, and includes the patch requested in
 https://cygwin.com/ml/cygwin/2015-10/msg00174.html

DESCRIPTION
CMake is a cross-platform 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


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 "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@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.

--
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: p7zip 15.09-1

[Tony Kelman]

Version 15.09-1 of the package p7zip is now available in the Cygwin
distribution.

CHANGES
 - 7-Zip now can extract ext2 and multivolume VMDK images.
 - 7-Zip now can extract ext3 and ext4 (Linux file system) images.
 - assembly routines now supported in 64 bit cygwin
 - cygwin : fix in GetRamSize()
 - 7-Zip now can extract GPT images and single file QCOW2, VMDK, VDI 
images.

 - 7-Zip now can extract solid WIM archives with LZMS compression.
 - 7-Zip now doesn't sort files by type while adding to solid 7z archive.
 new -mqs switch to sort files by type while adding to solid 7z 
archive.
 - 7-Zip now can create 7z, xz and zip archives with 1536 MB dictionary for 
LZMA/LZMA2.

 - 7-Zip now can extract .zipx (WinZip) archives that use xz compression.


DESCRIPTION
p7zip is the Unix port of 7-Zip, a file archiver that archives with
very high compression ratios.  It supports packing/unpacking 7z, zip, gzip
bzip2, xz, tar, and wim archives.  It supports unpacking of arj, cab, chm,
cpio, dmg, hfs, lzh, lzma, wim, xar, z, nsis, deb, rpm, msi, udf, iso, ntfs,
fat, vhd, and mbr archives.  This version does NOT support rar 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 from the cygwin-announce mailing list, look
at 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@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. 


--
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: Octave 4.0.0-3 x86_64 segfault (suspect openblas)

[Tony Kelman]

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 
#include 
#define BLASINT int32_t
void dgeev_(char*, char*, BLASINT*, double*, BLASINT*, double*, double*,
   double*, BLASINT*, double*, BLASINT*, double*, BLASINT*, BLASINT*);
int main() {
char jobvl = 'N';
char jobvr = 'N';
BLASINT n = 1000;
double *A = malloc(n*n*sizeof(double));
BLASINT lda = n;
double *WR = malloc(n*sizeof(double));
double *WI = malloc(n*sizeof(double));
double *VL;
BLASINT ldvl = n;
double *VR;
BLASINT ldvr = n;
double *work = malloc(1*sizeof(double));
BLASINT lwork = -1;
BLASINT info[1];
BLASINT i, j;
for (i=0; i--
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: Octave 4.0.0-3 x86_64 segfault (suspect openblas)

[Tony Kelman]

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://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: libuv

[Tony Kelman]

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 that's actually pretty simple to work around
in libuv. The harder part is the lack of support in Cygwin for epoll,
inotify, and other async IO syscalls that libuv uses on unices. It might
be possible to graft together a build configuration for libuv on Cygwin
that uses WinAPI IOCP for the async parts but cygwin's posix layer for
the rest, but it would be quite a bit of work.

-Tony


--
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: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

[Tony Kelman]

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-w64 library and
application packages?

(Also a newer clang+llvm would be useful, they've made a lot of
improvements since 3.5.)

-Tony




--
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: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

[Tony Kelman]

> 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 recently) but can be compiled as mingw applications?
Or are you suggesting those should remain distributed via their own
channels rather than cygwin-packaged now that a few of the mingw
libraries they depend on are starting to be included in the distro
(and the remainder could be added). Seeing the cross-compiled libraries
become available removes some of the need people may have to use a
certain popular Cygwin fork, which does have quite a few mingw
applications packaged as well.

> 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, otherwise wait a few weeks.
I'm trying to figure out how to cross-build mingw llvm via cmake
now that they've deprecated autotools (it's still there in 3.8 with
a warning, but has been deleted on trunk which will become 3.9).

I'll check your i686-libgit2 package soon, but I suspect it may be
affected by https://github.com/libgit2/libgit2/issues/3342 and need
to be built with -mincoming-stack-boundary=2

-Tony

  
--
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: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

[Tony Kelman]

> 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 recently) but can be compiled as mingw applications?
Or are you suggesting those should remain distributed via their own
channels rather than cygwin-packaged now that a few of the mingw
libraries they depend on are starting to be included in the distro
(and the remainder could be added). Seeing the cross-compiled libraries
become available removes some of the need people may have to use a
certain popular Cygwin fork, which does have quite a few mingw
applications packaged as well.

> 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, otherwise wait a few weeks.
I'm trying to figure out how to cross-build mingw llvm via cmake
now that they've deprecated autotools (it's still there in 3.8 with
a warning, but has been deleted on trunk which will become 3.9).

I'll check your i686-libgit2 package soon, but I suspect it may be
affected by https://github.com/libgit2/libgit2/issues/3342 and need
to be built with -mincoming-stack-boundary=2

-Tony

  
--
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] [SECURITY] Updated: p7zip 15.09-2

[Tony Kelman]

Version 15.09-2 of the package p7zip is now available in the Cygwin
distribution. This is a security bugfix.

CHANGES
- Includes patch to fix CVE-2015-1038, ref
  https://cygwin.com/ml/cygwin-apps/2016-01/msg00055.html


DESCRIPTION
p7zip is the Unix port of 7-Zip, a file archiver that archives with
very high compression ratios. It supports packing/unpacking 7z, zip, gzip
bzip2, xz, tar, and wim archives. It supports unpacking of arj, cab, chm,
cpio, dmg, hfs, lzh, lzma, wim, xar, z, nsis, deb, rpm, msi, udf, iso, ntfs,
fat, vhd, and mbr archives. This version does NOT support rar 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 from the cygwin-announce mailing list, look
at 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@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.

  
--
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: Last Version of Cygwin for XP

[Tony Kelman]

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 dependencies but I wonder what the minimum
footprint of a wine-capable VM or container would be.

-Tony



--
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: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools

[Tony Kelman]

>> 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, otherwise wait a few weeks.
> I'm trying to figure out how to cross-build mingw llvm via cmake
> now that they've deprecated autotools (it's still there in 3.8 with
> a warning, but has been deleted on trunk which will become 3.9).

Okay, just FYI, building LLVM 3.8 or newer will fail with a win32-threads
build of mingw-w64 unless you build with LLVM_ENABLE_THREADS=0
and completely stub out lib/Support/ThreadPool.cpp. We're using MCJIT
(actually the new ORCJIT) in Julia and it's slower than the old JIT but
mostly works.

> I'll check your i686-libgit2 package soon, but I suspect it may be
> affected by https://github.com/libgit2/libgit2/issues/3342 and need
> to be built with -mincoming-stack-boundary=2

Confirmed.

$ echo '#include "git2.h"
void main() {
    git_repository* repo_ptr = NULL;
    char* repo_url = "https://github.com/JuliaLang/Example.jl";;
    char* repo_path = "Example.Bare";
    git_clone_options clone_opts = GIT_CLONE_OPTIONS_INIT;
    clone_opts.bare = 1;
    git_libgit2_init();
    git_clone(&repo_ptr, repo_url, repo_path, &clone_opts);
    git_libgit2_shutdown();
}'> clonetest.c

Tony@LAPTOP-O230JCFF ~
$ i686-w64-mingw32-gcc -L/usr/i686-w64-mingw32/sys-root/mingw/bin \
  -lgit2 clonetest.c -g -o 
/usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe

Tony@LAPTOP-O230JCFF ~
$ gdb -q /usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe
Reading symbols from 
/usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe...done.
(gdb) r
Starting program: /usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe
[New Thread 8788.0x794]
[New Thread 8788.0x209c]
[New Thread 8788.0x638]
[New Thread 8788.0x123c]

Program received signal SIGSEGV, Segmentation fault.
0x6ccf9188 in libgit2!git_filebuf_commit ()
   from /usr/i686-w64-mingw32/sys-root/mingw/bin/libgit2.dll

(be sure to `rm -rf Example.Bare` between runs of this test program)


  
--
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: [ANNOUNCEMENT] llvm 3.7.1-1

[Tony Kelman]

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 as a result.

You're not supposed to use BUILD_SHARED_LIBS with LLVM's cmake build.
They have a dedicated flag LLVM_BUILD_LLVM_DYLIB for this.

-Tony



--
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: Can't link .res file (from windres) using i686-pc-mingw32-g++

[Tony Kelman]

> 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 coff -o res/NPOTAdlg.res
>> # i686-pc-mingw32-g++ -s -mwindows -static-libgcc -static-libstdc++
>> -lwininet NPOTA.o NPOTAdlg.o res/NPOTAdlg.res ../../library/library.a
>> /usr/i686-pc-mingw32/sys-root/mingw/lib/libwininet.a -o NPOTA

Or use i686-pc-mingw32-windres? If that doesn't exist, I know there is
one in mingw-w64 under the name i686-w64-mingw32-windres.

-Tony

  
--
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: [ANNOUNCEMENT] Updated: mingw64-*-{headers,runtime,winpthreads}-4.0.5-1 (x86/x86_64)

[Tony Kelman]

> 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 intentional that x86_64-headers
gets built with --enable-secure-api but i686-headers doesn't?

Thanks,
Tony

  
--
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: [attention p7zip maintainer] p7zip 15.14 is out

[Tony Kelman]

> 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" to build it.

When I run the suggested "cygport pkg" command, I get

*** Warning: setup.hint is missing
*** Warning: p7zip.hint is missing

I get the sense this is using a pretty old-style cygport packaging, which
I mostly inherited from the most recent 32-bit upload when I first adopted
the package. I'm not motivated enough to fight with cygport to modernize this
so I'll upload manually. Is this a regression in cygport's permissiveness?

If anyone wants to help point me in the right direction with modernizing,
I have the packaging sources up at https://github.com/tkelman/cygwin-p7zip

-Tony

  
--
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: faster opening Cygwin from Explorer window

[Tony Kelman]

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 willing to share
> I'd love to hear about it. BTW, I'm using Windows 7 and am current
> on Cygwin 64-bit.
> 
> --Ken Nellis

Git for Windows has (used to have?) a "git bash here" explorer integration
that I bet you could borrow and adapt into a "cygwin terminal here."

-Tony





--
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: mingw64-*-{headers,runtime,winpthreads}-4.0.5-1(x86/x86_64)

[Tony Kelman]

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 just had issues building some of LLVM's unit tests and
> tracked the root cause back to here - is it intentional that x86_64-headers
> gets built with --enable-secure-api but i686-headers doesn't?

Week later, hopefully socially acceptable ping. Can I request that
mingw64-i686-headers get rebuilt with --enable-secure-api at the next
update? Is there an especially good reason not to have it enabled by
default?

Thanks,
Tony



--
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: GitForWindows vs. Cygwin

[Tony Kelman]

>> 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 at all?  Is it descended from MSysGit?  I have been googling all over,
>> but not finding good answers.

GitForWindows 2.x is based on MSYS2, which doesn't share any non-cygwin
code with the old MSYS1 as far as I'm aware, but it reimplements (on
top of a much more up-to-date fork of cygwin) the path-mangling trick
that was the main motivating factor for using MSYS1 in the first place.
When you have a non-cygwin windows executable (one compiled by mingw.org,
or mingw-w64, or MSVC compilers) and try to pass it a posix/cygwin-style
absolute path, the windows executable won't usually recognize it as a
file that exists. What the MSYS shell does is apply a heuristic that
automatically translates posix-style absolute paths to Windows paths
(similar to manually calling `cygpath -w /posix/style/path` on each
argument within cygwin) before passing the argument to the executable.
There are other differences between MSYS2 and Cygwin, mostly that it
uses a different package manager and repository, but these are less
significant with respect to GitForWindows' requirements.

The git.exe in Cygwin's git package is a cygwin executable compiled
by cygwin's gcc. Hence it understands posix-style paths just fine,
but it depends on cygwin1.dll to do so, and may not perform as well as
a non-cygwin Windows executable. (Maybe someone has benchmarked this.)

GitForWindows has historically been compiled using mingw gcc -
the legacy and now-mostly-obsolete mingw.org in the git 1.x timeframe
(this is the reason there was not a 64 bit version of git.exe through
that release channel at the time), and more recently the mingw-w64
compilers for git 2.x. Many of your questions are answered at
https://github.com/git-for-windows/git/wiki/FAQ#what-is-the-relationship-between-git-for-windows-and-msysgit
https://github.com/git-for-windows/build-extra#components-of-the-git-for-windows-sdk
https://www.msys2.org

Some components used by git (any shell scripts, for example) require
some form of posix compatibility layer to function. The recent MinGit
has a busybox-based variant that can mostly avoid MSYS2 dependencies,
though it seems to have at least some small MSYS2 pieces remaining:
https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit

You can see exactly how the MSYS2 runtime used by GitForWindows differs
from the version used by the MSYS2 project itself by looking at the
git repo at https://github.com/git-for-windows/msys2-runtime/commits/master
and how MSYS2 differs from upstream cygwin by looking at the repos at
https://github.com/Alexpux/Cygwin/commits/msys2-master
https://github.com/mirror/newlib-cygwin/commits/master
https://github.com/mirror/newlib-cygwin/releases

These "patch sets" tend to get rebased pretty frequently when new
cygwin releases come out upstream.

I dunno where else this history has been written down, but this is
my understanding of the development heritage. Any git and/or MSYS2
maintainers can correct me if anything I stated here is incorrect.

-Tony

--
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: GitForWindows vs. Cygwin

[Tony Kelman]

>> 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.
>
> No, Tony explained how it's related to MSYS2. This isn't a MSYS2 mailing list.

Don't think they have one. Git for Windows does, and somewhere like
https://groups.google.com/forum/#!topic/git-for-windows/jtwpuGa5u_E
would have been a pretty good alternate place to ask this question.
But I also explained how MSYS2 is very closely related to Cygwin,
and pretending they are completely unrelated and have nothing to do
with one another is myopic and misleading. If "how are MSYS2 and
Cygwin related to one another" is a banned question on this list,
perhaps that should be written down somewhere.

>>> It doesn't use cygwin, therefore it's not related. Since this is a cygwin 
>>> mailing list,
>>> that means the first two replies were correct — this isn't the place to 
>>> discuss it.
>
> Which means this still applies.

When the vast majority of the code in the MSYS2 runtime is exactly
the same as the code in the Cygwin runtime, and Git for Windows uses
msys-2.0.dll in a number of places (which is essentially a renamed
copy of cygwin1.dll) the question was fair. Particularly given Cygwin
has its own git package, it's only natural to wonder how that differs
from Git for Windows, and how it differs from the probably lesser-
known msys2-git package (which is built in very nearly the same
configuration as the Cygwin git package, posix style).

-Tony

--
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: GitForWindows vs. Cygwin

[Tony Kelman]

>> 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/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Tony Kelman]

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 reboot over into windows to look at any patches
you may have. Without the patch from the tail end of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 , mingw-w64 gcc 5.x
will miscompile llvm. This should be fixed when gcc 6 comes out, but
that may of course break other things.

-Tony



--
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: [attention p7zip maintainer] p7zip 15.14 is out

[Tony Kelman]

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



--
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: [attention p7zip maintainer] p7zip 15.14 is out

[Tony Kelman]

>> 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
until I went and read the cygport docs in detail.

I didn't realize my -1 upload actually went through correctly, and I
spent a couple of weeks not using Windows. Once we can get the
new Windows Subsystem for Linux on Windows 10 I won't be using my
opensuse partition much any more - but I also might not use cygwin
either, we'll see.

I'll spin a -2 rebuild with the setup.hint mistake fixed, and mark the
build time dependency.

-Tony

  
--
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: p7zip 15.14.1-1

[Tony Kelman]

Version 15.14.1-1 of the package p7zip is now available in the Cygwin
distribution.

CHANGES
- New upstream release
- Minor packaging fixes, add nasm to DEPEND


DESCRIPTION
p7zip is the Unix port of 7-Zip, a file archiver that archives with
very high compression ratios. It supports packing/unpacking 7z, zip, gzip
bzip2, xz, tar, and wim archives. It supports unpacking of arj, cab, chm,
cpio, dmg, hfs, lzh, lzma, wim, xar, z, nsis, deb, rpm, msi, udf, iso, ntfs,
fat, vhd, and mbr archives. This version does NOT support rar archives.

HOMEPAGE
https://sourceforge.net/projects/p7zip and http://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

[Tony Kelman]

> 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 spin. Lots of things are broken or not yet
implemented, still lots of problems at this stage. Apparently they
already have fixes for some of the issues that have been reported
at https://github.com/Microsoft/BashOnWindows/issues but not rolled
out to users yet. In its current form it could only possibly be a
replacement for cygwin if you can get away with your only interoperation
between cygwin and win32 executables or libraries being the /cygdrive
mounted filesystem. Getting binaries straight from Ubuntu is a cool
trick and will be really convenient once enough of the syscalls are
working that you don't notice any gaps. I'd prefer a different distro's
userland if I had a choice, but maybe that'll be possible later.

-Tony

  
--
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: [ANNOUNCEMENT] mingw64-*-fftw3 3.3.4-1

[Tony Kelman]

> 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.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Tony Kelman]

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.src.tar.xz
tar -xJf llvm-3.7.1.src.tar.xz
mkdir llvm-3.7.1.src/build
cd llvm-3.7.1.src/build
../configure CC=gcc CXX=g++ # it defaults to clang but that's broken
make -j8

This works perfectly when I downgrade to make 4.1-1. On latest 4.2-1,
I get https://gist.github.com/a9322320eb73f9c3b56f6b732785d8a4

... (about 12 minutes in) ...
make[2]: Entering directory '/home/Tony/github/llvm-3.7.1.src/build/tools/lto'
make[2]: *** No rule to make target
'/home/Tony/github/llvm-3.7.1.src/build/Release+Asserts/lib/libLLVMBPFCodeGen.a',
needed by
'/home/Tony/github/llvm-3.7.1.src/build/Release+Asserts/bin/cygLTO.dll'.  Stop.
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/home/Tony/github/llvm-3.7.1.src/build/tools/lto'
make[1]: *** [/home/Tony/github/llvm-3.7.1.src/Makefile.rules:880: all] Error 1
make[1]: Leaving directory '/home/Tony/github/llvm-3.7.1.src/build/tools'
make: *** [/home/Tony/github/llvm-3.7.1.src/Makefile.rules:880: all] Error 1


Maybe there's a bug in LLVM's dependency declarations here that just
gets triggered by the newer version of make? Continuing with make -j1
seems to go through on make 4.2, but was never necessary on 4.1.


My cygcheck.out is at (can't do attachments from gmane)
https://gist.github.com/16a11b6ce7ac5b64e7bd6dc67ac732fe

Thanks in advance,
Tony



--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"

[Tony Kelman]

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, and cmake 3.3.2.


I'm at a conference this week so really busy, but it sounds like I may
need to update cmake to the latest version (which is overdue anyway)
if something in the latest gcc is unhappy. Can you provide full
reproduction steps, a source repo or tarball to download? Also looking
into (and posting) the full content of the cmake error/output log files
might provide more information about what the problem is.

Thanks,
Tony



--
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: Problem with git on cygwin64 on Windows 10 (2.8.3-1)

[Tony Kelman]

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"...
>  >
>  > Thomas  thoni64 ~
>  > $

Maybe try
$ PATH=/usr/bin git clone https://github.com/thoni56/cgreen.git
? That has helped resolve similar issues for me in the past.

-Tony



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

[Tony Kelman]

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, and that each ODE depends on around half of
> the others, so a Jacobian (were I to calculate it) would be quite
> densely packed.
> 
> Sundials works well for this problem, but it takes rather a lnog time
> and only utilizes a single processor on a 20-core machine.
> 
> So, the question: Is there a way to parallelize the calculation for
> this? The references in the Sundials docs that I have seen only refer
> to parallelization of solving linear equations, which I do not need
> to do.
> 
> Regards
> 
>   Thomas
> 

This is more of a general numerical ODE or Sundials usage question
rather than a cygwin specific one, but I would try openmp or mpi on
your function evaluations first, if that's taking most of the time.
Do you know whether sundials is thread-safe?

-Tony




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

[Tony Kelman]

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-64)
> version will give best use of vector processing, in my
> experience.
> 
> Regards -- Eliot Moss

numpy is only as parallel as the underlying BLAS/LAPACK library that
it uses is. So if you're using Cygwin's openblas then you're in
decent shape. But I don't think cv_adams spends much time (if any?)
in BLAS/LAPACK dense linear algebra functions, I think it's mostly
dominated by function evaluation time.

-Tony



--
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: problem building with cmake under cygwin (need clang)

[Tony Kelman]

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=clang ?


--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-1 (x86/x86_64) (Testing)

[Tony Kelman]

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&r2=232827&pathrev=232828
which is only on gcc 6, it has not been applied to the gcc-5 branch
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/config/i386/winnt.c?view=log

I was expecting the following to fail, but surprisingly it seems okay.
(It's large and would take an hour or more for you to reproduce this,
probably no need since it's working so far):

# check build prereqs
curl --version
patch --version
python --version
g++ --version
m4 --version
cmake --version
7z -h
x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-gfortran --version
# end of build prereq checks
git clone https://github.com/JuliaLang/julia -b release-0.5
cd julia
mkdir -p usr/bin # I'll need to fix Julia's build system for libvtv
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libvtv-0.dll usr/bin
make -j8 test # defaults to cross-compile when build env is cygwin


-Tony


--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-1 (x86/x86_64) (Testing)

[Tony Kelman]

> 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 those are
LLVM and OpenBLAS, which I believe we have mingw-w64 cross-compiled
versions of available in Cygwin, so it might be possible to link
against those to save some time, I haven't tried. I suspect those
packaged libraries haven't been rebuilt against this test gcc build
yet though. And in the default `git clone ...; make` build of Julia
we apply some patches to fix various bugs depending on what versions
of the dependency libraries we're using, so a USE_SYSTEM_LLVM build
might have test failures that aren't due to the GCC version being used.

On my 4 x (2 HT) core i7-6700 HQ laptop with an SSD, the from-scratch
source build of Julia without linking to any pre-existing dependency
libraries took about an hour. Not sure how that compares to QT.

-Tony


--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

> 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 reinstated as prev? And/or
could packaging of GCC 6 be done with a faster turnaround time? Here are
the repro steps for compiling to 32 bit (with apologies for how long it'll
take, it's mostly miscompilation of LLVM causing the problem):

# check build prereqs
curl --version
patch --version
python --version
g++ --version
m4 --version
cmake --version
7z -h
i686-w64-mingw32-gcc --version
i686-w64-mingw32-g++ --version
i686-w64-mingw32-gfortran --version
# end of build prereq checks
git clone https://github.com/JuliaLang/julia -b release-0.5
cd julia
echo 'XC_HOST = i686-w64-mingw32' > Make.user
make -j8 test


At the end of this, roughly an hour later, I see

JULIA usr/lib/julia/sys.o

Please submit a bug report with steps to reproduce this fault, and any error 
messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0xc5e821 -- unknown function (ip: 
00C5E821)
while loading sysimg.jl, in expression starting on line 6
unknown function (ip: 00C5E820)
unknown function (ip: 00C5ED73)
unknown function (ip: 00C5ED73)
unknown function (ip: 04B86E87)
unknown function (ip: FFFE)
...


instead of finishing building and executing the tests as expected.

Thanks,
Tony

--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

> 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
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 packaging changes you'd need
to go from 5.4.0 to 6.1.0. (And 6.2 should be coming shortly.)

According to the discussion in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
the underlying issue may have also been a problem for cygwin targets,
but I do much less testing there as Julia relies on async IO (via a fork
of libuv) that cygwin doesn't provide.

-Tony

--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

>> 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 packaging changes you'd need
>> to go from 5.4.0 to 6.1.0. (And 6.2 should be coming shortly.)
> 
>
> Usually a 5-6 hours per target, but my machine is underpowered, testing
> would be much appreciated.

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 from
opensuse where they already have mingw-w64 GCC 6 packaged and see if things
are in a better shape there.

-Tony

--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

> 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 from
> opensuse where they already have mingw-w64 GCC 6 packaged and see if things
> are in a better shape there.

I also get a segfault when I cross-compile with GCC 6.1 from opensuse 13.2
(needs wine to run this particular bootstrap build step), so this looks
like it's something else. To be sure, could you test the small ipa-ra.tgz
test case from the top of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
with your build? It runs correctly with my build where I've applied the
patch, but the larger Julia+LLVM case doesn't work. So this is something
new, and/or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601 wasn't
actually a duplicate of 66655. Will continue investigating.

-Tony


--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

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

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?

> Yaakov,
> 
> Can you restore 4.9.2-2 as previous? Thanks.

In the meantime it would be good to get 4.9.2-2 back as prev if
we can. Thanks!

-Tony

--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

>> 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?
>> 
>
> Please CC me, thanks.

GCC's bugzilla couldn't find a match for the gmail reply-to email you
have here, so see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333

-Tony

--
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: cmake-3.6.2-1

[Tony Kelman]

Version 3.6.2-1 of packages
  cmake
  cmake-gui
  cmake-doc
  cmake-debuginfo
  emacs-cmake
are available in the Cygwin distribution.

CHANGES
- I hadn't updated this package in a little while, so might have missed
  some build dependencies on my new system. Speak up if you see any issues.
- For 3.4 release notes, see 
http://www.cmake.org/cmake/help/v3.4/release/3.4.html
- For 3.5 release notes, see 
http://www.cmake.org/cmake/help/v3.5/release/3.5.html
- For 3.6 release notes, see 
http://www.cmake.org/cmake/help/v3.6/release/3.6.html

DESCRIPTION
CMake is a cross-platform 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


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 "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@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.

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

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

[Tony Kelman]

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 for a few months to try out the latest bugfixes in the new Windows
Subsystem for Linux. This is the first time I've hit any Cygwin trouble
on an update, rolling back to build 14915 is making things better so far.

Apologies for not collecting a cygcheck.out before rolling back, I've got
a fair amount of work I need to get done right now so a working system
is more important at the moment than helping debug this. But I'd be
willing to get this insider build in a VM and test things out, I'm fine
building cygwin from source and running things in gdb if there's a FAQ
for what to look for somewhere. Advice, anyone?

Thanks,
Tony

--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

[Tony Kelman]

> 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 for a few months

Anybody? Just checked 14931 and it has the same problem.
I'll be switching back the slow ring as soon as it lets me, but
I'm about to start getting "build will expire" popups.

-Tony

--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

[Tony Kelman]

> 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 the error message so we can
> determine where in the Cygwin code it's coming from?

I'll have to see if I can reproduce in a VM, and hope they release a
stable build soon that doesn't expire on me or exhibit this problem.
Is anyone else testing insider builds?

-Tony

--
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: CMake "command not found" on Windows Server 2012 R2

[Tony Kelman]

> 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 this locally? If not, try the rdp options on appveyor
to remote into one of their VM's. Trying to run strace on this just hangs,
so I suspect this is due to some of the other things appveyor puts on the
path by default (most likely, msys2).

--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

[Tony Kelman]

> 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:
>  - open a Command Prompt running as Administrator
>  - cd c:\ or wherever the root of your Cygwin installation drive is
>  - dir /S cygwin1.dll
> You might see multiple listings of the same cygwin1.dll due to the crazy WoW 
> support but these will all have the same date and size. You want to find the 
> cygwin1.dll that has a different date (probably older) and size. That's the 
> problematic one; rename it or delete it.

And if not?

C:\>dir /S cygwin1.dll
 Volume in drive C is Windows
 Volume Serial Number is C225-5FBC

 Directory of C:\cygwin64\bin

08/31/2016  05:32 AM 3,306,962 cygwin1.dll
   1 File(s)  3,306,962 bytes

 Total Files Listed:
   1 File(s)  3,306,962 bytes
   0 Dir(s)  58,480,676,864 bytes free

C:\>


--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

[Tony Kelman]

> 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 from, but I removed it and it made no
difference.

This is absolutely due to a change in Windows itself. 3 updates in
a row now, 14926, 14931, and now 14936, it's 100% reproducible just
from updating Windows. Downgrading to build 14915 gets everything back
working again, but that build is now expired so the only way for me to
get back to a supported build of Windows where cygwin works properly
is by totally reinstalling Windows. I haven't done that yet, but if
we can't identify the problem and a solution soon, I will have to.


--
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: Advice for debugging heap mismatches? (Win10 Insider build 14926)

[Tony Kelman]

>> 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 variable CYGWIN_NOWINPATH=true and try
> again.

Didn't help. BTW, that remains undocumented, ref
https://cygwin.com/ml/cygwin/2014-08/msg00418.html

C:\cygwin64\bin>set CYGWIN_NOWINPATH=true

C:\cygwin64\bin>sh -l

Tony@LAPTOP-O230JCFF ~
$ cd github/curl

Tony@LAPTOP-O230JCFF ~/github/curl
$ rm -rf build && mkdir build && cd build

Tony@LAPTOP-O230JCFF ~/github/curl/build
$ cmake .. && make -j4 && echo ok
-- The C compiler identification is GNU 5.4.0
CMake Warning at /usr/share/cmake-3.6.2/Modules/Platform/CYGWIN.cmake:15 
(message):
  CMake no longer defines WIN32 on Cygwin!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that Cygwin is WIN32.
  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.6.2/Modules/CMakeSystemSpecificInformation.cmake:36 
(include)
  CMakeLists.txt:47 (project)


-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Warning at CMakeLists.txt:49 (message):
  the curl cmake build system is poorly maintained.  Be aware


-- curl version=[7.51.0-DEV]
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_ADDR
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_ADDR - Success
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID
-- Performing Test HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID - Success
Found *nroff option: -- -man
-- Looking for dlopen in dl;
-- Looking for dlopen in dl; - found
-- Looking for connect in socket;dl
-- Looking for connect in socket;dl - not found
-- Looking for gethostbyname in c
-- Looking for gethostbyname in c - found
-- Looking for gethostname
-- Looking for gethostname - found
  0 [main] cmake 1280 child_info_fork::abort: 
C:\cygwin64\bin\cygintl-8.dll: Loaded to different address: parent(0x3E368) 
!= child(0xC)

[1]+  Stopped(SIGSTOP)cmake ..




> Something occupies the heap area for Cygwin, based on the low address.
> What does /proc/self/maps tell you?


$ cat /proc/self/maps
0001-0002 rw-s  : 0   [win heap 1 
default shared]
0002-00021000 rw-s  : 0
0003-00048000 r--s  : 0
0005-00054000 r--s  : 0
0006-00061000 r--s  : 0
0007-00072000 rw-p  : 0
0009-00099000 rw-p  : 0   [win heap 0 
default grow]
00099000-0019 ===p 9000 : 0   [win heap 0 
default grow]
0019-00191000 rw-p  : 0   [win heap 0 
default grow]
00191000-001C2000 ===p 1000 : 0   [win heap 0 
default grow]
0020-00352000 ===p  : 0
00352000-00353000 rw-p 00152000 : 0   [peb]
00353000-00355000 rw-p 00153000 : 0   [teb (tid 7204)]
00355000-00357000 rw-p 00155000 : 0   [teb (tid 7552)]
00357000-00359000 rw-p 00157000 : 0   [teb (tid 7648)]
00359000-0035B000 rw-p 00159000 : 0   [teb (tid 10468)]
0035B000-0035D000 rw-p 0015B000 : 0   [teb (tid 3876)]
0035D000-0040 ===p 0015D000 : 0
0060-006C1000 r--s  C225:5FBC 1407374885978955
/cygdrive/c/Windows/System32/locale.nls
006D-008CB000 ===p  : 0   [stack (tid 7552)]
008CB000-008CE000 rw-g 001FB000 : 0   [stack (tid 7552)]
008CE000-008D rw-p 001FE000 : 0   [stack (tid 7552)]
008D-00ACB000 ===p  : 0   [stack (tid 7648)]
00ACB000-00ACE000 rw-g 001FB000 : 0   [stack (tid 7648)]
00ACE000-00AD rw-p 001FE000 : 0   [stack (tid 7648)]
00AD-00CCB000 ===p  : 0   [stack (tid 
10468)]
00CCB000-00CCE000 rw-g 001FB000 : 0   [stack (tid 
10468)]
00CCE000-00CD rw-p 001FE000 : 0   [stack (ti

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

[Tony Kelman]

> 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 command? It does take a variable amount
of time to trigger, and sometimes exhibits as a complete freeze instead
of an error. What should I be looking for here?

> Have you tried to play around with the virus scanner settings?

I already have a Windows Defender exclusion for my Cygwin installs.
Turning off real-time protection temporarily didn't help.


> One sure-fire way to make sure your 32-bit E: installation is not causing 
> havoc
> with your 64-bit C: installation is to temporarily rename E:\cygwin32 to
> E:\somethingelse and retry your build.  This should not be necessary but I 
> don't
> know what else to suggest.

Good idea. Tried it, didn't help.

--
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: Random "child_info_fork::abort:"

[Tony Kelman]

>  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:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Tony Kelman]

> 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 for gcc 5 is deeply buggy on
mingw targets, resulting in miscompiling C++ libraries like LLVM.
This is keeping me on gcc 4 indefinitely until it gets fixed. I may
have to abandon gcc and switch to clang due to this, but there are
many libraries that have broken build systems that behave incorrectly
when you try to use clang on Windows.

I'll use time machine if that's my only way to keep getting gcc 4,
but this bug in gcc should really be fixed or it's going to start
showing up in cygwin-mingw-cross and msys2 packages.

Thanks,
Tony

--
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: [ANNOUNCEMENT] Updated: mingw64-*-gcc-5.4.0-2 (x86/x86_64)

[Tony Kelman]

> 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 build a patched gcc (and the test case)
than in cygwin.

Large test case (takes about 15 minutes on my year-old laptop):

curl -L http://llvm.org/releases/3.7.1/llvm-3.7.1.src.tar.xz | tar -xJf -
mkdir -p llvmbuild/bin
cd llvmbuild
echo 'set(CMAKE_C_COMPILER gcc)' > NATIVE.cmake
echo 'set(CMAKE_CXX_COMPILER g++)' >> NATIVE.cmake
cp /usr/i686-w64-mingw32/sys-root/mingw/bin/*.dll bin
cmake ../llvm-3.7.1.src -DCMAKE_SYSTEM_NAME=Windows \
  -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=host \
  -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc \
  -DCMAKE_CXX_COMPILER=i686-w64-mingw32-g++ \
  -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DCMAKE_TOOLCHAIN_FILE=$PWD/NATIVE.cmake
make -j`nproc` opt
bin/opt.exe -slp-vectorizer \
  -S ../llvm-3.7.1.src/test/Transforms/SLPVectorizer/X86/vector.ll


That'll give the following sane LLVM IR output on gcc 4.9, or crash on
unpatched 5+.

; ModuleID = '../llvm-3.7.1.src/test/Transforms/SLPVectorizer/X86/vector.ll'
target datalayout = 
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.8.0"

define void @test(<4 x i32> %in, <4 x i32> %in2) {
  %k = icmp eq <4 x i32> %in, %in2
  ret void
}


> I'll to include the update in the next 5.x release.

Thanks! We're mainly trying to double-check that the patch doesn't
introduce any regressions, cause more problems than it solves.

-Tony

--
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: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1

[Tony Kelman]

> 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 | head -n 2
BUGS
   It's too big and too slow.

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

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

[Tony Kelman]

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.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

Tony@LAPTOP-O230JCFF ~
$ mkdir tartest

Tony@LAPTOP-O230JCFF ~
$ echo 'tartest' > tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ echo 'tartest/filelist.txt' >> tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ tar -czf test.tar.gz -T tartest/filelist.txt --no-recursion

Tony@LAPTOP-O230JCFF ~
$ tar -tf test.tar.gz
tartest/
tartest/filelist.txt
tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ ls -al test.tar.gz
-rw-r--r-- 1 Tony None 186 Mar  7 15:39 test.tar.gz



If I downgrade to tar 1.28, I instead get

Tony@LAPTOP-O230JCFF ~
$ tar -tf test.tar.gz
tartest/
tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ ls -al test.tar.gz
-rw-r--r-- 1 Tony None 177 Mar  7 15:38 test.tar.gz



... though I just checked in a docker container of Debian unstable which
has tar 1.29 and I see the same issue, so this isn't cygwin-specific
and maybe I should report it upstream.

-Tony

--
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: tar 1.29 regression, duplicating files with -T and --no-recursion

[Tony Kelman]

> $ 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/?id=163e96a0e619a900eab6de827c7c5749ecc9d3f2
may have been accidental. As of 
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=9a33077a7b7ad7d32815a21dee54eba63b38a81c
(the very first commit after 1.29), this invocation now gives an error.
Guess no action is needed.

-Tony

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