On 2/26/2016 01:44, Yaakov Selkowitz wrote:
> JonY,
>
> It has been brought to my attention that /usr/lib/w32api is now taking
> precedence over /usr/lib, which is a result of this commit:
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227962
> https://
gcc-5.3.0-3 has been uploaded for 32bit and 64bit Cygwin, this release
reverts a change that causes /usr/lib/w32api to be searched before
/usr/lib, it should now behave similarly to gcc-4.
GCC5 uses a new versioning scheme, under the old scheme, it would be
5.0.3, with 5.2.0 as 5.0.2. See https://
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
The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_
On 3/17/2016 16:07, Tony Kelman wrote:
> 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
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.
Note that C11 with gnu extensions is now default for C. See
https://gcc.gnu.org/gcc-5/porting_to.html for more help on porting code
to GC
On 3/21/2016 20:31, Tony Kelman wrote:
> 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 h
On 3/22/2016 03:12, Lee wrote:
> On 3/17/16, Yaakov Selkowitz wrote:
>> The old mingw.org (i686-pc-mingw32) toolchain has been removed from the
>> Cygwin distribution. It was unmaintained (both upstream and downstream)
>> and limited to 32-bit support.
>>
>> Users who wish to cross-compile for nat
Version 3.0b_svn5431-1 of "w32api" has been uploaded.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
Cygwin packagers, please test your applications.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *
On 10/20/2012 21:12, Christian Franke wrote:
> Just for Info:
>
> The new /usr/include/w32api/windef.h does no longer define _WIN32.
>
> This may require compile fixes for some sources which check only for
> _WIN32 and not for __CYGWIN__ after windows.h is included.
>
> Christian
I can't imagin
On 10/21/2012 01:31, Christian Franke wrote:
> Kai Tietz wrote:
>> 2012/10/20 JonY wrote:
>>> On 10/20/2012 21:12, Christian Franke wrote:
>>>> Just for Info:
>>>>
>>>> The new /usr/include/w32api/windef.h does no longer define _WIN32.
>
Version 3.0b_svn5431-2 of "w32api-runtime" has been uploaded.
This release fixes a bug with the iphlpapi.def stdcall exports list.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
*** CYGWI
On 11/15/2012 13:37, Peter Rosin wrote:
> On 2012-11-15 05:40, marco atzeri wrote:
>> On 11/14/2012 11:09 PM, David Stacey wrote:
>>> I am trying to use 'xz -9' to compress a file, but the programme exits
>>> with the error message 'Cannot allocate memory'. Here's what I tried:
>>>
>>>
>>> $ echo H
Version 3.0b_svn5452-1 of "w32api" has been uploaded.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
Cygwin packagers, please test your applications.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
I have just updated the CRT and runtime libraries for the mingw-w64
cross compilers.
mingw64-*-headers-3.0b_svn5452-1
mingw64-*-runtime-3.0b_svn5352-1
The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-ming
Version 3.0b_svn5496-1 of "w32api" has been uploaded.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
Cygwin packagers, please test your applications.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
On 2/17/2013 14:43, Fergus wrote:
> On attempting to install w32api-headers-3.0b_svn5591-1:
> Error message:
> Unable to extract /usr/include/w32api/agtctl.h -- corrupt package?
> Fergus
>
Can you test with kernel.org mirror?
I checked:
http://mirrors.kernel.org/sourceware/cygwin/release/w32api/
I have just updated the CRT and runtime libraries for the mingw-w64
cross compilers.
mingw64-*-headers-3.0b_svn5591-1
mingw64-*-runtime-3.0b_svn5591-1
The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-min
Version 3.0b_svn5591-1 of "w32api" has been uploaded.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
Cygwin packagers, please test your applications.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
Version 4.7.2-1 of "gcc4" has been uploaded.
I have just uploaded an updated GCC-4 package to cygwin.com. It will be
arriving at your favourite mirror next time it synchronizes itself with
the official Cygwin repository.
This is an experimental release of gcc 4.7.2, it is not expected to be
bug f
On 3/7/2013 00:53, Christopher Faylor wrote:
> On Wed, Mar 06, 2013 at 08:40:32AM -0500, Chris Sutcliffe wrote:
>> I noticed a problem after upgrading to the 2.23.1-1 release of
>> binutils that cygport was no longer generating debuginfo files. After
>> digging in to it a little and following up o
On 3/12/2013 02:03, Dave Korn wrote:
> On 05/03/2013 16:22, Christopher Faylor wrote:
>> On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote:
>>> I have GCC-4.5.3 installed and I am not going to install the test
>>> version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1
I have just updated the CRT and runtime libraries for the mingw-w64
cross compilers.
mingw64-*-headers-3.0b_svn5747-1
mingw64-*-runtime-3.0b_svn5747-1
The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-min
Version 3.0b_svn5747-1 of "w32api" has been uploaded.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
Cygwin packagers, please test your applications.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
On 4/27/2013 04:12, Charles Wilson wrote:
> Any thoughts on this -- the idea that the cygwin (and cygwin64) package of
>
>w32api-headers
>w32api-runtime
>
> should be stripped of any ddk-related items, as they can't actually be
> mixed with the usable-from-cygwin user mode w32 items?
>
>
On 4/29/2013 14:40, Denis Excoffier wrote:
> Hello!
>
> I tried the 20130424 snapshot and obtained the following Windows message
> (in pop-up and translated from french):
>
> bash: CreateSymbolicLinkW not found in KERNEL32.DLL
>
>
> Therefore, i keep the plain 1.7.18 running:
>
> % cat /proc/v
On 4/30/2013 03:57, Denis Excoffier wrote:
> The pop-up is produced even before login, presumably during the load of
> "bash --login -i" (but i also have /bin/bash in /etc/passwd, so this may also
> be the reason).
>
> I don't understand why a symlink is created during login, but in any case,
> on
On 6/10/2013 09:11, Lord Flaubert Steve Ataucuri Cruz wrote:
> Folks,
>
> I did some research at mailing list, faq and I didn't seek any
> information about this error . I am trying to build an installer of
> some great tools of linux to windows, but I wanna use and Cygwin
> runtime and Mingw(plea
Version 4.7.3-1 of gcc has been uploaded. Some important notes are:
* gcc-3.x is now finally removed, replaced by this version.
* This means -mno-cygwin support is also removed completely, use the
provided cross compilers to build Windows code.
* Previous gcc4-4.5.3 has been renamed to gcc and p
On 7/2/2013 20:00, Ryan Johnson wrote:
> On 02/07/2013 6:26 AM, JonY wrote:
>> Version 4.7.3-1 of gcc has been uploaded. Some important notes are:
>>
>> * gcc-3.x is now finally removed, replaced by this version.
>>
>> * This means -mno-cygwin support is
On 7/9/2013 05:50, Ken Brown wrote:
> On 7/8/2013 4:37 PM, David Stacey wrote:
>> On 08/07/13 21:23, Denis Excoffier wrote:
>>> On 2013-07-08 02:54, Chris Sutcliffe wrote:
>Hi All,
>
>I'm having a problem trying to update
>mingw64-x86_64-runtime-3.0b_svn5935-1 in that with every
On 7/10/2013 06:35, Angelo Graziosi wrote:
> Setup.exe has updates (4.5.3 ==> 4.7.3) for mingw64-i686-gcc-core but
> not for other language (fortran, g++ etc.).
>
> Beside this, it wants install mingw64-i686-gcc-debuginfo.. Usually
> *debuginfo packages are optional not mandatory.. Or not?
>
It
On 7/10/2013 17:52, JonY wrote:
> On 7/10/2013 06:35, Angelo Graziosi wrote:
>> Setup.exe has updates (4.5.3 ==> 4.7.3) for mingw64-i686-gcc-core but
>> not for other language (fortran, g++ etc.).
>>
>> Beside this, it wants install mingw64-i686-gcc-debuginfo.. Usua
On 7/11/2013 06:12, Christian Franke wrote:
>
> If #pragma pack(1) is used instead, it works as expected also with
> i686-w64-mingw32-gcc 4.7.3.
>
> (Upstream?) bug ?
>
Likely, there are no cygwin specific patches applied for it, please
check with gcc-help.
Thanks.
signature.asc
Descripti
On 7/11/2013 06:28, JonY wrote:
> On 7/11/2013 06:12, Christian Franke wrote:
>>
>> If #pragma pack(1) is used instead, it works as expected also with
>> i686-w64-mingw32-gcc 4.7.3.
>>
>> (Upstream?) bug ?
>>
>
> Likely, there are no cygwin specific pa
Version 3.0b_svn5935-1 of "w32api" has been uploaded.
This version of w32api is based on mingw-w64 headers and libraries for
the Cygwin toolchain and should be compatible with previous versions.
Cygwin packagers, please test your applications.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
This update includes:
Update:
mingw64-*-headers-3.0b_svn5935-1
mingw64-*-runtime-3.0b_svn5935-1
mingw64-*-gcc-4.7.3-1
mingw64-*-pthreads-20100619-5
New:
mingw64-*-winpthreads-3.0b_svn5935-1
*** NOTES ***
For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
now default, for be
On 7/13/2013 17:46, Florent Monnier wrote:
> Hi,
> One week ago a project compiled under Cygwin with CC defined as bellow
> was compiling just fust fine,
> CC = c:/cygwin/bin/i686-w64-mingw32-gcc.exe
>
> But since yesterday, after a cygwin update, I get the following error:
>
> Fatal error: Error
On 7/13/2013 22:25, Florent Monnier wrote:
> + flexlink -chain mingw -stack 16777216 -o .\dllsdl2_stubs.dll
> sdlinit_stub.o sdlquit_stub.o sdlrect_stub.o sdlblendMode_stub.o
> sdlsurface_stub.o sdlwindow_stub.o sdlrender_stub.o sdltexture_stub.o
> sdlpixel_stub.o sdlevent_stub.o sdlkeyboard_stub.o
On 7/17/2013 17:12, Altgr wrote:
> Florent Monnier gmail.com> writes:
>
>>
>> But since yesterday, after a cygwin update, I get the following error:
>>
>> Fatal error: Error while reading:
>> C:/cygwin/usr/i686-w64-mingw32/sys-root/mingw/lib/libmoldname.a:
>> end-of-file
>>
>> Does someone know
Version 3.0b_svn5935-2 of "mingw64-i686-runtime" and
"mingw64-x86_64-runtime" has been uploaded.
The only change from the -1 release is the addition of the -headers
package as dependency that was accidentally omitted in the last release.
mingw64-* gcc should install correctly again for fresh inst
On 7/23/2013 07:51, Richard H Lee wrote:
> I'm trying to compile the following basic program on cygwin64:
>
> int main() {
> ;
> return 0;
> }
>
> But I get the following errors:
>
> $ gcc test.c
> /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -ladvap
hanging Python module order around
>> makes the problem go away for a little while.
>>
>> The right fix for libgcc looks something like this:
>
> Good catch! Any chance you could send this upstream?
>
> JonY, do you have any spare cycles to create new 32 and 64 bit gcc
>
On 7/25/2013 18:18, JonY wrote:
> On 7/25/2013 17:17, Corinna Vinschen wrote:
>> On Jul 25 01:36, Daniel Colascione wrote:
>>> On 7/25/2013 12:11 AM, Daniel Colascione wrote:
>>>> On 7/24/2013 11:55 PM, Daniel Colascione wrote:
>>>>> Does that help at a
On 7/25/2013 23:14, Christopher Faylor wrote:
>
> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
>
> Are there outstanding patches that need attention? If so, please send URLs
> from the gcc-patches archive here so that I can attend to them.
>
This libgcc patch, and
On 7/26/2013 01:20, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 12:10:17AM +0800, JonY wrote:
>> On 7/25/2013 23:14, Christopher Faylor wrote:
>>>
>>> I'm still a (silent) gcc maintainer so I can presumably accept this patch.
>>>
>>> Are
On 7/26/2013 13:02, Yaakov (Cygwin/X) wrote:
> On 2013-07-12 05:33, JonY wrote:
>> For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
>> now default, for better MSVC compatibility. This may cause ABI changes
>> in libraries that expose data structure
On 7/26/2013 17:45, JonY wrote:
> On 7/26/2013 13:02, Yaakov (Cygwin/X) wrote:
>> On 2013-07-12 05:33, JonY wrote:
>>> For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
>>> now default, for better MSVC compatibility. This may cause ABI changes
&
On 7/29/2013 20:19, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
>> The above warning appears when -Wmissing-include-dirs is in effect (and
>> aborts compilation if -Werror is also given). The missing include path
>> seems to be produced by the following compiler spec:
>>
>> %(cpp_cpu) [...
Hi,
After removing 4.8-cmodel-medium.patch and 4.8-duplicate-symbols.patch
for 32bit cygwin, 2nd stage libgcc fails with spawn error, "C compiler
cannot create executables".
Running the compile command manually does show it running cc1, but hangs
indefinitely, adding -v causes it to emit xgcc: er
2api when
> cross building on Fedora), so the libs are taken from the w32api-runtime
> package. However, the compiler uses the default crt file
> /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o which is provided
> by the mingw-crt package.
>
> This is a bug in Cygwin's
On 7/31/2013 18:47, Corinna Vinschen wrote:
> On Jul 31 12:28, Corinna Vinschen wrote:
>> On Jul 31 18:13, JonY wrote:
>>> On 7/31/2013 17:59, Corinna Vinschen wrote:
>>>> On Jul 31 12:55, Pavel Fedin wrote:
>>>>> /usr/x86_64-w64-mingw32/
On 7/31/2013 19:49, Corinna Vinschen wrote:
> On Jul 31 19:31, JonY wrote:
>> On 7/31/2013 18:47, Corinna Vinschen wrote:
>>> Erm... hang on. On second thought, I'm not sure that this is a bug.
>>> The actual bug here was clearly in the Cygwin utils Makefile.
>
Version 1.14-1 of lzip and lziprecover has been uploaded for both 32bit
and 64bit Cygwin.
lzip is an alternative to the bzip2 compressor. lziprecover is
responsible for fixing corrupted lzip compressed files.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from
libmangle is a library that decodes Visual Studio style C++ name
mangling into human readable names.
gendef is a tool to generate exports definitions by analyzing DLLs.
Functions with stdcall call conventions are automatically decorated.
It also supports both win32 and win64 DLLs.
These packages
On 9/1/2013 19:26, nu774 wrote:
> It seems that mingw64-*-gcc-g++ package is not compiled with
> --enable-pthread, that results in no c++11 threading support.
> Is it intentional, or is it possible to enable it?
> As far as I understand, c++11 threading support can be enabled by
> libwinpthread of
On 9/7/2013 00:36, na...@notthisway.com wrote:
> Hi,
>
> I am trying to get the mingw64 build chain using cygwin, but when I run
> setup and locate the correct packages, there is no bin available for
> mingw64-i686-gcc. It only allows me to get src. Can anyone point me in
> the right direction for
Hi,
Seems like there is a duplicate definition of TRANSACTION_ALL_ACCESS and
THREAD_INFORMATION_CLASS, found by one of the msys2 developers.
See attached log.
c++wrap -ggdb -pipe
-fdebug-prefix-map=/work/build32/runtime-stable=/usr/src/debug/msys
-fdebug-prefix-map=/work/Cygwin=/usr/src/debug/m
On 9/10/2013 16:44, Kai Tietz wrote:
> 2013/9/10 JonY:
>> Hi,
>>
>> Seems like there is a duplicate definition of TRANSACTION_ALL_ACCESS and
>> THREAD_INFORMATION_CLASS, found by one of the msys2 developers.
>>
>> See attached log.
>
> I can't see
gcc-9.2.0-1 has been uploaded for Cygwin. This version is for testing.
Known issues:
* ADA support is still broken, even for x86_64.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in
On 2/1/20 6:34 PM, Steven Penny wrote:
> On Wed, 8 Jan 2020 13:38:17 +0000, JonY wrote:
>> gcc-9.2.0-1 has been uploaded for Cygwin. This version is for testing.
>
> https://cygwin.com/ml/cygwin/2020-01/msg00077.html
>
> Any chance of an update for these?
>
>
gcc-9.2.0-2 has been uploaded for Cygwin. This version is the same as
-1, just repackaged and marked as stable.
Known issues:
* ADA support has been dropped, select version 7.4.0-1 if ADA support is
still needed.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe
On 2/24/20 8:21 PM, Achim Gratz wrote:
> JonY writes:
>> gcc-9.2.0-2 has been uploaded for Cygwin. This version is the same as
>> -1, just repackaged and marked as stable.
>
> This version of gcc requires a newer binutils than defined as current in
> the Cygwin repo, so u
The following packages have been uploaded to the Cygwin distribution:
* binutils-2.34
This version was tested by building gcc-9.2.0.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in
The mingw-w64 cross compilers have been updated:
* mingw64-i686-gcc-9.2.0-1
* mingw64-x86_64-gcc-9.2.0-1
*** 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 mess
The mingw-w64 cross compilers have been updated:
* mingw64-i686-binutils-2.34-1
* mingw64-x86_64-binutils-2.34-1
*** 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 th
On 2/29/20 7:23 PM, Marco Atzeri wrote:
> Am 26.02.2020 um 11:35 schrieb JonY:
>> The following packages have been uploaded to the Cygwin distribution:
>>
>> * binutils-2.34
>>
>> This version was tested by building gcc-9.2.0.
>>
>
> It seems there is
On 3/1/20 11:00 AM, Marco Atzeri wrote:
>>
>> Last file checked: /lib/libpthread.a
>>
>> Is that correct? Do you have the complete command line? Is this
>> happening on both archs or just i686?
>>
>
> both archs.
> The error is likely coming from libtool and it is valid for all the 3
> libraries "
On 3/4/20 8:59 AM, Joachim Metz wrote:
> I maintain numerous projects, as part of that I've set up CI tests that use
> current Cygwin 32-bit and 64-bit. Recently I've noticed that builds were
> failing with errors like:
>
> https://ci.appveyor.com/project/libyal/libfwsi/build/job/7b822r4j4ghfs2m5#
gcc-9.2.0-3 has been uploaded for Cygwin. This version is the same as
-2, but rebuilt with ISL updated.
Known issues:
* ADA support has been dropped, select version 7.4.0-1 if ADA support is
still needed.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the
The mingw-w64 cross compilers have been updated:
* mingw64-i686-gcc-9.2.0-2
* mingw64-x86_64-gcc-9.2.0-2
These are the same as -1, but rebuilt with ISL updated.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the
On 3/9/20 9:01 PM, Simon Marchi wrote:
>> Hello libtool folks,
>> Any ideas about this? Something confused the file magic command?
>> dlltool --identify does show libdl.a is associated with cygwin1.dll for
>> example.
>
> Hi,
>
> I stumbled on this and dug into libtool, here's what I found.
>
>
I have just updated the mingw-w64 headers, runtime, and winpthreads to
4.0.6-1.
mingw64-*-headers-4.0.6-1
mingw64-*-runtime-4.0.6-1
mingw64-*-winpthreads-4.0.6-1
Here are some of the notable fixes:
* Fix scanf memleak
* mkstemp should no longer delete files if file handle is closed.
* call _fpres
On 4/14/2016 21:52, Corinna Vinschen wrote:
>
> This is actually a problem in libstdc++-v3. On platforms missing
> certain long double functions libstdc++-v3 is built with stub functions
> using the same name.
>
> Jon, any chance to rebuild the gcc packages ASAP?
>
Already on it, uploads shoul
gcc-5.3.0-5 has been uploaded for Cygwin, now rebuilt with cygwin 2.5.0.
Now actually built with cygwin 2.5.0.
GCC5 uses a new versioning scheme, under the old scheme, it would be
5.0.3, with 5.2.0 as 5.0.2. See https://gcc.gnu.org/develop.html under
"Version Numbering Scheme for GCC 5 and Up".
T
On 4/26/2016 01:46, Marco Atzeri wrote:
> Visible on 32bit and not present on 64bit
>
> $ cat uuid.c
> #include
>
> int main ()
> {
> uuid_t out;
> uuid_generate_random(out);
> return 0;
> }
>
>
> $ gcc uuid.c -luuid
> /tmp/ccLlmFMf.o:uuid.c:(.text+0x16): undefined reference to
> `
On 4/26/2016 20:10, Marco Atzeri wrote:
>
>
> On 26/04/2016 12:16, JonY wrote:
>> On 4/26/2016 01:46, Marco Atzeri wrote:
>>> Visible on 32bit and not present on 64bit
>>>
>>> $ cat uuid.c
>>> #include
>>>
>>> i
On 4/27/2016 05:08, Lee wrote:
> Questions:
>
> How to tell if I should be using libwinpthread or pthread? I had no
> idea so installed both:
> /usr/i686-w64-mingw32/sys-root/mingw/bin
> $ ls -l *hread*
> -rwxr-xr-x 1 root None 47635 Apr 7 08:54 libwinpthread-1.dll
> -rwxr-xr-x 1 root None 65024
On 4/27/2016 08:32, Lee wrote:
> On 4/26/16, JonY wrote:
>> On 4/27/2016 05:08, Lee wrote:
>>> Questions:
>>>
>>> How to tell if I should be using libwinpthread or pthread? I had no
>>> idea so installed both:
>>> /usr/i686-w64-mingw32/sys-ro
gcc-5.3.0-5 has been uploaded for Cygwin, it should now scan /usr/lib
ahead of /usr/lib/w32api.
GCC5 uses a new versioning scheme, under the old scheme, it would be
5.0.3, with 5.2.0 as 5.0.2. See https://gcc.gnu.org/develop.html under
"Version Numbering Scheme for GCC 5 and Up".
This version has
Version 1.18-1 of lzip and lziprecover has been uploaded for both 32bit
and 64bit Cygwin.
lzip is an alternative to the bzip2 compressor. lziprecover is
responsible for fixing corrupted lzip compressed files.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from
gcc-5.4.0-1 has been uploaded for 32bit and 64bit Cygwin and marked as
stable.
This version has been built with
--with-default-libstdcxx-abi=gcc4-compatible so it should remain
compatible to GCC 4 C++ ABI.
Note that C11 with gnu extensions is now default for C. See
https://gcc.gnu.org/gcc-5/porti
I have just updated the mingw-w64 cross compilers Cygwin 32bit and 64bit.
This version is considered testing and has --enable-vtable-verify set.
I'd consider moving it to stable if it can build non-trivial C++
applications.
PLEASE RECOMPILE ALL YOUR C++ CODE FOR ABI COMPATIBILITY
The c
On 8/6/2016 14:58, Tony Kelman wrote:
> 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/view
On 8/8/2016 07:48, Yaakov Selkowitz wrote:
> On 2016-08-05 18:15, JonY wrote:
>> I have just updated the mingw-w64 cross compilers Cygwin 32bit and 64bit.
>>
>> This version is considered testing and has --enable-vtable-verify set.
>> I'd consider moving it to stab
I have just updated the mingw-w64 cross compilers Cygwin 32bit and
64bit to mingw64-*-gcc-5.4.0-2.
Unlike the Cygwin gcc, this version DOES NOT PRESERVER C++ ABI from
gcc4. Please rebuild all your C++ libraries.
PLEASE RECOMPILE ALL YOUR C++ CODE FOR ABI COMPATIBILITY
The cross compile
On 8/16/2016 15:57, Tony Kelman wrote:
>> 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
> di
On 8/18/2016 08:19, Tony Kelman wrote:
>> 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 an
On 8/18/2016 20:08, Tony Kelman wrote:
>> 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
On 8/20/2016 05:54, Yaakov Selkowitz wrote:
> On Thu, 2016-08-18 at 07:13 +0800, JonY wrote:
>> Yaakov,
>>
>> Can you restore 4.9.2-2 as previous? Thanks.
>
> Done. Once calm next runs, 4.9.2-2 will be previous, 5.4.0-2 current,
> and the previous 5.x t
On 8/20/2016 02:59, Tony Kelman wrote:
>> 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/Ju
On 8/29/2016 10:06, Whek rin wrote:
> The utility x86_64-w64-mingw32-ld from package mingw-x86_64-binutils
> cannot by default find libraries from the path
> /usr/x86_64-w64-mingw32/sysroot/mingw/lib, where the package
> mingw64-x86_64-runtime installs them. I believe this is a build
> configuratio
I have just updated the mingw-w64 headers, runtime, and winpthreads to
5.0.0-1.
mingw64-*-headers-5.0.0-1
mingw64-*-runtime-5.0.0-1
mingw64-*-winpthreads-5.0.0-1
The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_
I have just updated the mingw-w64 cross compilers Cygwin 32bit and
64bit to mingw64-{i686,x86_64}-gcc-5.4.0-3.
This version uses POSIX threads to support C++11 std::thread, as a
consequence, require winpthreads.
Unlike the Cygwin gcc, this version DOES NOT PRESERVER C++ ABI from
gcc4. Please rebu
On 11/11/2016 22:06, Tony Kelman wrote:
>> 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
I have just updated the mingw-w64 headers, runtime, and winpthreads to
5.0.1-1.
mingw64-*-headers-5.0.1-1
mingw64-*-runtime-5.0.1-1
mingw64-*-winpthreads-5.0.1-1
The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_
gcc-6.3.0-1 has been uploaded for Cygwin. This version is for testing.
This version has been built with
--with-default-libstdcxx-abi=gcc4-compatible so it should remain
compatible to GCC 4 C++ ABI.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwi
On 01/26/2017 10:30 AM, Christian Franke wrote:
> After upgrading to gcc test version 6.3.0-1, C++ exception handling is
> broken if DLL version of new libstdc++6 is used.
>
Noted, I'll consider the test version broken for now.
signature.asc
Description: OpenPGP digital signature
On 01/25/2017 09:26 AM, Václav Haisman wrote:
> On 9 February 2016 at 15:23, Václav Haisman wrote:
>> On 19 May 2015 at 10:52, Václav Haisman wrote:
>>> On 19 January 2015 at 15:42, Václav Haisman wrote:
Hi.
I have hit an issue with thread-local storage variables on
Cygwi
On 02/20/2017 03:32 PM, Tony Kelman wrote:
> My email client is not letting me bottom post this or send it in
> plaintext, so the list might reject it. There's now a patch that
> works at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333#c17, are
> you equipped to run the gcc test suite?
>
Do yo
I have just updated the 32bit mingw-w64 cross compilers Cygwin 32bit and
64bit to mingw64-i686-gcc-5.4.0-4.
This new update contains a patch by Martin Jambor to fix stack
adjustments on i686:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333#c17
PLEASE RECOMPILE ALL YOUR C++ CODE FOR ABI CO
301 - 400 of 503 matches
Mail list logo
