On Mar 22 02:23, Yaakov wrote:
> On Mon, 18 Mar 2013 11:09:24 +0100, Corinna Vinschen wrote:
> > On Mar 17 18:49, Yaakov wrote:
> > > On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> > > > I also discovered two more gcc macros which were missing updates for
> > > > x86_64-cygwin. I h
On Mon, 18 Mar 2013 11:09:24 +0100, Corinna Vinschen wrote:
> On Mar 17 18:49, Yaakov wrote:
> > On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> > > I also discovered two more gcc macros which were missing updates for
> > > x86_64-cygwin. I have added those patches, and incorporated
On Mar 20 01:22, Yaakov (Cygwin/X) wrote:
> Unfortunately I missed something last time when I tried fixing ONDEE.
> Patch attached.
I checked it in with a small change. I thought it might look a bit
more clear if all symbols are defined using a REAL_foo define. Please
have a look if that's ok as
On Mar 17 18:49, Yaakov wrote:
> On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> > I also discovered two more gcc macros which were missing updates for
> > x86_64-cygwin. I have added those patches, and incorporated your x86_64
> > patches into mine, into a 4.8 branch of my gcc port
On Sun, 17 Mar 2013 04:18:25 -0500, Yaakov (Cygwin/X) wrote:
> I also discovered two more gcc macros which were missing updates for
> x86_64-cygwin. I have added those patches, and incorporated your x86_64
> patches into mine, into a 4.8 branch of my gcc port:
>
> http://cygwin-ports.git.sourcefo
On Sat, 16 Mar 2013 11:45:15 +0100, Corinna Vinschen wrote:
> > Also, in libstdc++-v3/crossconfig.m4:
> >
> > > + *-cygwin*)
> > > +GLIBCXX_CHECK_COMPILER_FEATURES
> > > +GLIBCXX_CHECK_LINKER_FEATURES
> > > +GLIBCXX_CHECK_MATH_SUPPORT
> > > +GLIBCXX_CHECK_STDLIB_SUPPORT
> > > +
On Mar 15 16:56, Yaakov wrote:
> On Fri, 15 Mar 2013 11:26:55 +0100, Corinna Vinschen wrote:
> > ftp://ftp.cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130305.patch
> >
> > I didn't change anything in the toolchain since then.
>
> This hunk doesn't look right (gcc/config/i386/i386.c):
>
>
On Fri, 15 Mar 2013 11:26:55 +0100, Corinna Vinschen wrote:
> ftp://ftp.cygwin.com/pub/cygwin/64bit/x86_64-pc-cygwin-gcc-20130305.patch
>
> I didn't change anything in the toolchain since then.
This hunk doesn't look right (gcc/config/i386/i386.c):
>if (TARGET_64BIT && DEFAULT_ABI == MS_
On Mar 15 05:18, Yaakov wrote:
> On Tue, 5 Mar 2013 10:38:50 +0100, Corinna Vinschen wrote:
> > What about
> >
> > #if BUILDING_GCC_MAJOR == 4
> > #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
> > #else
> > #error LIBGCJ_SONAME versioning scheme needs attention
> > #end
On Tue, 5 Mar 2013 10:38:50 +0100, Corinna Vinschen wrote:
> What about
>
> #if BUILDING_GCC_MAJOR == 4
> #define LIBGCJ_SONAME "cyggcj-" __cyg_mkstr (BUILDING_GCC_MINOR+6) ".dll"
> #else
> #error LIBGCJ_SONAME versioning scheme needs attention
> #endif
>
> for now?
Nope; this failed in boostrap
On Tue, 5 Mar 2013 10:30:09 +0100, Corinna Vinschen wrote:
> On Mar 5 03:14, Yaakov wrote:
> > No, we don't control the DLL name; libjava/Makefile.am and
> > libjava/libtool-version determine the soname of libgcj based on
> > standard libtool naming and versioning practices. Since GCC 3.2
> > (li
On Mar 5 10:30, Corinna Vinschen wrote:
> On Mar 5 03:14, Yaakov wrote:
> > On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> > > On Mar 5 00:09, Yaakov wrote:
> > > > I don't know if the version changes are a matter of policy or just how
> > > > it has happened, but in any case that'
On Mar 5 03:14, Yaakov wrote:
> On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> > On Mar 5 00:09, Yaakov wrote:
> > > I don't know if the version changes are a matter of policy or just how
> > > it has happened, but in any case that's not the current versioning
> > > scheme, nor is i
On Tue, 5 Mar 2013 09:49:50 +0100, Corinna Vinschen wrote:
> On Mar 5 00:09, Yaakov wrote:
> > I don't know if the version changes are a matter of policy or just how
> > it has happened, but in any case that's not the current versioning
> > scheme, nor is it how libtool libraries are usually versi
On Mar 5 00:09, Yaakov wrote:
> On Mon, 4 Mar 2013 15:40:22 +0100, Corinna Vinschen wrote:
> > On Mar 4 14:15, Corinna Vinschen wrote:
> > > Thanks, but here's a question: If the libgcj ABI version really changes
> > > with every GCC major.minor release, wouldn't it then make sense to
> > > chan
On Mon, 4 Mar 2013 15:40:22 +0100, Corinna Vinschen wrote:
> On Mar 4 14:15, Corinna Vinschen wrote:
> > Thanks, but here's a question: If the libgcj ABI version really changes
> > with every GCC major.minor release, wouldn't it then make sense to
> > change the libgcj DLL versioning scheme so it
On Mar 4 14:15, Corinna Vinschen wrote:
> On Mar 4 05:39, Yaakov wrote:
> > On Mon, 4 Mar 2013 11:51:34 +0100, Corinna Vinschen wrote:
> > > That looks good, thanks for catching this problem! Please apply the
> > > Cygwin changes. I'll rebuild new base packages including the gcc
> > > patches s
On Mar 4 05:39, Yaakov wrote:
> On Mon, 4 Mar 2013 11:51:34 +0100, Corinna Vinschen wrote:
> > That looks good, thanks for catching this problem! Please apply the
> > Cygwin changes. I'll rebuild new base packages including the gcc
> > patches soon.
>
> BTW, at some point the attached patch wil
On Mon, 4 Mar 2013 11:51:34 +0100, Corinna Vinschen wrote:
> That looks good, thanks for catching this problem! Please apply the
> Cygwin changes. I'll rebuild new base packages including the gcc
> patches soon.
BTW, at some point the attached patch will also need to be added for
4.8. The libgc
On Mar 4 02:12, Yaakov wrote:
> Corinna,
>
> More fun from our good friend, size_t:
>
> Because operator new (in its various forms) takes a size_t argument, it
> is mangled differently on x86_64 above and beyond the common leading
> underscore issue. Patches for winsup/cygwin and gcc (on top of
20 matches
Mail list logo
