GCC dependencies (attn David Billinghurst)

GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

David,

As mentioned recently on the list, due to Dave Korn's extended absence,
I'll be maintaining our gcc packages.  Since you maintain several GCC
dependencies, we'll need to coordinate.

Would you be able to update the following packages to exactly these
versions:

gmp-4.3.2
mpfr-3.0.1
mpclib-0.9
ppl-0.11.2
cloog-ppl-0.15.9

Minor bugfixes notwithstanding, that should take care of things for GCC
4.5 and 4.6.

This isn't urgent; if these could be ready in the next couple of weeks,
that would be great.  Thanks,


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[David Billinghurst]

On 27/07/2011 1:11 PM, Yaakov (Cygwin/X) wrote:
> David,
>
> As mentioned recently on the list, due to Dave Korn's extended absence,
> I'll be maintaining our gcc packages.  Since you maintain several GCC
> dependencies, we'll need to coordinate.
>
> Would you be able to update the following packages to exactly these
> versions:
>
> gmp-4.3.2
> mpfr-3.0.1
> mpclib-0.9
> ppl-0.11.2
> cloog-ppl-0.15.9
>
> Minor bugfixes notwithstanding, that should take care of things for GCC
> 4.5 and 4.6.
>
> This isn't urgent; if these could be ready in the next couple of weeks,
> that would be great.  Thanks,

OK. I have test builds of the majority of these.  I will make a start 
over the weekend.  From memory I had some issues with mpfr-3.0.1.

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Thu, 2011-07-28 at 21:55 +1000, David Billinghurst wrote:
> On 27/07/2011 1:11 PM, Yaakov (Cygwin/X) wrote:
> > Would you be able to update the following packages to exactly these
> > versions:
> >
> > gmp-4.3.2
> > mpfr-3.0.1
> > mpclib-0.9
> > ppl-0.11.2
> > cloog-ppl-0.15.9
> >
> > Minor bugfixes notwithstanding, that should take care of things for GCC
> > 4.5 and 4.6.
> >
> > This isn't urgent; if these could be ready in the next couple of weeks,
> > that would be great.  Thanks,
> 
> OK. I have test builds of the majority of these.  I will make a start 
> over the weekend.  From memory I had some issues with mpfr-3.0.1.

I just cross-compiled 3.0.1 with the upstream 'allpatches' with no other
changes besides a cygautoreconf.  However, it does involve an ABI
version bump on libmpfr (same for libppl and maybe libmpc).


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Tue, 2011-07-26 at 22:11 -0500, Yaakov (Cygwin/X) wrote:
> Would you be able to update the following packages to exactly these
> versions:
> 
> gmp-4.3.2
> mpfr-3.0.1
> mpclib-0.9
> ppl-0.11.2
> cloog-ppl-0.15.9

Sorry, that needs to be cloog-ppl-0.15.11 in order to build OOTB with
ppl-0.11.x.


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[Dave Korn]

On 27/07/2011 04:11, Yaakov (Cygwin/X) wrote:
> David,
> 
> As mentioned recently on the list, due to Dave Korn's extended absence,
> I'll be maintaining our gcc packages.  Since you maintain several GCC
> dependencies, we'll need to coordinate.

  Yaakov, how is this going?  I see you haven't uploaded anything yet.  I'm
back and able to resume maintainership duties if everyone would like.


    cheers,
      DaveK

Re: GCC dependencies (attn David Billinghurst)

[David Billinghurst]

On 10/08/2011 4:45 AM, Dave Korn wrote:
> On 27/07/2011 04:11, Yaakov (Cygwin/X) wrote:
>> David,
>>
>> As mentioned recently on the list, due to Dave Korn's extended absence,
>> I'll be maintaining our gcc packages.  Since you maintain several GCC
>> dependencies, we'll need to coordinate.
>
>    Yaakov, how is this going?  I see you haven't uploaded anything yet.  I'm
> back and able to resume maintainership duties if everyone would like.
>
>
>      cheers,
>        DaveK

I have the remaining packages ready to upload when I get home this evening.

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Tue, 2011-08-09 at 19:45 +0100, Dave Korn wrote:
>   Yaakov, how is this going?  I see you haven't uploaded anything yet.  I'm
> back and able to resume maintainership duties if everyone would like.

