On 06/05/2013 17:41, Jason Merrill wrote:
> On 05/05/2013 09:57 AM, Dave Korn wrote:
>> This sounds like a bad idea to me, and not just because the locking
>> mechanism is dodgy. Is the problem more widespread than just your laptop?
>> Does it affect other host OSs? Linking
On 01/05/2013 03:02, Jason Merrill wrote:
> Since GNU Make doesn't support anything like the .MUTEX directive
> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=17873), and
> accidentally doing "make -j8 -l4" makes my laptop useless for several
> minutes while it tries to link all the front e
On 22/04/2013 13:51, Angelo Graziosi wrote:
> Il 16/04/2013 10.10, Dave Korn ha scritto:
>>This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
>
>
> From comment 5 and 9 something should be fixed but with current
> snapshot, 4.9-20130421, it seems that the bu
On 17/04/2013 19:59, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:32, Dave Korn wrote:
>> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>>> Your boehm-gc patch can replace my java-libgc-win32.patch, provided it
>>> works properly.
>>
>>It appears to, l
On 18/04/2013 21:50, Vladimir Makarov wrote:
> On 04/17/2013 11:18 PM, Shiva Chen wrote:
>> Full test2.c.209r.reload is about 296kb and i can't send successfully.
>> Is there another way to send the dump file?
>>
> Did you try to compress it? Another possibility would be send dump only
> for the p
On 16/04/2013 14:25, Warren Young wrote:
> On 4/11/2013 14:38, Dave Korn wrote:
>>
>> The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is
>> missing in 2.1.0-1(**), was that intentional?
>
> I think I got that, um, "feature" for free w
On 15/04/2013 15:50, Angelo Graziosi wrote:
> The current snapshot [*] fails to build on Cygwin as follow:
> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
> error: unrecognizable insn:
> }
> ^
> (insn 15 14 16 5 (set (reg:SI 63)
> (symbol_ref:SI ("GetModuleHandleA@4
On 16/04/2013 07:55, Dave Korn wrote:
> On 16/04/2013 07:05, Dave Korn wrote:
>> On 15/04/2013 15:50, Angelo Graziosi wrote:
>
>>> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
>>> error: unrecognizable insn:
>>> }
>
On 16/04/2013 07:05, Dave Korn wrote:
> On 15/04/2013 15:50, Angelo Graziosi wrote:
>> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
>> error: unrecognizable insn:
>> }
>> ^
>> (insn 15 14 16 5 (set (reg:SI 63)
>> (symbol_ref
On 15/04/2013 15:50, Angelo Graziosi wrote:
> The current snapshot [*] fails to build on Cygwin as follow:
> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c: In
> function ‘__gcc_register_frame’:
> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:106:19:
> warning: array s
On 15/04/2013 18:14, Christopher Faylor wrote:
> On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:
>> Some notes on the above:
>>
>> The same happens with both the previous version and current snapshot of the
>> cygwin dll. It also happens with both
On 13/04/2013 15:49, Corinna Vinschen wrote:
> On Apr 13 12:39, Andy Koppe wrote:
>> On 13 April 2013 10:03, Corinna Vinschen wrote:
>>> On Apr 13 06:55, Andy Koppe wrote:
I'm struggling to get setup.hint generation to work. Is it supported
with cygport 0.11.3 as currently in the distros?
On 13/04/2013 11:07, Corinna Vinschen wrote:
> On Apr 12 21:31, Dave Korn wrote:
>> Nope, just vague about input and output sections. Enabling auto imports
>> selects a linker script that causes all the .rdata in the input object files
>
> Out of curiosity, which
On 12/04/2013 19:47, Janne Blomqvist wrote:
> As I don't have a Windows system to test on, I would appreciate if somebody
> more familiar with that platform could take a quick look. In particular, I
> *think* it should be Ok to use win32 API functions on Cygwin (that is,
> cygwin-gcc ships the win
On 12/04/2013 16:57, Corinna Vinschen wrote:
> Dave? Ping?
Heh, don't panic, I'm still here! Just needed some sleep :)
> On Apr 11 15:37, Corinna Vinschen wrote:
>> On Apr 11 12:16, Corinna Vinschen wrote:
>>> On Apr 10 18:16, Corinna Vinschen wrote:
>&g
On 12/04/2013 11:44, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 23:24, Dave Korn wrote:
> Most of the discussed features are already in the latest release. Right
> now, the major difference between the release and git master is full
> support for x86_64-pc-cygwin, but there are a num
On 11/04/2013 21:42, Thomas Wolff wrote:
> Am 11.04.2013 14:34, schrieb Dave Korn:
>> Also, I don't plan on doing it unless there's significant demand.
> I would appreciate to keep it as gcc-3.
Fancy being the maintainer for it then? ;-)
> The reason is quite pecu
On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:32, Dave Korn wrote:
>> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>>> Also in the 4.8 branch is a patch to unversion the LTO plugin; it
>>> applies to 4.7 as well.
>>
>> I'll take
On 12/04/2013 00:36, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:35, Dave Korn wrote:
>> On 11/04/2013 13:22, NightStrike wrote:
>>> Speaking of which.. 4.8 is out...
>
> So is GNOME 3.8.0, but I tend to let others deal with the early bugs and
> catch up by
On 12/06/2012 13:31, Warren Young wrote:
> PACKAGE DESCRIPTION
> ===
>
> Homepage: http://sourceforge.net/projects/expat/
> License : MIT-like
>
> Expat is a C library for parsing XML, originally created and maintained
> by James Clark, but since 2001 taken over by a loose group o
On 11/04/2013 00:58, Dave Korn wrote:
> I would like to express my gratitude to JonY for stepping into the breach
> caused by my absence from the Cygwin community and releasing the first test
> version of GCC 4.7 series. He did a very difficult job and did it well and
> deserves th
On 11/04/2013 13:22, NightStrike wrote:
> Speaking of which.. 4.8 is out...
Point. Anyone got any particular preference whether I go for a 4.7.3 or
4.8.0 release next? Maybe do a 4.7.3 curr: and then a 4.8.0 test: package?
cheers,
DaveK
On 11/04/2013 13:19, Corinna Vinschen wrote:
>>>> On 2013-04-11 01:02, Dave Korn wrote:
>>>>> Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was
>>>>> using
>>>>> it and wants to know where it's gone.
On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 01:02, Dave Korn wrote:
>> Yes, I've looked at most of your patches already, I'm not saying there's
>> any complication in adding them, it's just that I didn't want to wait
>> another how
On 11/04/2013 11:13, Corinna Vinschen wrote:
> On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
>> On 2013-04-11 01:02, Dave Korn wrote:
>>> Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was
>>> using
>>> it and wants to know where
On 11/04/2013 03:44, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 20:40, Dave Korn wrote:
>>Surely there'll be a problem if the curr: version of everything
>> else goes to 4.7.3-1 but there's no matching version of libffi4?
>
> Not as long as 4.5.3-3-src remains
On 11/04/2013 07:08, Duncan Roe wrote:
> Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc &
> alternatives.
Glad to hear it!
> I put them there because I like to have the odd cygwin utility available
> to CMD.EXE.
>
> May put them back - but will take more care with them i
On 11/04/2013 05:47, Christopher Faylor wrote:
> On Thu, Apr 11, 2013 at 02:21:00AM +0100, Dave Korn wrote:
>> On 11/04/2013 02:05, Dave Korn wrote:
>>> On 11/04/2013 01:18, Christopher Faylor wrote:
>>>> gcc won't be available until this is fixed.
>>&
On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 11:56, Dave Korn wrote:
>>It takes 11 hours on a triple-core machine at -j6 to build and
>> package GCC.
>> In order to guarantee consistent reproduction I always respin the built
>> package fr
On 11/04/2013 06:12, Duncan Roe wrote:
> Thanks guys for the pointers to cygmpfr-4.dll. Got it.
>
> This problem with headers started happening on an old installation so I
> reinstalled but it still happens:
> ignoring nonexistent directory "/usr/include"
> strerror.c:2:19: error: no include pat
On 11/04/2013 02:57, Duncan Roe wrote:
> I have just installed cygwin on this system.
> When I try to compile a small program, I get this error:
>
> /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared
> libraries: cygmpfr-4.dll: cannot open shared object file: No such file
> or d
On 11/04/2013 02:33, Yaakov (Cygwin/X) wrote:
> After applying my libffi-noinst.patch, all you really need to do is
> remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro
> until all libffi-dependent packages are rebuilt (most of which are mine).
Surely there'll be a problem i
On 11/04/2013 02:05, Dave Korn wrote:
> On 11/04/2013 01:18, Christopher Faylor wrote:
>> gcc won't be available until this is fixed.
>
> Oops. I'll just edit it on the server. Sorry for the inconvenience.
Should be ok now I trust. Apologies once more, I've
:
gcc4-java: Requires libgcj13.
gcc4-objc: Requires libobjc4.
gcc4-ada: Requires libgnat4.7.
gcc4-fortran: Requires libquadmath0, libquadmath0-devel.
libgfortran3: Requires libquadmath0.
Cygwin port maintained by: Dave Korn
Please address all questions to the main Cygwin mailing list.
This
:
gcc4-java: Requires libgcj13.
gcc4-objc: Requires libobjc4.
gcc4-ada: Requires libgnat4.7.
gcc4-fortran: Requires libquadmath0, libquadmath0-devel.
libgfortran3: Requires libquadmath0.
Cygwin port maintained by: Dave Korn
Please address all questions to the main Cygwin mailing list.
This
On 11/04/2013 01:18, Christopher Faylor wrote:
> gcc won't be available until this is fixed.
Oops. I'll just edit it on the server. Sorry for the inconvenience.
cheers,
DaveK
On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 04:29, Corinna Vinschen wrote:
>> On Apr 10 04:06, Yaakov (Cygwin/X) wrote:
>>> libffi development moved out of GCC into a separate project a long
>>> time ago; the copy included in GCC is used for libgcj, but only as a
>>> convenience (
On 10/04/2013 16:47, Christopher Faylor wrote:
> It isn't clear to me why we'd be spending days discussing this when
> presumably the patches apply without too much effort. Some of the
> patches here:
>
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
>
> look worthwh
On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
> Could you explain the necessity of the dllimport's in the same patch?
The idea is to one day be able to move away from having auto-import enabled
by default in binutils, so that .rdata can go back into the read-only-mapped
.rdata section and be sh
On 09/04/2013 11:37, Kai Tietz wrote:
> Hmm, well in standard-case you are right. But well there is still a
> chance that GetProcAddress returns NULL-pointer ...
How would that actually happen? Removing any of those functions from libgcc
or libjava would be a very serious ABI breakage; we'r
Hi all,
I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back
to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
work and restores java and libffi. I've also been running the testsuite over
the last few days and the results look quite reason
On 09/04/2013 11:30, Yaakov (Cygwin/X) wrote:
> On 2013-04-09 02:08, Dave Korn wrote:
>> On 25/03/2013 08:52, Corinna Vinschen wrote:
>>> On Mar 24 03:33, Yaakov (Cygwin/X) wrote:
>>>> In any case, the error is a result of adding one of Dave Korn's
&g
On 25/03/2013 08:52, Corinna Vinschen wrote:
> On Mar 24 03:33, Yaakov (Cygwin/X) wrote:
>> In any case, the error is a result of adding one of Dave Korn's patches:
>>
>> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.
On 22/03/2013 08:44, Kai Tietz wrote:
> 2013-03-22 Kai Tietz
>
> * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
> (__deregister_frame_info): Likewise.
Hi Kai,
I read your explanation of the problem relating to x86-64 memory models over
on the Cygwin de
On 07/04/2013 19:50, Christopher Faylor wrote:
> On Sun, Apr 07, 2013 at 06:16:17PM +, Gene wrote:
>> save: fork_level=1 SetHandleInformation() failed: fd 0 handle 0x3 type
>> 2: Th e parameter is incorrect.
>
> That error message doesn't seem to be coming from Cygwin. I have
> grepped the C
Hi list,
I always used to use du with the -cxhs options, but since updating to the
latest (8.15-1) version there appears to be a problem caused by -x:
> $ ls -la
> total 392188
> drwxr-xr-x+ 1 DKAdmin None 0 Apr 6 00:35 .
> drwxr-xr-x+ 1 DKAdmin None 0 Apr 3 05:58 ..
> dr
On 05/04/2013 18:07, Dave Korn wrote:
> On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote:
>> On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote:
>>> And the reroll failed to build because of the problem JonY ran into with
>>> java. Turns out that libjava keys off the pre
On 05/04/2013 20:52, Ryan Johnson wrote:
> On 05/04/2013 3:07 PM, Angelo Graziosi wrote:
>> Dave Korn wrote:
>>> Did you install the manually-required runtime libs as well?
>>
>> I don't understand here. I have installed GCC-4.7.2-1 with setup.exe
>> choo
On 05/04/2013 12:22, Angelo Graziosi wrote:
> Just for completeness...
>
> This morning I have installed the test release of GCC-4.7 (4.7.2-1) and
> after that a few applications do not work any more.
>
> For example, Terminator, installed via Cygwinports, does not start. From
> command line I ha
On 02/04/2013 16:27, Achim Gratz wrote:
> I've added test packages compiled with gcc-4.7.2-1 (to be installed by
> manually selecting them, like the test version of gcc itself):
>
> wget="wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release";
Is there some access permission I would need to
On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote:
> On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote:
>> And the reroll failed to build because of the problem JonY ran into with
>> java. Turns out that libjava keys off the presence of pthread_getattr_np
>> (added to the D
On 04/04/2013 08:48, Kai Tietz wrote:
Hi Kai,
> That change is intentional and would be called __thiscall. To mix
> stdcall and regparam is no more supported AFAIK.
Why are stdcall and regparam not allowed together any more? They seem
entirely orthogonal to me, and the overall result is
Hi list,
Previously (tested with gcc-4.5.3), constructs like this:-
-- foo.h
struct sigpacket
{
int __stdcall process () __attribute__ ((regparm (1)));
};
-- foo.cpp
#include "foo.h"
int __stdcall
sigpacket::process ()
{
return 2;
}
--
... used to work, wi
On 01/04/2013 09:56, Dave Korn wrote:
> Hi Yaakov et al.,
>
> I'm confused by the output from cygport (0.11.3) when building GCC. During
> the packaging step, after the final binary package from PKG_NAMES has been
> tarballed, I see:
>
>> *** Info: No de
Hi Yaakov et al.,
I'm confused by the output from cygport (0.11.3) when building GCC. During
the packaging step, after the final binary package from PKG_NAMES has been
tarballed, I see:
>
> *** Info: No debug files, skipping debuginfo subpackage
>
Checking packages for missing or d
Hi folks,
There are a lot of broken entries in the lower levels of the package list on
the website. Clicking a package name at http://cygwin.com/packages/ takes you
to the page that lists the available binary and source package versions, as
before, but attempting to follow the link to one
On 28/03/2013 15:18, Dave Korn wrote:
> On 28/03/2013 14:05, Dave Korn wrote:
>
>> Righto. Will upload as soon as I've finished running setup ;)
>
> Argh. Gotta re-roll the packaging step as I forgot to commit some of the
> setup.hint reversions to my local
On 28/03/2013 14:05, Dave Korn wrote:
> Righto. Will upload as soon as I've finished running setup ;)
Argh. Gotta re-roll the packaging step as I forgot to commit some of the
setup.hint reversions to my local svn. D'oh, but at least I spotted it before
uploading.
cheers,
DaveK
On 28/03/2013 13:39, Corinna Vinschen wrote:
> On Mar 28 13:25, Dave Korn wrote:
>> I've realised that I should re-roll the release after updating to the
>> latest
>> cygport, as I don't yet have the version with the debuginfo changes, which I
>> assu
On 26/03/2013 11:20, Corinna Vinschen wrote:
> Hi Dave,
>
> On Mar 12 23:50, Dave Korn wrote:
>> On 12/03/2013 22:15, Achim Gratz wrote:
>>> Achim Gratz writes:
>>>> Yaakov (Cygwin/X) writes:
>>>> OK. I won't be able to run the tests for
On 23/03/2013 00:57, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 23/03/2013 00:24, Kai Tietz wrote:
>>> 2013/3/23 Dave Korn :
>>>> On 23/03/2013 00:16, Kai Tietz wrote:
>>>>
>>>>> welcome, too. It would be even better if we could ret
On 23/03/2013 00:41, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 22/03/2013 09:56, Kai Tietz wrote:
>>> Hi,
>>>
>>> this patch adds required configure changes for new cygwin x64
On 23/03/2013 00:27, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 23/03/2013 00:08, Kai Tietz wrote:
>>> 2013/3/23 Dave Korn :
>>>> Also, can you explain the motivation for this change? I don't see how
>>>> it's
>>>> going to
On 23/03/2013 00:24, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 23/03/2013 00:16, Kai Tietz wrote:
>>
>>> welcome, too. It would be even better if we could rethink actual the
>>> need of loading java-library within libgcc's cygwin's/mingw's crt
On 22/03/2013 09:56, Kai Tietz wrote:
> Hi,
>
> this patch adds required configure changes for new cygwin x64 target.
> Index: gcc/configure.ac
> ===
> --- gcc/configure.ac (Revision 196898)
> +++ gcc/configure.ac (Arbeitskopie)
>
On 23/03/2013 00:16, Kai Tietz wrote:
> welcome, too. It would be even better if we could rethink actual the
> need of loading java-library within libgcc's cygwin's/mingw's crtbegin
> at all. I am actual not that sure, if we need this at all.
Somebody has to register the default classes at s
On 23/03/2013 00:08, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> Also, can you explain the motivation for this change? I don't see how it's
>> going to work right; from what I remember, we don't have weak definitions in
>> PE-COFF, just weak references.
On 22/03/2013 09:00, Kai Tietz wrote:
> (CXX_WRAP_SPEC_LIST): Undefine before define.
> @@ -73,6 +82,7 @@
>
> /* To implement C++ function replacement we always wrap the cxx
> malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */
> +#undef CXX_WRAP_SPEC_LIST
> #defin
On 22/03/2013 09:00, Kai Tietz wrote:
> (LIBGCJ_SONAME): Make name minor-build-version dependent.
>
> Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please
> especially a look to LIBGCJ_SONAME change. I think we should include
> MAJOR_VERSION here, too. Ok for apply?
I'm not sur
On 22/03/2013 08:44, Kai Tietz wrote:
> Hi,
>
> this change is actual used by cygwin and is required for upcoming x64
> cygwin target.
>
> ChangeLog
>
> 2013-03-22 Kai Tietz
>
> * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
> (__deregister_frame_info): Like
On 17/03/2013 16:45, Christopher Faylor wrote:
> I'd like to have a feel for how the 64-bit version of Cygwin will
> impact package maintainers.
>
> So, I'd appreciate some discussion about this.
>
> 1) Do you have a 64-bit version of Windows available?
Yes.
> 3) Are you willing to download t
On 16/03/2013 11:57, Jakub Jelinek wrote:
> GCC 4.8.0 Release Candidate available from gcc.gnu.org
>
> The first release candidate for GCC 4.8.0 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.0-RC-20130316
>
> and shortly its mirrors. It has been generated from SVN revision 1966
On 04/03/2013 06:31, Christopher Faylor wrote:
> On Sun, Mar 03, 2013 at 09:54:58PM -0600, Yaakov wrote:
>> Based on your recent commit to cygwin-64bit-branch, are we dropping
>> support for Win2K as well?
>
> Yes.
:-( Gonna have to set up a new dev environment on a new pc
cheers,
On 12/03/2013 08:59, Richard Biener wrote:
> On Tue, Mar 12, 2013 at 2:44 AM, Dave Korn wrote:
>> Hello list,
>>
>> The attached patch makes -shared-libgcc the default for Cygwin. This is
>> something that I should have done some time ago, as shared libgcc on
Hi list,
I'm in the middle of a testsuite run and just saw the following FAILs crop up:
> FAIL: g++.old-deja/g++.brendan/cvt1.C (test for excess errors)
> FAIL: g++.old-deja/g++.brendan/enum11.C (test for excess errors)
> FAIL: g++.old-deja/g++.brendan/enum8.C (test for excess errors)
> FA
On 12/03/2013 22:15, Achim Gratz wrote:
> Achim Gratz writes:
>> Yaakov (Cygwin/X) writes:
>> OK. I won't be able to run the tests for some packages this way, but it
>> sounds like this should provide a workable solution for bootstrapping.
>> I guess we will anyway have to re-compile all packages
o use my target maintainer's discretion to apply
it even at this late stage, but I figure it's so close to RC1 that I should
ask the RM's permission anyway.
I'd also like to backport it to all the currently-open branches.
gcc/ChangeLog
2013-03-12 Dave Korn
* confi
On 12/03/2013 01:02, Dave Korn wrote:
> On 10/03/2013 15:43, Achim Gratz wrote:
>
>> - TLS disabled since it doesn't work with current gcc
>
> I just debugged that over on the mpfr list. It can be made to work by
> adding "LDFLAGS=-shared-libgcc" to your
On 10/03/2013 15:43, Achim Gratz wrote:
> - TLS disabled since it doesn't work with current gcc
I just debugged that over on the mpfr list. It can be made to work by
adding "LDFLAGS=-shared-libgcc" to your configure line.
(I'm going to patch upstream GCC to make that the default, and I'm al
On 11/03/2013 23:40, Yaakov (Cygwin/X) wrote:
> JonY, Achim, and others,
>
> I have updated .cygport and patch files for GCC and its dependencies:
>
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
I'm trying to look at this, but all I get is errors:
> $ git clone g
On 11/03/2013 22:12, JonY wrote:
> 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
>&
On 11/03/2013 23:21, Christopher Faylor wrote:
> On Mon, Mar 11, 2013 at 06:03:08PM +0000, 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
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
>> even if I have selected "Curr" packag
On 08/03/2013 00:11, Jonathan Wakely wrote:
> On 7 March 2013 23:53, Caroline Tice wrote:
>> I believe this patch addresses all of your comments; I modified the
>> configure.ac files to generate the configures, and I fixed the
>> spelling mistakes in the comments. I still get the warnings when
>>
On 07/03/2013 21:00, Andrew Haley wrote:
> Either Anthony or I review libffi patches in gcc.
Perhaps you two should list yourselves as such in MAINTAINERS, for the
avoidance of doubt?
> You're not going to get any more reviews.
I committed it. Thanks for the clarification.
cheers,
On 21/02/2013 19:35, Anthony Green wrote:
> This patch looks fine, thanks. I don't plan to merge back into GCC
> for at least a week or two, so I think you should commit it to the GCC
> tree independently.
Committed to GCC revision 196527. Thanks!
cheers,
DaveK
On 07/03/2013 16:55, Andrew Haley wrote:
> On 03/07/2013 02:09 PM, Dave Korn wrote:
>> On 06/03/2013 16:05, Jakub Jelinek wrote:
>>
>>> If no new P1 appears within a week,
>> I may be about to file one. What priority would "Java doesn't compile on a
>
On 06/03/2013 16:05, Jakub Jelinek wrote:
> If no new P1 appears within a week,
I may be about to file one. What priority would "Java doesn't compile on a
secondary platform" count as? There's a trivial bug in libffi and I already
posted a patch(*) to both -patches and upstream, but am waiti
On 27/02/2013 21:52, Tom Tromey wrote:
> I'm posting this now to get reactions to the probe before cleaning up
> the corresponding gdb patches for submission. I've built it both with
> and without sys/sdt.h, but I haven't yet run the test suite.
How did it build in the without sys/sdt.h case?
On 27/02/2013 19:53, Ludovic Courtès wrote:
> Dave Korn skribis:
>
>> On 26/02/2013 22:07, Ludovic Courtès wrote:
>>
>>> * Makefile.in (LDFLAGS): New variable.
>> "Import from automake" might be more informative.
>
> Automake has not
On 26/02/2013 22:07, Ludovic Courtès wrote:
> * Makefile.in (LDFLAGS): New variable.
"Import from automake" might be more informative.
cheers,
DaveK
On 12/02/2013 16:11, Sebastian Huber wrote:
> This patch from Alan Modra fixes a section type conflict error. See also
>
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02172.html
The Windows part is OK. I ran the g++ testsuite (gcc/, not libstdc) with no
change before and after.
cheers,
On 18/02/2013 11:59, Ryan Johnson wrote:
> On 17/02/2013 10:38 PM, Zach Saw wrote:
>> The following test case fails on Cygwin but passes on Linux (both
>> tested using
>> GCC 4.7.2).
> Cygwin doesn't have a gcc-4.7.2 package yet (not even for testing);
> 4.5.3 is the highest I see this morning in s
On 21/02/2013 19:35, Anthony Green wrote:
> On Thu, Feb 21, 2013 at 2:22 PM, Dave Korn wrote:
>> Gcc-patches: Assuming AG approves, can we commit this without waiting for
>> an
>> upstream libffi release and doing a full merge? Currently GCC HEAD won't
>>
suming AG approves, can we commit this without waiting for an
upstream libffi release and doing a full merge? Currently GCC HEAD won't
build libffi (and hence libjava) without it.
2013-02-21 Dave Korn
* src/closures.c (is_emutramp_enabled [!FFI_MMAP_EXEC_EMUTRAMP_PAX]):
Hi all,
I've got a gcc-4.7.2 package almost ready to upload, but there's one issue
I'm not sure what's best to do about.
Several of the runtime libs have changed version numbers, i.e.
libgnat4.5->libgnat4.7, libgcj11->libgcj13, libobjc2->libobjc4.
I'd like to release a test: version o
On 06/06/2012 11:14, Richard Guenther wrote:
> The first release candidate for GCC 4.7.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606
>
> and shortly its mirrors. It has been generated from SVN revision 188257.
>
> I have so far bootstrapped and tested the releas
On 03/06/2012 04:43, Hans-Peter Nilsson wrote:
> On Fri, 18 May 2012, Ralf Corsepius wrote:
>> On 05/18/2012 09:24 AM, Sebastian Huber wrote:
>>> Hi,
>>>
>>> if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
>>> target, then I get several unexpected errors due to:
>>>
>>> gcc
On 14/04/2012 14:58, Kai Tietz wrote:
> 2012/4/14 Nicolai Josuttis:
>> The first problem was that
>> build/gcc/gengtype-lex.c
>> was created with DOS-Newlines (CR-LF),
>> which makes the following compiling fail:
>> make[2]: Entering directory `/cygdrive/p/gcc480snap-install/build/gcc'
>> gcc -c
On 11/04/2012 20:30, Tobias Burnus wrote:
> In any case, the gfortran front end cannot really afford to loose
> developers, given that it is a hobbyist* project and given that
> attracting new developers is difficult.
>
> Tobias
>
> * In terms of the development; I assume that those who use it f
1 - 100 of 7205 matches
Mail list logo