That's good news, we were starting to be worried about you.

I was just getting KDE 4.7 out the door while I was waiting for David to
finish the deps.  Here is what I was planning to release:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4

Besides the version update to 4.5.3, there are several changes over the
distro 4.5.0, including:

* Linked against shared (instead of static) libintl.
* Fix shared libgnat installation.
* Fix Java NIO (patch may not be required with recent snapshots).
* Pass --large-address-aware when, and --tsaware only when, linking
EXEs.
* libtool fixup script actually changes .la files.
* Don't install GCC .la files so that the libtool fixup script will be
less needed in the future.
* Revise gcc4-java alternatives usage.

We'll all be glad -- myself included -- for you to resume gcc
development; I have only taken a cursory glance at 4.6.1 (and not even a
glance at gccgo), and I have no idea where trunk is holding.  If you've
got time to package stable branches on top of that, fine, otherwise I
could still handle the packaging side while you focus on development.
Either way, I think we really need a 4.5.3-2 with at least that patchset
out as soon as David can finish updating the deps.

Let me know how you'd like to proceed.


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Fri, 2011-08-12 at 07:09 -0500, Yaakov (Cygwin/X) wrote:
> On Tue, 2011-08-09 at 19:45 +0100, Dave Korn wrote:
> >   Yaakov, how is this going?  I see you haven't uploaded anything yet.  I'm
> > back and able to resume maintainership duties if everyone would like.
> 
> That's good news, we were starting to be worried about you.
> 
> I was just getting KDE 4.7 out the door while I was waiting for David to
> finish the deps.  Here is what I was planning to release:
> 
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4
> 
> Besides the version update to 4.5.3, there are several changes over the
> distro 4.5.0, including:
> 
> * Linked against shared (instead of static) libintl.
> * Fix shared libgnat installation.
> * Fix Java NIO (patch may not be required with recent snapshots).
> * Pass --large-address-aware when, and --tsaware only when, linking
> EXEs.
> * libtool fixup script actually changes .la files.
> * Don't install GCC .la files so that the libtool fixup script will be
> less needed in the future.
> * Revise gcc4-java alternatives usage.
> 
> We'll all be glad -- myself included -- for you to resume gcc
> development; I have only taken a cursory glance at 4.6.1 (and not even a
> glance at gccgo), and I have no idea where trunk is holding.  If you've
> got time to package stable branches on top of that, fine, otherwise I
> could still handle the packaging side while you focus on development.
> Either way, I think we really need a 4.5.3-2 with at least that patchset
> out as soon as David can finish updating the deps.
> 
> Let me know how you'd like to proceed.

BTW, for those interested, I'm already working on updating the Fedora
Cygwin toolchain to match the recent binutils/gdb releases and add the
--large-address-aware patch, along with restoring cygwin-gcc-java for
F15.


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[Dave Korn]

On 12/08/2011 13:09, Yaakov (Cygwin/X) wrote:

> Besides the version update to 4.5.3, there are several changes over the
> distro 4.5.0, including:
> 
> * Linked against shared (instead of static) libintl.
> * Fix shared libgnat installation.
> * Fix Java NIO (patch may not be required with recent snapshots).
> * Pass --large-address-aware when, and --tsaware only when, linking
> EXEs.
> * libtool fixup script actually changes .la files.
> * Don't install GCC .la files so that the libtool fixup script will be
> less needed in the future.
> * Revise gcc4-java alternatives usage.

  Thanks.  I'm not too sure about not installing the .la files; won't that
potentially lead to problems for libtool-using projects at link time?  Also,
did you run any testsuites yet?

> We'll all be glad -- myself included -- for you to resume gcc
> development; I have only taken a cursory glance at 4.6.1 (and not even a
> glance at gccgo), and I have no idea where trunk is holding.  If you've
> got time to package stable branches on top of that, fine, otherwise I
> could still handle the packaging side while you focus on development.
> Either way, I think we really need a 4.5.3-2 with at least that patchset
> out as soon as David can finish updating the deps.
> 
> Let me know how you'd like to proceed.

  I just started a build and test cycle using your updated patches+cygport
script; since you have about a million packages to maintain, I may as well
take care of releasing this and free you up for other stuff.

    cheers,
      DaveK

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Fri, 2011-08-12 at 16:48 +0100, Dave Korn wrote:
>   Thanks.  I'm not too sure about not installing the .la files; won't that
> potentially lead to problems for libtool-using projects at link time?

No, but that reminded me, the libtool fixup script needs a small tweak
to adjust.  I just pushed that to Ports git.

>   I just started a build and test cycle using your updated patches+cygport
> script; since you have about a million packages to maintain, I may as well
> take care of releasing this and free you up for other stuff.

OK.  FHI, last month, I tried sending the following patches upstream:

top-level: fix config.rpath for cygwin/mingw
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01578.html
http://sourceware.org/ml/binutils/2011-07/msg00181.html
http://sourceware.org/ml/gdb-patches/2011-07/msg00563.html

cygwin/mingw: update LIBGCJ_SONAME
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01579.html

libjava: add comment to libtool-version
http://gcc.gnu.org/ml/java-patches/2011-q3/msg00023.html

AFAICS they've gone absolute nowhere.  Maybe you'll have better luck.


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[Corinna Vinschen]

Hi Dave, Hi Yaakov,

On Aug 12 11:21, Yaakov (Cygwin/X) wrote:
> On Fri, 2011-08-12 at 16:48 +0100, Dave Korn wrote:
> >   Thanks.  I'm not too sure about not installing the .la files; won't that
> > potentially lead to problems for libtool-using projects at link time?
> 
> No, but that reminded me, the libtool fixup script needs a small tweak
> to adjust.  I just pushed that to Ports git.
> 
> >   I just started a build and test cycle using your updated patches+cygport
> > script; since you have about a million packages to maintain, I may as well
> > take care of releasing this and free you up for other stuff.
> 
> OK.  FHI, last month, I tried sending the following patches upstream:
> 
> top-level: fix config.rpath for cygwin/mingw
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01578.html
> http://sourceware.org/ml/binutils/2011-07/msg00181.html
> http://sourceware.org/ml/gdb-patches/2011-07/msg00563.html
> 
> cygwin/mingw: update LIBGCJ_SONAME
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01579.html
> 
> libjava: add comment to libtool-version
> http://gcc.gnu.org/ml/java-patches/2011-q3/msg00023.html
> 
> AFAICS they've gone absolute nowhere.  Maybe you'll have better luck.

here's a minor nit, but that bugs me for a while now.

  $ cc hello.c
  $ ./a.out
  bash: ./a.out: No such file or directory

I would like to see that GCC for Cygwin creates the output file
"a.out.exe", so the result is the same on Unix/Linux and Cygwin:

  $ cc hello.c
  $ ./a.out
  hello, world


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: GCC dependencies (attn David Billinghurst)

[Corinna Vinschen]

Hi Yaakov,

On Aug 12 07:40, Yaakov (Cygwin/X) wrote:
> On Fri, 2011-08-12 at 07:09 -0500, Yaakov (Cygwin/X) wrote:
> > On Tue, 2011-08-09 at 19:45 +0100, Dave Korn wrote:
> > >   Yaakov, how is this going?  I see you haven't uploaded anything yet.  I'm
> > > back and able to resume maintainership duties if everyone would like.
> > 
> > That's good news, we were starting to be worried about you.
> > 
> > I was just getting KDE 4.7 out the door while I was waiting for David to
> > finish the deps.  Here is what I was planning to release:
> > 
> > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4
> > 
> > Besides the version update to 4.5.3, there are several changes over the
> > distro 4.5.0, including:
> > 
> > * Linked against shared (instead of static) libintl.
> > * Fix shared libgnat installation.
> > * Fix Java NIO (patch may not be required with recent snapshots).
> > * Pass --large-address-aware when, and --tsaware only when, linking
> > EXEs.
> > * libtool fixup script actually changes .la files.
> > * Don't install GCC .la files so that the libtool fixup script will be
> > less needed in the future.
> > * Revise gcc4-java alternatives usage.
> > 
> > We'll all be glad -- myself included -- for you to resume gcc
> > development; I have only taken a cursory glance at 4.6.1 (and not even a
> > glance at gccgo), and I have no idea where trunk is holding.  If you've
> > got time to package stable branches on top of that, fine, otherwise I
> > could still handle the packaging side while you focus on development.
> > Either way, I think we really need a 4.5.3-2 with at least that patchset
> > out as soon as David can finish updating the deps.
> > 
> > Let me know how you'd like to proceed.
> 
> BTW, for those interested, I'm already working on updating the Fedora
> Cygwin toolchain to match the recent binutils/gdb releases and add the
> --large-address-aware patch, along with restoring cygwin-gcc-java for
> F15.

There's a small glitch in the cross toolchain:

  $ i686-pc-cygwin-gcc foo.c -o foo
  $ ls foo*
  foo  foo.c

Since foo is a Cygwin executable, shouldn't gcc append .exe?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: GCC dependencies (attn David Billinghurst)

[Peter Rosin]

Den 2011-08-13 13:28 skrev Corinna Vinschen:
> Hi Dave, Hi Yaakov,
> 
> On Aug 12 11:21, Yaakov (Cygwin/X) wrote:
>> On Fri, 2011-08-12 at 16:48 +0100, Dave Korn wrote:
>>>   Thanks.  I'm not too sure about not installing the .la files; won't that
>>> potentially lead to problems for libtool-using projects at link time?
>>
>> No, but that reminded me, the libtool fixup script needs a small tweak
>> to adjust.  I just pushed that to Ports git.
>>
>>>   I just started a build and test cycle using your updated patches+cygport
>>> script; since you have about a million packages to maintain, I may as well
>>> take care of releasing this and free you up for other stuff.
>>
>> OK.  FHI, last month, I tried sending the following patches upstream:
>>
>> top-level: fix config.rpath for cygwin/mingw
>> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01578.html
>> http://sourceware.org/ml/binutils/2011-07/msg00181.html
>> http://sourceware.org/ml/gdb-patches/2011-07/msg00563.html
>>
>> cygwin/mingw: update LIBGCJ_SONAME
>> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01579.html
>>
>> libjava: add comment to libtool-version
>> http://gcc.gnu.org/ml/java-patches/2011-q3/msg00023.html
>>
>> AFAICS they've gone absolute nowhere.  Maybe you'll have better luck.
> 
> here's a minor nit, but that bugs me for a while now.
> 
>   $ cc hello.c
>   $ ./a.out
>   bash: ./a.out: No such file or directory
> 
> I would like to see that GCC for Cygwin creates the output file
> "a.out.exe", so the result is the same on Unix/Linux and Cygwin:

It's "a.exe" for cygwin native.

>   $ cc hello.c
>   $ ./a.out
>   hello, world

Cheers,
Peter

Re: GCC dependencies (attn David Billinghurst)

[Corinna Vinschen]

On Aug 13 18:20, Peter Rosin wrote:
> Den 2011-08-13 13:28 skrev Corinna Vinschen:
> > Hi Dave, Hi Yaakov,
> > 
> > On Aug 12 11:21, Yaakov (Cygwin/X) wrote:
> >> On Fri, 2011-08-12 at 16:48 +0100, Dave Korn wrote:
> >>>   Thanks.  I'm not too sure about not installing the .la files; won't that
> >>> potentially lead to problems for libtool-using projects at link time?
> >>
> >> No, but that reminded me, the libtool fixup script needs a small tweak
> >> to adjust.  I just pushed that to Ports git.
> >>
> >>>   I just started a build and test cycle using your updated patches+cygport
> >>> script; since you have about a million packages to maintain, I may as well
> >>> take care of releasing this and free you up for other stuff.
> >>
> >> OK.  FHI, last month, I tried sending the following patches upstream:
> >>
> >> top-level: fix config.rpath for cygwin/mingw
> >> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01578.html
> >> http://sourceware.org/ml/binutils/2011-07/msg00181.html
> >> http://sourceware.org/ml/gdb-patches/2011-07/msg00563.html
> >>
> >> cygwin/mingw: update LIBGCJ_SONAME
> >> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01579.html
> >>
> >> libjava: add comment to libtool-version
> >> http://gcc.gnu.org/ml/java-patches/2011-q3/msg00023.html
> >>
> >> AFAICS they've gone absolute nowhere.  Maybe you'll have better luck.
> > 
> > here's a minor nit, but that bugs me for a while now.
> > 
> >   $ cc hello.c
> >   $ ./a.out
> >   bash: ./a.out: No such file or directory
> > 
> > I would like to see that GCC for Cygwin creates the output file
> > "a.out.exe", so the result is the same on Unix/Linux and Cygwin:
> 
> It's "a.exe" for cygwin native.

I know.  That was my point.  On other systems it's called a.out, on
Cygwin it's called a.exe.  So, if you try to learn C using the good old
K&R book from 1983, you're asked to compile hello.c and then call a.out.
Doesn't work on Cygwin for obvious reasons.  Why on earth didn't the GCC
folks decide to name the output file a.out.exe, so you can run "hello,
world" by running a.out as well?

> >   $ cc hello.c
> >   $ ./a.out
> >   hello, world
> 
> Cheers,
> Peter


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Sat, 2011-08-13 at 16:11 +0200, Corinna Vinschen wrote:
> > BTW, for those interested, I'm already working on updating the Fedora
> > Cygwin toolchain to match the recent binutils/gdb releases and add the
> > --large-address-aware patch, along with restoring cygwin-gcc-java for
> > F15.

FYI, this has been pushed to the servers now.

> There's a small glitch in the cross toolchain:
> 
>   $ i686-pc-cygwin-gcc foo.c -o foo
>   $ ls foo*
>   foo  foo.c

Confirmed, and now I see that the same happens with Fedora's
mingw32-gcc.

> Since foo is a Cygwin executable, shouldn't gcc append .exe?

This would make sense.  Since mingw32-gcc does the same thing, I'll
guess that the .exe magic was only implemented for a native compiler.

Looking at the code, the .exe handling is added in gcc/gcc.c.  There are
two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it
calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used
only for and in convert_filename() to change the output filename.  But
the latter is only used if:

/* By default there is no special suffix for target executables.  */
/* FIXME: when autoconf is fixed, remove the host check - dj */
#if defined(TARGET_EXECUTABLE_SUFFIX) && defined(HOST_EXECUTABLE_SUFFIX)
#define HAVE_TARGET_EXECUTABLE_SUFFIX
#endif

I may be new to the GCC code, but that just looks bogus.  On Linux,
HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control
HAVE_TARGET_EXECUTABLE_SUFFIX?

I've made a patch to change that, and am rebuilding cygwin-gcc with that
now.  If it works (and I don't see why it won't), I'll go ahead and
respin releases with the patch.

Dave, anything to add here?


Yaakov

Re: GCC dependencies (attn David Billinghurst)

[Peter Rosin]

Den 2011-08-14 13:20 skrev Corinna Vinschen:
> On Aug 13 18:20, Peter Rosin wrote:
>> Den 2011-08-13 13:28 skrev Corinna Vinschen:
>>> here's a minor nit, but that bugs me for a while now.
>>>
>>>   $ cc hello.c
>>>   $ ./a.out
>>>   bash: ./a.out: No such file or directory
>>>
>>> I would like to see that GCC for Cygwin creates the output file
>>> "a.out.exe", so the result is the same on Unix/Linux and Cygwin:
>>
>> It's "a.exe" for cygwin native.
> 
> I know.  That was my point.  On other systems it's called a.out, on
> Cygwin it's called a.exe.  So, if you try to learn C using the good old
> K&R book from 1983, you're asked to compile hello.c and then call a.out.
> Doesn't work on Cygwin for obvious reasons.  Why on earth didn't the GCC
> folks decide to name the output file a.out.exe, so you can run "hello,
> world" by running a.out as well?

Oops, sorry for the noise. Here I was thinking you had suffered from a brain
fart or something. I read your other post about the .exe suffix for the cross
compiler first and erroneously thought you were talking about cross compilers
here as well.

Oh well, I'm crawling back to my corner...

Cheers,
Peter

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

On Sun, 2011-08-14 at 14:29 -0500, Yaakov (Cygwin/X) wrote:
> On Sat, 2011-08-13 at 16:11 +0200, Corinna Vinschen wrote:
> > > BTW, for those interested, I'm already working on updating the Fedora
> > > Cygwin toolchain to match the recent binutils/gdb releases and add the
> > > --large-address-aware patch, along with restoring cygwin-gcc-java for
> > > F15.
> 
> FYI, this has been pushed to the servers now.
> 
> > There's a small glitch in the cross toolchain:
> > 
> >   $ i686-pc-cygwin-gcc foo.c -o foo
> >   $ ls foo*
> >   foo  foo.c
> 
> Confirmed, and now I see that the same happens with Fedora's
> mingw32-gcc.
> 
> > Since foo is a Cygwin executable, shouldn't gcc append .exe?
> 
> This would make sense.  Since mingw32-gcc does the same thing, I'll
> guess that the .exe magic was only implemented for a native compiler.
> 
> Looking at the code, the .exe handling is added in gcc/gcc.c.  There are
> two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it
> calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used
> only for and in convert_filename() to change the output filename.  But
> the latter is only used if:
> 
> /* By default there is no special suffix for target executables.  */
> /* FIXME: when autoconf is fixed, remove the host check - dj */
> #if defined(TARGET_EXECUTABLE_SUFFIX) && defined(HOST_EXECUTABLE_SUFFIX)
> #define HAVE_TARGET_EXECUTABLE_SUFFIX
> #endif
> 
> I may be new to the GCC code, but that just looks bogus.  On Linux,
> HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control
> HAVE_TARGET_EXECUTABLE_SUFFIX?
> 
> I've made a patch to change that, and am rebuilding cygwin-gcc with that
> now.  If it works (and I don't see why it won't), I'll go ahead and
> respin releases with the patch.

cygwin-gcc 4.5.3-4 is now available for both releases on both arches.  I
still need to test my patch (for trunk, attached) in other
configurations, but AFAICS it fixes the issue you reported.


Yaakov


[-- Attachment #2: cross-target-exe-suffix.patch --]
[-- Type: text/x-patch, Size: 628 bytes --]

2011-08-14  Yaakov Selkowitz  <yselkowitz@...>

	* gcc.c (HAVE_TARGET_EXECUTABLE_SUFFIX): Do not make dependent
	on HOST_EXECUTABLE_SUFFIX.

Index: gcc/gcc.c
===================================================================
--- gcc/gcc.c	(revision 177751)
+++ gcc/gcc.c	(working copy)
@@ -48,8 +48,7 @@
 #include "filenames.h"
 
 /* By default there is no special suffix for target executables.  */
-/* FIXME: when autoconf is fixed, remove the host check - dj */
-#if defined(TARGET_EXECUTABLE_SUFFIX) && defined(HOST_EXECUTABLE_SUFFIX)
+#if defined(TARGET_EXECUTABLE_SUFFIX)
 #define HAVE_TARGET_EXECUTABLE_SUFFIX
 #endif
 

Re: GCC dependencies (attn David Billinghurst)

[Corinna Vinschen]

On Aug 14 23:03, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-08-14 at 14:29 -0500, Yaakov (Cygwin/X) wrote:
> > On Sat, 2011-08-13 at 16:11 +0200, Corinna Vinschen wrote:
> > > > BTW, for those interested, I'm already working on updating the Fedora
> > > > Cygwin toolchain to match the recent binutils/gdb releases and add the
> > > > --large-address-aware patch, along with restoring cygwin-gcc-java for
> > > > F15.
> > 
> > FYI, this has been pushed to the servers now.
> > 
> > > There's a small glitch in the cross toolchain:
> > > 
> > >   $ i686-pc-cygwin-gcc foo.c -o foo
> > >   $ ls foo*
> > >   foo  foo.c
> > 
> > Confirmed, and now I see that the same happens with Fedora's
> > mingw32-gcc.
> > 
> > > Since foo is a Cygwin executable, shouldn't gcc append .exe?
> > 
> > This would make sense.  Since mingw32-gcc does the same thing, I'll
> > guess that the .exe magic was only implemented for a native compiler.
> > 
> > Looking at the code, the .exe handling is added in gcc/gcc.c.  There are
> > two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it
> > calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used
> > only for and in convert_filename() to change the output filename.  But
> > the latter is only used if:
> > 
> > /* By default there is no special suffix for target executables.  */
> > /* FIXME: when autoconf is fixed, remove the host check - dj */
> > #if defined(TARGET_EXECUTABLE_SUFFIX) && defined(HOST_EXECUTABLE_SUFFIX)
> > #define HAVE_TARGET_EXECUTABLE_SUFFIX
> > #endif
> > 
> > I may be new to the GCC code, but that just looks bogus.  On Linux,
> > HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control
> > HAVE_TARGET_EXECUTABLE_SUFFIX?
> > 
> > I've made a patch to change that, and am rebuilding cygwin-gcc with that
> > now.  If it works (and I don't see why it won't), I'll go ahead and
> > respin releases with the patch.
> 
> cygwin-gcc 4.5.3-4 is now available for both releases on both arches.  I
> still need to test my patch (for trunk, attached) in other
> configurations, but AFAICS it fixes the issue you reported.

WJFFM, thank you!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: GCC dependencies (attn David Billinghurst)

[Corinna Vinschen]

On Aug 15 01:01, Peter Rosin wrote:
> Den 2011-08-14 13:20 skrev Corinna Vinschen:
> > On Aug 13 18:20, Peter Rosin wrote:
> >> Den 2011-08-13 13:28 skrev Corinna Vinschen:
> >>> here's a minor nit, but that bugs me for a while now.
> >>>
> >>>   $ cc hello.c
> >>>   $ ./a.out
> >>>   bash: ./a.out: No such file or directory
> >>>
> >>> I would like to see that GCC for Cygwin creates the output file
> >>> "a.out.exe", so the result is the same on Unix/Linux and Cygwin:
> >>
> >> It's "a.exe" for cygwin native.
> > 
> > I know.  That was my point.  On other systems it's called a.out, on
> > Cygwin it's called a.exe.  So, if you try to learn C using the good old
> > K&R book from 1983, you're asked to compile hello.c and then call a.out.
> > Doesn't work on Cygwin for obvious reasons.  Why on earth didn't the GCC
> > folks decide to name the output file a.out.exe, so you can run "hello,
> > world" by running a.out as well?
> 
> Oops, sorry for the noise. Here I was thinking you had suffered from a brain
> fart or something.

I did.   The K&R book has been published in 1978, not 1983.  That was
the publishing date of the german translation which I purchased in a
feeble moment way back when.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: GCC dependencies (attn David Billinghurst)

[Dave Korn]

On 14/08/2011 20:29, Yaakov (Cygwin/X) wrote:

> Looking at the code, the .exe handling is added in gcc/gcc.c.  There are
> two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it
> calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used
> only for and in convert_filename() to change the output filename.  But
> the latter is only used if:
> 
> /* By default there is no special suffix for target executables.  */
> /* FIXME: when autoconf is fixed, remove the host check - dj */
> #if defined(TARGET_EXECUTABLE_SUFFIX) && defined(HOST_EXECUTABLE_SUFFIX)
> #define HAVE_TARGET_EXECUTABLE_SUFFIX
> #endif
> 
> I may be new to the GCC code, but that just looks bogus.  On Linux,
> HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control
> HAVE_TARGET_EXECUTABLE_SUFFIX?
> 
> I've made a patch to change that, and am rebuilding cygwin-gcc with that
> now.  If it works (and I don't see why it won't), I'll go ahead and
> respin releases with the patch.
> 
> Dave, anything to add here?

  Perhaps ping DJ over on the GCC list to ask him if he remembers the context
behind that comment; maybe whatever was the autoconf problem is indeed now fixed.

    cheers,
      DaveK

Re: GCC dependencies (attn David Billinghurst)

[Yaakov (Cygwin/X)]

On Sat, 2011-08-13 at 13:28 +0200, Corinna Vinschen wrote:
> here's a minor nit, but that bugs me for a while now.
> 
>   $ cc hello.c
>   $ ./a.out
>   bash: ./a.out: No such file or directory
> 
> I would like to see that GCC for Cygwin creates the output file
> "a.out.exe", so the result is the same on Unix/Linux and Cygwin:
> 
>   $ cc hello.c
>   $ ./a.out
>   hello, world

Besides that POSIX requires a.out for the default output for c99 and
fort77.


Yaakov